This commit fixes issue with using elf2image command without --flash-mmu-page-size.
In that case, app info segment might be incorrectly placed in the image.
This is fixed by checking if app info segment is present and if so,
use page size from it or from its alignment.
Closes https://github.com/espressif/esptool/issues/1062
Remove the flags condition from merging function because it prevents
merging segments in certain conditions.
This reverts commit e87cc3ec62.
Signed-off-by: Marek Matej <marek.matej@espressif.com>
Improve the condition upon the segments being merged in the
elf2image command. Covering the cases when comparing adjacent
segment addresses and types is not enough.
Signed-off-by: Marek Matej <marek.matej@espressif.com>
The ram-only-header configuration makes only
the RAM segments visible to the ROM bootloader placing
them at the beginning of the file and altering the
segment count from the image header with the quantity
of these segments, and also writing only their
checksum. This segment placement also may not result
as optimal as the standard way regarding the padding
gap use among the flash segments that could result
in a less fragmented binary.
The image built must then handle the basic hardware
initialization and the flash mapping for code execution
after ROM bootloader boot it.
Signed-off-by: Marek Matej <marek.matej@espressif.com>
Signed-off-by: Almir Okato <almir.okato@espressif.com>
Mostly for the use case of linker scripts which have a large number of sections.
This is also required when having both .eh_frame and .eh_frame_hdr sections in
an ELF file. Having this feature will let us merge both sections within the
flash's rodata section (as long as they are all adjacent).
Normally would use segments (PHDRs) instead, but there are some things about our
ELF files that are not easily comaptible with this (especially ESP32-S2 where
DRAM & IRAM have different VMAs but use the same LMA space, however our linker
scripts so far haven't reflected this.)
Alternative approach to https://github.com/espressif/esptool/pull/546
More discussion at https://www.esp32.com/viewtopic.php?p=62918&sid=564af52d09a51a307f9e9ef9eba6eff6#p62918
Please refer to https://gitlab.espressif.cn:6688/espressif/esp-idf/-/merge_requests/12070 for more info about the use of this functionality.
Relates to IDF-2064
Allows generating a properly checksummed and hashed binary file which
contains the hash of the original ELF file inside. Useful for being
able to identify the ELF file used to produce the binary.
* Pad IROM section to 16 byte boundary
* Append a CRC32 of the rest of the file
Backwards compatible with previous approach (CRC32 is ignored, padding IROM
section changes length so rboot/etc will be able to accommodate.)
