maxikrie opened a new pull request, #21133:
URL: https://github.com/apache/nuttx/pull/21133
## Summary
Depends on #21132 , which makes the CMake build of the Xtensa ESP32 chips
work for simple boot. With `ESP32S3_APP_FORMAT_MCUBOOT` the CMake build still
stopped at configure time. This PR ports `Bootloader.mk` for the ESP32-S3:
- `arch/xtensa/src/esp32s3/Bootloader.cmake` writes `bootloader.conf` as
`Bootloader.mk` does and adds a `bootloader` target (not in the default
build, as `make bootloader`): it clones MCUboot and its HAL, runs
`tools/espressif/build_mcuboot.sh` and copies `mcuboot-esp32s3.bin` to the
NuttX directory, where the flash and merge steps look for it (as on
RISC-V).
- On Xtensa the board options are `<CHIP>_ESPTOOL_TARGET_*`,
`<CHIP>_APP_MCUBOOT_HEADER_SIZE` and `<CHIP>_OTA_*`, which
`tools/esp32s3/Config.mk` reads; `espressif_esptool_common.cmake` now maps
them onto the `ESPRESSIF_*` names the shared image and flash scripts use.
Before, the image was signed and flashed for the `ESPRESSIF_OTA_*`
defaults, or stopped at "Missing MCUBoot slot target".
- `espressif_mkimage.cmake` needs the bootloader binary only for a merged or
UF2 image, as `Config.mk`; an app build no longer fails before the
bootloader target has run.
ESP32 and ESP32-S2 MCUboot and the legacy app format still stop at configure
time; their `Bootloader.mk` differ (secure boot, 0x1000 offset).
## Impact
CMake builds of ESP32-S3 MCUboot configs (`esp32s3-devkit:mcuboot_nsh`).
Make builds are unchanged. The `espressif_mkimage.cmake` change also applies
to the RISC-V Espressif chips: they no longer require the bootloader binary
for a plain app image.
## Testing
Host: Debian Linux (kernel 6.1), x86_64. Toolchain: esp-14.2.0_20251107,
esptool 5.6.0, imgtool 2.5.0.
`esp32s3-devkit:mcuboot_nsh` with CMake (`cmake --build <dir>`, then
`-t bootloader`), compared with the Make build of the same commit:
- `bootloader.conf`: identical.
- `mcuboot-esp32s3.bin`: same code; Make's is 112 B longer from the longer
`__FILE__` paths of its build tree and segment padding.
- App ELF: same symbols and sections; the size differences are the ROMFS
ones of the base PR.
- Signed `nuttx.bin`: same MCUboot header (0x20, 0.0.0+0), padded to the
slot.
- `-t flash` writes mcuboot at 0x0, `vefuse.bin` at 0x10000 and `nuttx.bin`
at 0x20000, as `make flash`.
Rebuilt after rebasing onto master 93c7e875a4, together with
esp32s3-devkit:nsh and wifi, esp32-devkitc:nsh and esp32s2-saola-1:nsh.
Hardware (ESP32-S3, chip rev v0.2), flashed with `cmake --build <dir> -t
flash`:
```
[esp32s3] [INF] *** Booting MCUboot build v2.2.0-151-g8a07053d ***
[esp32s3] [INF] [boot.esp32s3] Boot SPI Speed : 40MHz
[esp32s3] [INF] [boot.esp32s3] SPI Mode : DIO
[esp32s3] [INF] [boot.esp32s3] SPI Flash Size : 4MB
[esp32s3] [INF] Image index: 0, Swap type: none
[esp32s3] [INF] Loading image 0 - slot 0 from flash, area id: 1
[esp32s3] [INF] start=0x40374ba4
nsh>
```
`usbnsh` with MCUboot builds with neither Make nor CMake: without a UART
console nothing sets `CONFIG_ESP_CONSOLE_UART_NUM` for the bootloader, and
its `bootloader_console.c` fails. Not changed here.
# Notes
- Diff: `diffs/xtensa-esp32s3-mcuboot-cmake.diff`, on top of
`diffs/xtensa-esp-cmake.diff`, both on master 5055d980da.
- `tools/checkpatch.sh -f` passes on the four files.
## What it changes
- `arch/xtensa/src/esp32s3/Bootloader.cmake` (new): writes `bootloader.conf`
line for line as `Bootloader.mk`, and adds a `bootloader` target (not in
the default build, as `make bootloader`) that clones MCUboot and its HAL on
first use, runs `tools/espressif/build_mcuboot.sh` and copies
`mcuboot-esp32s3.bin` to the NuttX directory, where the flash and merge
steps look for it (as on RISC-V).
- `arch/xtensa/src/common/espressif/CMakeLists.txt`: ESP32-S3 MCUboot no
longer stops at configure; ESP32 / ESP32-S2 MCUboot and the legacy format
still do (their Bootloader.mk differ: secure boot, 0x1000 offset). Simple
boot gets a `bootloader` target printing Make's message.
- `tools/espressif/espressif_esptool_common.cmake`: on Xtensa, the per-chip
options (`<CHIP>_ESPTOOL_TARGET_*`, `<CHIP>_APP_MCUBOOT_HEADER_SIZE`,
`<CHIP>_OTA_*`) replace the `ESPRESSIF_*` ones the shared image and flash
scripts read. Without it a board setting `ESP32S3_OTA_*` (as Make reads)
was signed and flashed for the `ESPRESSIF_OTA_*` defaults, and no
`ESPRESSIF_ESPTOOL_TARGET_*` exists on Xtensa ("Missing MCUBoot slot
target").
- `tools/espressif/espressif_mkimage.cmake`: the bootloader binary is needed
only for a merged or UF2 image, as in Config.mk; an app build no longer
fails before the bootloader target has run. (Also affects RISC-V.)
## Compared with Make, esp32s3-devkit:mcuboot_nsh
- `bootloader.conf`: identical.
- `mcuboot-esp32s3.bin`: same code; 112 B longer in Make, from the 5 assert
`__FILE__` paths (20 B longer each in the Make tree) plus segment padding.
- App ELF: same symbols (CMake adds the `.callsz`/`.locsz` section symbols);
sections equal but `.flash.rodata` +1012 B, `.dram0.data` +16 B,
`.dram0.bss` -8 B: the ROMFS / `romfs_img_len` differences noted in
`xtensa-esp-cmake.md`.
- Signed `nuttx.bin`: same header (0x20, 0.0.0+0, flags 0), padded to the
slot; image length differs by the ROMFS bytes.
- Flash (stub esptool): mcuboot 0x0, vefuse.bin 0x10000, nuttx.bin 0x20000,
as `make flash`.
## Open
- An unset value (an `OTA_*` option missing from `.config`) writes an empty
`bootloader.conf` line, as Make does, instead of a CMake macro error.
- MCUboot with a USB-only console (`usbnsh` + MCUBOOT) does not build, in
Make or CMake: no UART console sets no `CONFIG_ESP_CONSOLE_UART_NUM`, and
`bootloader_console.c` fails. Not ours; hardware test uses `mcuboot_nsh`.
- Hardware done: `mcuboot_nsh` built with CMake, `cmake --build <dir> -t
bootloader` then `-t flash` (via ESP-Prog): MCUboot v2.2.0-151-g8a07053d,
DIO 40 MHz 4 MB, boots slot 0 at 0x20000 (header 0x20), `nsh>` on UART0.
- Builds needed `kconfiglib`, `esptool`, `imgtool` (scratch venv).
- For spacetime: its mcuboot patch 0011 (DIO image) is in
`build_mcuboot.sh`, which this path runs too; 0010 (QIO HAL sources) and
0012 (40 MHz) patch `Bootloader.mk` and would need the same change in
`Bootloader.cmake`, once spacetime is on a release with CMake for the S3.
--
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]
