I could not get any output from on the serial console of a seeedstudio-xiao-esp32c3 board, after an upgrade of RIOT and the Espressif toolchain. Thankfully, this post fixed this issue.
Still, when I type make reset, I get an intriguing SHA-256 error, as shown below. Should I worry?
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x42002c04
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd6100,len:0x4ac
load:0x403ce000,len:0x840
load:0x403d0000,len:0x227c
SHA-256 comparison failed:
Calculated: 585f3a3b13464e4a50472e1127df5378d3206951c227446dcf1d1d957b67aae7
Expected: 6e736aefb929d9eb3a9deb06c01299a4e20e794fc644f4c87eb5ba12b830b4a9
Attempting to boot anyway...
entry 0x403ce000
Pro cpu up.
The Xtensa-CPU based ESP32 have a secure boot mechanism, with a fuse that gets blown to force it. I would expect the RISC-V based ones would retain that.
PDF:
https://www.espressif.com/sites/default/files/documentation/esp32-c3_technical_reference_manual_en.pdf#sysmem
Table 4.3-1 – cont’d from previous page
mentions the secure boot bits in the eFuse.
Nope… not in that document.
https://docs.espressif.com/projects/esp-idf/en/stable/esp32c3/security/secure-boot-v2.html#secure-boot-v2-process
“SHA-256 hash of only the image content, not including the signature block.”
I imagine that the first stage boot loader is calculating the SHA256 of the second stage, and your device has a hash already in an eFUSE, but you don’t have the bit blown that says to refuse to boot if they do not match.
I’ve read the “secure-boot-v2” pages before, they are unfortunately very ESP-IDF specific, and they don’t really explain the SHA256 step.
I went down this rabbit hole, because I thought maybe the c3 documentation might be better/different than the Xtensa-ARCH one.