Hi Michael, The codebase related to MCUboot support has indeed changed a bit since my presentation at the NuttX Workshop last year. The quickest way for testing the MCUboot bootloader on ESP32 is to use the " *esp32-devkitc:mcuboot_update_agent*" and " *esp32-devkitc:mcuboot_slot_confirm*" defconfigs. Still, let's try to explain the issues you reported.
First, regarding the "nuttx_signed.bin" image. For the initial support of MCUboot on ESP32 (https://github.com/apache/incubator-nuttx/pull/4295), although the build system used the "*sign*" command from *imgtool*, the image was not actually signed, so the "signed" suffix was not really correct. Later, when Secure Boot support was upstreamed on https://github.com/apache/incubator-nuttx/pull/5044, the build system once again generated the "nuttx_signed.bin" image, but now that image was indeed signed with a private key. > But I have still some questions: > - I have not yet flashed the ESP32. Could I brick the board permanent, > if I made a mistake in the above procedure? When you enable Secure Boot on ESP32, the chip performs some irreversible actions (e.g. burning eFuses), so you must proceed with caution. You may find more information about the Secure Boot module on the following pages: - MCUboot and Secure Boot support on Espressif chips: https://docs.mcuboot.com/readme-espressif.html#secure-boot - Secure Boot V2 component: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/secure-boot-v2.html > - Why is the additional scratch partition, in addition to the ota1 and > ota2 partition required? Can I omit the scratch partition, when I select > MCUBOOT_SWAP_USING_MOVE and deselect MCUBOOT_SWAP_USING_SCRATCH? As of today, the only supported and verified method is MCUBOOT_SWAP_USING_SCRATCH. Even so, I believe you could omit the scratch partition when using MCUBOOT_SWAP_USING_MOVE, but maybe you'd need to perform some changes on the NuttX side to properly support it. Best regards, Gustavo. On Sat, Jun 18, 2022 at 12:24 PM <michael.sch...@mdc-service.de> wrote: > Dear all, > > I try to implement over-the-air(or Ethernet cable in my case) on > ESP32-WROOM with the latest Nuttx 10.0.03. I followed a video "Secure > Boot on NuttX with MCUboot > demo"(https://www.youtube.com/watch?v=Vzy0rl-ixbc) from last year. > Unfortunately, its not working for me. > > The current Nuttx have more menu options, and I was unable to to bringup > the > Application Configuration -> Bootloader Utilities -> MCUboot -> MCUboot > update agent example > and > Application Configuration -> Bootloader Utilities -> MCUboot -> MCUboot > slot confirm example. > > nuttxspace/apps/boot/mcuboot/Kconfig does not contain > "CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT". > (I added the following to my > boards/xtensa/ESP32/espiff-v1/configs/ethernet/defconfig > CONFIG_NSH_MOTD_STRING="Welcome to MCUboot support on NuttX!" > CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT=y > CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT_DL_BUFFER_SIZE=4096 > CONFIG_ESP32_APP_FORMAT_MCUBOOT=y > CONFIG_EXAMPLES_MCUBOOT_SLOT_CONFIRM=n > then did a make distclean and ./tools/configure.sh -l > esp32-espiff-v1:ethernet, but it does not show the "MCUboot slot confirm > example" and "MCUboot slot confirm example" as in the video shown). > > I found further, that the build system seem to work different now then > in the 1 year old video. > > My console output after make: > .... > AR (create): libboard.a esp32_boot.o esp32_bringup.o esp32_appinit.o > esp32_reset.o esp32_board_i2c.o esp32_board_spiflash.o > > make[2]: Leaving directory > '/home/micha/nuttxspace/nuttx/boards/xtensa/esp32/common' > LD: nuttx > make[1]: Leaving directory > '/home/micha/nuttxspace/nuttx/arch/xtensa/src' > CP: nuttx.hex > MKIMAGE: ESP32 binary > imgtool sign --pad --confirm --align 4 -v 0 -s auto -H 32 --pad-header > -S 0x100000 nuttx.hex nuttx.bin > Generated: nuttx.bin (MCUboot compatible) > > console output in video: > ... > AR (create): libboard.a esp32_boot.o esp32_bringup.o esp32_appinit.o > esp32_reset.o esp32_spiflash.o esp32_board_wlan.o > ... > MKIMAGE: ESP32 binary > imgtool sign --pad --pad-sig --confirm --align 4 -v 0 -H 32 --pad-header > -S 0x100000 nuttx.bin nuttx_signed.bin > Generated: nuttx.bin (MCUboot compatible) > > The parameters for the call of "MKIMGAGE" are different then in the > video, and did not create a "nuttx_signed.bin", and so, MCUboot does not > build. > > Searching for the problem, I found that the CONFIG_ESP32_SECURE_BOOT is > not set. The 10.0.3 build system offer now, to set this, combined with a > warning. On the last years version, as shown in the video, these option > was not visible. But it comes with a warning: > "Enable hardware Secure Boot in bootloader (READ HELP FIRST)". > So I set it, came a set further. The build system then complains, that > ESPSEC_KEYDIR is not set. This does not look if its a Nuttx > configuration variable, I could not find out how to set it in the Nuttx > build system, so I simply set an environment variable > export ESPSEC_KEYDIR=/home/micha/nuttxspace/nuttx/espsec_keydir/, > created a new key > imgtool keygen --key app_signing_key.pem --type rsa-3072 > and now finally make succeed. > > But I have still some questions: > - I have not yet flashed the ESP32. Could I brick the board permanent, > if I made a mistake in the above procedure? > > - Why is the additional scratch partition, in addition to the ota1 and > ota2 partition required? Can I omit the scratch partition, when I select > MCUBOOT_SWAP_USING_MOVE and deselect MCUBOOT_SWAP_USING_SCRATCH? > My current partition table is > # Name, Type, SubType, Offset, Size > nvs, data, nvs, 0x009000, 0x004000 > otadata, data, ota, 0x00d000, 0x002000 > phy_init, data, phy, 0x00f000, 0x001000 > ota_0, app, ota_0, , 0x180000 > ota_1, app, ota_1, , 0x180000 > -- Gustavo Henrique Nihei
