ESP32C3: boot_request_upgrade() does not work when flash encryption is enabled

[abdulhayub]

I have built the Espressif port of MCUboot v2.0.0 (with secure boot and flash encryption) using this guide. I'm using MCUboot with my Zephyr-based (v3.5.0) application to perform OTA updates and so on.

After transferring the update image to slot1, I mark it as test using boot_request_upgrade(BOOT_UPGRADE_TEST) from the zephyr-based application. However, after doing a reset, the module still boots into the old image and no swapping is started. It seems like boot_request_upgrade() does not work as intended when using MCUboot with flash encryption enabled, and it doesn't return any error code either.

The build of MCUboot without flash encryption enabled works as intended, i.e. the update image can be marked as test and on the next reboot the swapping starts as expected.

For reference, I sign the update image as: imgtool.py sign -k <SIGNING_KEY.pem> --align 32 --max-align 32 -v 0 -H 32 --pad-header -S <SLOT_SIZE> <BIN_IN> <BIN_OUT>

To Reproduce:

• Build MCUboot v2.0.0 with secure boot and encryption enabled for esp32c3
• Flash MCUboot, primary application in slot0 and secondary update applicaiton in slot1
• Via the primary application, call boot_request_upgrade(BOOT_UPGRADE_TEST)
• Reboot

Expected behavior: MCUboot swaps primary and secondary applications as expected.

Impact: Since I'm unable to mark update candidate image for update, I have to transfer images that are already marked as test/permanent. More importantly, I'm unable to revert/downgrade to previous image (swapped and stored in slot1).

Logs: Below is the log from the boot where I expect swapping to begin:

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x403803ba
0x403803ba: esp_restart_noos at /workdir/zephyr/soc/riscv/espressif_esp32/esp32c3/soc.c:168 (discriminator 1)
 
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd8d58,len:0x3874
load:0x403c7000,len:0x362c
load:0x403d0000,len:0x4f94
entry 0x403d4dea
[esp32c3] [WRN] [boot.esp32c3] eFuse virtual mode is enabled. If Secure boot or Flash encryption is enabled then it does not provide any security. FOR TESTING ONLY!
[esp32c3] [INF] *** Booting MCUboot build v2.0.0 ***
[esp32c3] [INF] [boot] chip revision: v0.3
[esp32c3] [INF] [boot.esp32c3] SPI Speed      : 40MHz
[esp32c3] [INF] [boot.esp32c3] SPI Mode       : DIO
[esp32c3] [INF] [boot.esp32c3] SPI Flash Size : 4MB
[esp32c3] [INF] [boot] Enabling RNG early entropy source...
[esp32c3] [WRN] eFuse virtual mode is enabled. If Secure boot or Flash encryption is enabled then it does not provide any security. FOR TESTING ONLY!
[esp32c3] [WRN] [efuse] [Virtual] try loading efuses from flash: 0x250000 (offset)
[esp32c3] [WRN] [efuse] [Virtual] Loading virtual efuse blocks from flash
EFUSE_BLKx:
0) 0x01800305 0x00000002 0x49c40000 0x00100000 0x00000002 0x00000000 
1) 0x4e5ac980 0x0000a076 0x00000000 0x890c0000 0x9514ece1 0x00070af3 
2) 0xbf84e746 0x7dc016dd 0xe76ec983 0x520f60b5 0x17044829 0xfa461c81 0x5e338263 0x00000009 
3) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
4) 0x0258b8a6 0x5cb0d362 0x10f1e67d 0x65315957 0xb0db3a9b 0x22fdd386 0x149c0eec 0xce7bf55b 
5) 0x199bb5ea 0xbef37db9 0xb29396b5 0x19c86024 0xc4ff457d 0xc9e177c2 0xb34063dc 0xf1f1daa5 
6) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
7) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
8) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
9) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
10) 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
[esp32c3] [INF] enabling secure boot v2...
[esp32c3] [INF] secure boot v2 is already enabled, continuing..
[esp32c3] [INF] Primary image: magic=bad, swap_type=0x1, copy_done=0x3, image_ok=0x3
[esp32c3] [INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[esp32c3] [INF] Boot source: none
[esp32c3] [INF] Image index: 0, Swap type: none
[esp32c3] [INF] Checking flash encryption...
[esp32c3] [INF] [flash_encrypt] flash encryption is enabled (1 plaintext flashes left)
[esp32c3] [INF] Disabling RNG early entropy source...
[esp32c3] [INF] br_image_off = 0x10000
[esp32c3] [INF] ih_hdr_size = 0x20
[esp32c3] [INF] Loading image 0 - slot 0 from flash, area id: 1
[esp32c3] [INF] DRAM segment: start=0x296d0, size=0x1cfc, vaddr=0x3fcbc138
[esp32c3] [INF] IRAM segment: start=0x2002c, size=0x96a4, vaddr=0x40380000
0x40380000: _esp32c3_vector_table at ??:?
 
[esp32c3] [INF] start=0x4038881a
0x4038881a: __start at /workdir/zephyr/soc/riscv/espressif_esp32/esp32c3/loader.c:83
 
[esp32c3] [INF] DROM segment: paddr=00010040h, vaddr=3C000040h, size=0FFECh ( 65516) map
[esp32c3] [INF] IROM segment: paddr=00030000h, vaddr=42020000h, size=48088h (295048) map
*** Booting Zephyr OS build zephyr-v3.5.0 ***

Environment:

• MCUboot v2.0.0 - Espressif port for esp32c3 using default boot/espressif/port/esp32c3/bootloader.conf
• OS: zephyr-v3.5.0
• Target: esp32c3 (DevkitM-1)

[nordicjm]

@sylvioalves

[almir-okato]

Hi @abdulayubzoi, I'm investigating what may be the root cause.

[almir-okato]

Hi @abdulhayub, sorry for the delay. One of the issues is that Virtual eFuses is still not supported on Zephyr for Espressif chips. I was working on provisionally adding this to Zephyr, but still couldn't finish.

Also when working with Flash Encryption enabled, this must be added to DTS as an overlay:

&flash0 {
  write-block-size = <32>;
};

However, I couldn't fully test it (currently I can't risk bricking boards as the Virtual eFuses still are not supported on Zephyr level), so be very careful if trying this without Virtual eFuses enabled.

[abdulble]

Hi @almir-okato,

So if I understood it correctly, I just need to add the DTS overlay and experiment with virtual eFuse disabled, right? I will do some testing and get back to you then.

Thank you!

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.