You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by mi...@mdc-service.de on 2022/06/18 15:24:01 UTC
Nuttx 10.0.3, ESP32-WROOM and MCUboot for OTA
Dear all,
I try to implement over-the-air(or Ethernet cable in my case) on
ESP32-WROOM with the latest Nuttx 10.0.03. I followed a video "Secure
Boot on NuttX with MCUboot
demo"(https://www.youtube.com/watch?v=Vzy0rl-ixbc) from last year.
Unfortunately, its not working for me.
The current Nuttx have more menu options, and I was unable to to bringup
the
Application Configuration -> Bootloader Utilities -> MCUboot -> MCUboot
update agent example
and
Application Configuration -> Bootloader Utilities -> MCUboot -> MCUboot
slot confirm example.
nuttxspace/apps/boot/mcuboot/Kconfig does not contain
"CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT".
(I added the following to my
boards/xtensa/ESP32/espiff-v1/configs/ethernet/defconfig
CONFIG_NSH_MOTD_STRING="Welcome to MCUboot support on NuttX!"
CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT=y
CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT_DL_BUFFER_SIZE=4096
CONFIG_ESP32_APP_FORMAT_MCUBOOT=y
CONFIG_EXAMPLES_MCUBOOT_SLOT_CONFIRM=n
then did a make distclean and ./tools/configure.sh -l
esp32-espiff-v1:ethernet, but it does not show the "MCUboot slot confirm
example" and "MCUboot slot confirm example" as in the video shown).
I found further, that the build system seem to work different now then
in the 1 year old video.
My console output after make:
....
AR (create): libboard.a esp32_boot.o esp32_bringup.o esp32_appinit.o
esp32_reset.o esp32_board_i2c.o esp32_board_spiflash.o
make[2]: Leaving directory
'/home/micha/nuttxspace/nuttx/boards/xtensa/esp32/common'
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)
console output in video:
...
AR (create): libboard.a esp32_boot.o esp32_bringup.o esp32_appinit.o
esp32_reset.o esp32_spiflash.o esp32_board_wlan.o
...
MKIMAGE: ESP32 binary
imgtool sign --pad --pad-sig --confirm --align 4 -v 0 -H 32 --pad-header
-S 0x100000 nuttx.bin nuttx_signed.bin
Generated: nuttx.bin (MCUboot compatible)
The parameters for the call of "MKIMGAGE" are different then in the
video, and did not create a "nuttx_signed.bin", and so, MCUboot does not
build.
Searching for the problem, I found that the CONFIG_ESP32_SECURE_BOOT is
not set. The 10.0.3 build system offer now, to set this, combined with a
warning. On the last years version, as shown in the video, these option
was not visible. But it comes with a warning:
"Enable hardware Secure Boot in bootloader (READ HELP FIRST)".
So I set it, came a set further. The build system then complains, that
ESPSEC_KEYDIR is not set. This does not look if its a Nuttx
configuration variable, I could not find out how to set it in the Nuttx
build system, so I simply set an environment variable
export ESPSEC_KEYDIR=/home/micha/nuttxspace/nuttx/espsec_keydir/,
created a new key
imgtool keygen --key app_signing_key.pem --type rsa-3072
and now finally make succeed.
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?
- 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?
My current partition table is
# Name, Type, SubType, Offset, Size
nvs, data, nvs, 0x009000, 0x004000
otadata, data, ota, 0x00d000, 0x002000
phy_init, data, phy, 0x00f000, 0x001000
ota_0, app, ota_0, , 0x180000
ota_1, app, ota_1, , 0x180000
Re: Nuttx 10.0.3, ESP32-WROOM and MCUboot for OTA
Posted by Gustavo Henrique Nihei <gh...@gmail.com>.
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 <mi...@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 <mi...@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
Re: Nuttx 10.0.3, ESP32-WROOM and MCUboot for OTA
Posted by mi...@mdc-service.de.
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 <mi...@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.
>> >
>>
Re: Nuttx 10.0.3, ESP32-WROOM and MCUboot for OTA
Posted by Gustavo Henrique Nihei <gh...@gmail.com>.
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 <mi...@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
Re: Nuttx 10.0.3, ESP32-WROOM and MCUboot for OTA
Posted by mi...@mdc-service.de.
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.
>
Re: Nuttx 10.0.3, ESP32-WROOM and MCUboot for OTA
Posted by Gustavo Henrique Nihei <gh...@gmail.com>.
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.
On Sat, Jun 18, 2022 at 12:24 PM <mi...@mdc-service.de> wrote:
> Dear all,
>
> I try to implement over-the-air(or Ethernet cable in my case) on
> ESP32-WROOM with the latest Nuttx 10.0.03. I followed a video "Secure
> Boot on NuttX with MCUboot
> demo"(https://www.youtube.com/watch?v=Vzy0rl-ixbc) from last year.
> Unfortunately, its not working for me.
>
> The current Nuttx have more menu options, and I was unable to to bringup
> the
> Application Configuration -> Bootloader Utilities -> MCUboot -> MCUboot
> update agent example
> and
> Application Configuration -> Bootloader Utilities -> MCUboot -> MCUboot
> slot confirm example.
>
> nuttxspace/apps/boot/mcuboot/Kconfig does not contain
> "CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT".
> (I added the following to my
> boards/xtensa/ESP32/espiff-v1/configs/ethernet/defconfig
> CONFIG_NSH_MOTD_STRING="Welcome to MCUboot support on NuttX!"
> CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT=y
> CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT_DL_BUFFER_SIZE=4096
> CONFIG_ESP32_APP_FORMAT_MCUBOOT=y
> CONFIG_EXAMPLES_MCUBOOT_SLOT_CONFIRM=n
> then did a make distclean and ./tools/configure.sh -l
> esp32-espiff-v1:ethernet, but it does not show the "MCUboot slot confirm
> example" and "MCUboot slot confirm example" as in the video shown).
>
> I found further, that the build system seem to work different now then
> in the 1 year old video.
>
> My console output after make:
> ....
> AR (create): libboard.a esp32_boot.o esp32_bringup.o esp32_appinit.o
> esp32_reset.o esp32_board_i2c.o esp32_board_spiflash.o
>
> make[2]: Leaving directory
> '/home/micha/nuttxspace/nuttx/boards/xtensa/esp32/common'
> 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)
>
> console output in video:
> ...
> AR (create): libboard.a esp32_boot.o esp32_bringup.o esp32_appinit.o
> esp32_reset.o esp32_spiflash.o esp32_board_wlan.o
> ...
> MKIMAGE: ESP32 binary
> imgtool sign --pad --pad-sig --confirm --align 4 -v 0 -H 32 --pad-header
> -S 0x100000 nuttx.bin nuttx_signed.bin
> Generated: nuttx.bin (MCUboot compatible)
>
> The parameters for the call of "MKIMGAGE" are different then in the
> video, and did not create a "nuttx_signed.bin", and so, MCUboot does not
> build.
>
> Searching for the problem, I found that the CONFIG_ESP32_SECURE_BOOT is
> not set. The 10.0.3 build system offer now, to set this, combined with a
> warning. On the last years version, as shown in the video, these option
> was not visible. But it comes with a warning:
> "Enable hardware Secure Boot in bootloader (READ HELP FIRST)".
> So I set it, came a set further. The build system then complains, that
> ESPSEC_KEYDIR is not set. This does not look if its a Nuttx
> configuration variable, I could not find out how to set it in the Nuttx
> build system, so I simply set an environment variable
> export ESPSEC_KEYDIR=/home/micha/nuttxspace/nuttx/espsec_keydir/,
> created a new key
> imgtool keygen --key app_signing_key.pem --type rsa-3072
> and now finally make succeed.
>
> 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?
>
> - 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?
> My current partition table is
> # Name, Type, SubType, Offset, Size
> nvs, data, nvs, 0x009000, 0x004000
> otadata, data, ota, 0x00d000, 0x002000
> phy_init, data, phy, 0x00f000, 0x001000
> ota_0, app, ota_0, , 0x180000
> ota_1, app, ota_1, , 0x180000
>
--
Gustavo Henrique Nihei