casaroli opened a new pull request, #19789:
URL: https://github.com/apache/nuttx/pull/19789

   ## Summary
   
   A protected build on the ESP32 could only use the legacy IDF image format. 
This pull request lets it boot from simple boot instead.
   
   Kconfig already allowed the choice. `ESP32_APP_FORMAT_LEGACY` is only a 
`default y if BUILD_PROTECTED`, not a `select`, so a user could clear it and 
get `CONFIG_ESPRESSIF_SIMPLE_BOOT=y`. The result did not link, and after it 
linked it did not boot.
   
   Simple boot has no second-stage bootloader. `__start()` maps the flash 
itself, so everything it reaches has to be in RAM already. `kernel-space.ld` 
pinned none of it, and it did not place `esp32_start` at all, so the entry 
point landed in the flash that the code was about to map:
   
   ```
   entry 0x400d0ba4
   Fatal exception (0): IllegalInstruction
   epc1=0x400d0ba6
   ```
   
   ## What changed
   
   One file, `boards/xtensa/esp32/common/scripts/kernel-space.ld`, and every 
block is behind `CONFIG_ESPRESSIF_SIMPLE_BOOT`. A legacy build gets exactly the 
IRAM it had before.
   
   It pins `esp32_start` and the bootloader, flash, ROM, clock and log objects 
that `bootloader_init()` and `map_rom_segments()` reach, with the matching 
read-only data.
   
   It defines the six `_image_irom_*` and `_image_drom_*` symbols that 
`__start()` needs to link. Under simple boot `map_rom_segments()` reads the 
segment table out of the image in flash, so these only have to exist.
   
   It adds `#include <nuttx/config.h>`. The file held no conditionals until 
now, so nothing revealed the omission. Without it the new blocks compiled away 
in silence and the link failed exactly as if the file had never been edited. 
This cost me a build cycle and is worth knowing about for anyone adding a 
conditional to this script.
   
   The default does not change. A protected build still uses the legacy format 
unless the user clears `CONFIG_ESP32_APP_FORMAT_LEGACY`.
   
   This is the ESP32 counterpart of #19764, which did the same for the ESP32-S3.
   
   ## Testing
   
   Board: ESP32-DevKitC V4, with an ESP32-D0WD-V3 revision 3.1.
   
   Host: macOS 15 on Apple Silicon, `xtensa-esp32-elf-gcc` 12.2.0.
   
   | configuration | image format | result |
   |---|---|---|
   | `esp32-devkitc:knsh` | simple boot | boots to NSH, maps 7 segments |
   | `esp32-devkitc:knsh` | legacy | unchanged, boots to NSH |
   
   With simple boot the kernel flashes at `0x1000` and the user image at 
`0x90000`. There is no bootloader and no partition table to flash:
   
   ```
   rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
   entry 0x40091c90
   *** Booting NuttX ***
   imap: lma 0x00010020 vma 0x400d0020 len 0x15f4c  (89932)
   dmap: lma 0x00030020 vma 0x3f400020 len 0x2c64   (11364)
   total segments stored 7
   ABCESP32 chip revision is v3.1
   
   NuttShell (NSH) NuttX-12.2.1
   ```
   
   `ostest` reaches the same point in both image formats, so userspace behaves 
the same either way.
   
   Note for reviewers: `ostest` does not finish on `esp32-devkitc:knsh` in 
**either** format. It stops in the barrier test with `barrier_test: ERROR 
thread 6 create, status=12`. That is heap size, not this change — the protected 
user heap arena is 95,908 B against 320,236 B in the flat build, and eight 
barrier threads want 8192 B of stack each. I confirmed it is pre-existing by 
building `esp32-devkitc:knsh` from `master` and getting the identical failure 
on the same board.
   
   `tools/checkpatch.sh -c -u -m -g` reports no errors.
   


-- 
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]

Reply via email to