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.
