Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[esp32c6] espflash write-bin converts the ELF image to a .bin which has the DROM/IROM segment containing esp_app_desc_t at a wrong position #741

Open
ivmarkov opened this issue Feb 3, 2025 · 1 comment
Milestone

Comments

@ivmarkov
Copy link
Contributor

ivmarkov commented Feb 3, 2025

There is a need for some black magic in the code that converts an ELF to a .bin file so as to make sure, that the segment containing the esp_app_desc_t structure is placed as the first segment in the the resulting .bin file.

The correct placement of this struct however fails on the esp32c6 (and I suspect other newer MCUs as well). More info here: esp-rs/esp-idf-sys#365 (comment)

The above was always necessary so that one can easily locate the position of the esp_app_desc_t structure during OTA update and abort the OTA update "in-flight" if the image description describes an older (or in other ways inappropriate) image for flashing.

The problem is however now much more severe with the recent breed of new ESP IDF bootloaders (ESP-IDF 5.2.3 and ESP-IDF 5.3.2) which themselves do expect the esp_app_desc_t to be at the beginning of the firmware image (offset 32 if I'm not mistaken) or else they read bogus values and often refuse to boot the firmware image.

Possible reasons why the esp_app_desc_t is no longer placed at the beginning of the binary image is explained in details in the above esp-idf-sys bug and has a lot to do with the fact that esp32c6 and newer MCUs no longer distinguish between "DROM" and "IROM" and moreover, the "DROM" segment (if there is still such a thing after all) is having an address which is after the IROM segment (unlike all earlier chips, where exactly the opposite is true).

I suspect proper placement of esp_app_desc_t was anyway only working as a pure luck in espflash simply due to the fact that probably XMAS ELF returns the ELF segments by address order and then naturally the "DROM" segment was placed first in the resulting .bin - for earlier chips.

FYI, esptool is suffering exactly the same bug, but ESP-IDF C code is apparently unaffected, as the ESP IDF native C build apparently uses "something else" to convert the ELF to .bin...

@Dzarda7
Copy link

Dzarda7 commented Feb 3, 2025

FYI guys, here is the problem and proposed solutions described.

@SergioGasquez SergioGasquez added this to the v4 milestone Feb 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

3 participants