ESP8266 Community Forum

- Wed Jan 28, 2015 4:20 am #8388 Wonder if anyone can help me out with this...

I'd like to be able to use an OtA update procedure, but would also like to be able to squeeze in some space for some html files as there will be a web interface on the module. What I'd like to do is adjust the locations and sizes of the different pieces of the memory map to make room. If I'm using the Espressif provided OtA update I'm guessing that I'll need to modify the bootloader to do this. So a few questions:

1. Is the source to the bootloader available anywhere?
2. If not is there an open source alternative?
3. Can anyone point me to any info that might help me achieve this? Has anyone else tried it?

Cheers,
Ben

- Thu Jan 29, 2015 12:07 pm #8461 I still haven't been able to find the source for the bootloader anywhere - has anyone else seen this? It would be very useful to get hold of because I imagine lots of people will want to do cloud updates, but not everyone will want to use the exact same settings.

Might be worth putting some effort into an open version of this.

- Thu Jan 29, 2015 2:53 pm #8477 The Espressif OTA upgrade procedure uses two images and an additional "boot loader" that basically just selects which image to run when booting (the one last downloaded OTA). I assume you mean this one and not the one in rom. It seems someone actually has managed to reverse engineer it here: https://github.com/esp8266/esp8266-wiki/tree/master/reversed

The method with two images enables the OTA download routine to make use of the TCP/IP stack and other library functions such as flash routines etc. while upgrading the other firmware slot. The price to pay for this method is ofcause a much reduced flash space for application and data. I've been thinking It should be possible to implement a more efficient method by separating the libs from the app and data and just upgrade the later two OTA.

/Bananis

- Thu Jan 29, 2015 4:27 pm #8479 I've also been thinking how to implement OTA without duplicating the libraries. At first it seemed to be an easy thing to do.
My idea was to create the following flash layout:
0x00000 - 0x1C000 : .text, .data, .rodata (these sections contain data and some code from the libraries, plus my OTA procedure)
0x20000 - 0x40000 : .app.text, .app.data, .app.rodata (I would put my app into these sections)
0x40000 and up : .irom0.text (mostly code from the libraries)

The additional data sections (.app.data, .app.rodata, .app.bss) would be added to the linker script at some fixed offset in RAM, after the .data, .rodata, and .bss. When my firmware would start, it would copy the .app.data, .app.rodata, and .app.text sections from flash to RAM, zero-init .app.bss, and jump to the app entry point somewhere in .app.text.

The problem with this approach is that the heap start address is determined at link time, and library code (in libmain.a) uses that address. So when the actual size of .app.data + .app.rodata + .app.bss sections changes, __heap_start address has to be adjusted. But it is already baked into libmain.a which is stored in flash somewhere above 0x40000!
So the only way left is to have heap size fixed in the linker script. This will also fix the maximum amount of RAM available for the app, and this is something I would rather avoid.

I'm really stuck now. It seems that it's not possible to avoid library code duplication AND have variable heap size at the same time. Any ideas?