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.
>
