cederom commented on issue #13824: URL: https://github.com/apache/nuttx/issues/13824#issuecomment-2406318087
As reported in https://github.com/espressif/esptool/issues/1018 by @radimkarnis: > Taking a brief look at this - I believe this is a result of some of the recent fixes (https://github.com/espressif/esptool/commit/4c5874a3c497ce3bd2e3289d5e367db4f4ac89b5, https://github.com/espressif/esptool/commit/4394a658c40b73cc6d593797a42b665e68f84cf7, https://github.com/espressif/esptool/commit/e87cc3ec62c08046503092b8f58bf62ebadcbcac) in [the --ram-only-header option](https://docs.espressif.com/projects/esptool/en/latest/esp32s3/esptool/basic-commands.html#:~:text=The%20%2D%2Dram%2Donly,bootloader%20boot%20it) in v4.8. > > These changes have been implemented by the Zephyr team. Hopefully, they can shed some more light on this - cc @almir-okato, @sylvioalves PTAL. > >> what would be the way to approach and fix > > Currently, I can only recommend that you use the latest esptool. We don't plan to backport any of these changes and they are still somewhat "experimental". Looking at the provided information `--ram-only-header` is used by `esptool` command `elf2image` that converts ELF to firmware image flashed into the chip to trigger "simple boot" mode that redirects BootROM to hardware initialization functions bundled within the image: > The --ram-only-header configuration is mainly applicable for use within the Espressif’s SIMPLE_BOOT option from 3rd party OSes such as ZephyrOS and NuttX OS. This option 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 may result in a more fragmented binary because of flash alignment constraints. It is strongly recommended to use this configuration with care, because the image built must then handle the basic hardware initialization and the flash mapping for code execution after ROM bootloader boot it. Previous releases of `esptool` did not have this functionality implemented (i.e. version 4.3) or produced invalid image with overlapping regions (i.e. version 4.7). Fixes will not be backported to previous releases. For now we are tied to `esptool` version >= 4.8. I have asked about possible alternative solutions for older `esptool` versions, but most feasible solution for now is to verify version and throw build error if version older than 4.8. Can you please prepare this kind of patch @fdcavalcanti @almir-okato ? :-) 1. This should be placed right before the firmware image is generated. 2. Verify and report available `esptool` version. 3. Throw build error if `esptool` version `< 4.8` with a message that v4.8 contains fixes required to build valid firmware image and tool needs an upgrade. Thank you :-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
