[esptool] segments with load 0x00000000

[michprev]

Haven't tried but i think that padding segments are also upload by esptool. Yes, it would be better just say "Skip next x KB in memory and continue with a next partition" but I guess that we are limited by ROM bootloader.

Bin image consists of an image header https://github.com/espressif/esptool/wi ... ile-header (ESP32 header is a bit longer) and segments https://github.com/espressif/esptool/wi ... at#segment.

ROM bootloader reads image header and interprets the next bytes as segment header. Segment header contains also information about how big the segment is. Bootloader reads (and tries to copy) data in that segment and right after that data it expects another segment header and so on.

Bin image should look like:
[Image headers][Segment 0 headers][Segment 0 data][Segment 1 headers][Segment 1 data] ....

So basically we need at least padding segment headers so that bootloader could work correctly. We do not need to send segment data themself. But we would have to do something like:

Code: Select all

esptool.py --chip esp32 write_flash 0x10000 app_part1.bin 0x4000000 app_part2.bin ...

Where app_part1.bin contains image headers, some segments and padding segment headers. Let's say that padding segment headers would be flashed to 0x3800000. Data in range 0x3800008 - 0x3FFFFFF would be padding data but we don't need to send them. So we continue flashing app_part2.bin at 0x4000000 with another segments data.

So after first stage bootloader configures SPI flash it does something like this (lets assume we do not use secure boot):

1. check image header at 0x1000 as described here https://github.com/espressif/esptool/wi ... ile-header (ESP32 probably has additional bytes in header)

Pretty much. ROM bootloader (ie first stage bootloader) actually uses this header to further configure the SPI flash (based on mode, flash frequency, flash size which are all encoded there).

There's an additional 16 bytes of header for ESP32, for a total of 24. Most of this extra header is unused (see the load_extended_header function in esptool.py if you're interested).

[*] iterate over segments with their headers as described here https://github.com/espressif/esptool/wi ... at#segment; based on memory offset decide

• if this is a RAM segment copy it to the corresponding RAM space
• if this is a flash segment leave it right as it is

[/list]

For the ROM bootloader, it actually tries to copy every segment to the specified load address. If the load address is in a flash cache mapped space then I believe what you'll get is essentially a lot of no-op writes as it reads from flash and discards the output by writing it into a black hole.

(This is one of the reasons the ESP-IDF software bootloader runs 100% from IRAM/DRAM.)

This is also why any padding segments (mapped at address 0x0) cause it to crash (memory protection is applied for 0x0)..

[michprev]

I think I understand that segments in flash need to be 64K aligned so that they can be mapped by the MMU component. For example, I may have:

Code: Select all

[Segment A: 10K]
[Padding:   54K]
[Segment B: 20K]
[Padding:   44K]
[Segment C: 30K]

This seems to result in an image bin file size of about 158K. However, if we look at the actual data content, it appears to be only 10K + 20K + 30K = 60K with the remainder being padding.

I think that something like this will hardly happen. Only flash segments (data that will go to flash) need to be 64K aligned. RAM segments can be placed anywhere. So scenario you describe would only happen with all A, B, C segments being flash segments. If there was another RAM segment D with size 70K then it would be split into 54K and 16K parts.

Code: Select all

[FLASH Segment A:           10K]
[RAM Segment D (part 1):    54K]
[FLASH Segment B:           20K]
[RAM Segment D (part 2):    16K]
[Padding:                   28K]
[FLASH Segment C:           30K]