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
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
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
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
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*" defconf
