Hi Michael, Indeed, MCUboot supports the ESP32 family of chips from a minimum revision and for *ESP32* that baseline is *REV 3*. Operation under older chip revisions has not been validated. Besides, some features might not be available (e.g. Secure Boot and Flash Encryption).
In case you want to proceed for testing purposes, just omit the "*--min-rev*" argument from "*esptool.py elf2image*" command here: https://github.com/mcu-tools/mcuboot/blob/main/boot/espressif/CMakeLists.txt#L244-L250 But, for production purposes, I'd recommend that you consider working with *REV3*, which as of today is the most recent revision. Best regards, Gustavo. On Tue, Jun 21, 2022 at 5:29 AM <michael.sch...@mdc-service.de> wrote: > Hi Gustavo, > > thank you for the explanation. Unfortunately, I can't make it run on my > ESP32-WROOM. I finally downloaded the MCUboot source, and build from > source, and flashed it. But then got: "app build with a chip revision 3, > but actual chip is revision 1". > > In the source code of MCUboot, in boot/espressif/CMakeList.txt: > # Set the minimum revision for each supported chip > if ("${MCUBOOT_TARGET}" STREQUAL "esp32") > set(ESP_MIN_REVISION 3) > elseif("${MCUBOOT_TARGET}" STREQUAL "esp32s2") > set(ESP_MIN_REVISION 0) > elseif("${MCUBOOT_TARGET}" STREQUAL "esp32s3") > set(ESP_MIN_REVISION 0) > elseif("${MCUBOOT_TARGET}" STREQUAL "esp32c3") > set(ESP_MIN_REVISION 3) > else() > message(FATAL_ERROR "Unsupported target ${MCUBOOT_TARGET}") > endif() > > Is it so, that the ESP32-chips with chip revision 1 are not supported by > MCUboot? Unfortunately, I have chip revision 1 on my ESP32-WROOM boards. > > Best regards, > Michael > > Am 2022-06-20 15:19, schrieb Gustavo Henrique Nihei: > > 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
