Hi Michael, > The parameter "--pad-sig" are no longer required for Version > 1.5?
No, according to the documentation it is no longer required. > "-s auto" is not needed ether? Actually "-s auto" is still part of the imgtool arguments that the ESP32 build system passes by default. > So it does not generate a "nuttx_signed.bin". Is this the intended way? > I disconnected my board, and run "make flash" to see the output of the > command, and indeed, "make flash" would try to flash nuttx.bin on the > board, not the "nuttx_signed.bin". Yes, the build system will only sign the firmware image (nuttx_signed.bin) if the user enables the "ESP32_SECURE_BOOT" configuration. Otherwise, the output will be an unsigned firmware image (nuttx.bin). > What would now happen, if I really flash this just generated "nuttx.bin" > onto the board? The MCUboot bootloader would simply load this unsigned application firmware, in a similar way that the standard IDF bootloader does. > Can we use MCUboot with the ESP32 without encryption, and without > touching the EFUSES? If so, what would be the procedure? Yes. The "mcuboot_slot_confirm" and "mcuboot_update_agent" defconfigs do not enable the ESP32 hardware support for neither Secure Boot nor Flash Encryption, so the eFuses will not be burned. The ESP32_SECURE_BOOT configuration enables the usage of ESP32 Secure Boot V2, which will be a complement to MCUboot's verification. It is not enabled by default, so you don't need to worry about bricking your device. Once Secure Boot V2 is enabled, the ROM bootloader verifies the signature of the MCUboot bootloader using the RSA-3072 algorithm, achieving a complete Secure Boot solution. Best regards, Gustavo. On Sun, Jun 19, 2022 at 6:47 AM <michael.sch...@mdc-service.de> wrote: > Hi Gustavo, > > thank you for the fast reply. So there is the danger, to brick the board > irreversible, when something is going wrong. That scares me. > > I took a look, if I can build the esp32-devkitc:mcuboot_update_agent. So > I did > make distclean > make menuconfig. -> here I changed the ESP32-WROVER to ESP-WROOM. And I > enabled Ethernet-Phy > make. The result is: > > 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) > > The parameter "--pad-sig" are no longer required for Version > 1.5? "-s > auto" is not needed ether? > > So it does not generate a "nuttx_signed.bin". Is this the intended way? > I disconnected my board, and run "make flash" to see the output of the > command, and indeed, "make flash" would try to flash nuttx.bin on the > board, not the "nuttx_signed.bin". > What would now happen, if I really flash this just generated "nuttx.bin" > onto the board? > > Can we use MCUboot with the ESP32 without encryption, and without > touching the EFUSES? If so, what would be the procedure? > > Best regards, > Michael > > > Am 2022-06-19 02:29, schrieb Gustavo Henrique Nihei: > > 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. > > > -- Gustavo Henrique Nihei
