Rust ESP32 Community Meeting 2025-02-13

[MabezDev]

The meeting is scheduled for 13th of February 2025 - 5 pm CET/GMT+1.

Join the meeting here

[SergioGasquez]

espflash save image rework: We are currently discussing how to allow the user to have separate binaries when using this command, here is the conversation esp-rs/espflash#717

[ivmarkov]

Feature gaps in espflash compared to Espressif's esptool Python tooling - (from my POV - excuse my potential naivety!)

===================================================================================================

(In the context of OTA/esp_app_desc_t, Secure Download mode, Secure boot, Flash Encryption, and eFuse-ing.)

(This includes the topic of @SergioGasquez - esp-rs/espflash#717 but not only.)

(Also, I'm sure I'm missing a lot of related / other issues to the topic at hand - sorry about that!)

Status quo

I think the usability of espflash is great and in fact better than esptool for regular "development-style" flashing of firmware.

Where things start to break a bit is in the (long) "last mile" when the flashing is for a production setup.

In production setup - contrary to the development one - one or several of the requirements below might be necessary to meet.

Gaps / Necessary Extensions

esp_app_desc_t at offset 32 in the firmware .bin

esp_app_desc_t is an ESP-IDF-specific structure that should be part of the firmware "app" image.

Up until ESP IDF V5.3 (I think) it was only necessary (I think!) for ESP-IDF-based firmware using the ESP-IDF OTA APIs, in that those APIs do read and interpret this structure and expect it to be at a fixed offset in the app partition.

Additionally, the presence of this structure at a fixed offset in the to-be-downloaded .bin allows the app itself to load the structure while the .bin is copied in chunks to the partition and abort the OTA update/flash process in the middle, if the description is found to be for an image which is not the latest version and thus not a good candidate for update.

Since ESP-IDF 5.3 the new bootloaders however now also read this structure on firmware app boot (so as to check certain parameters like chip compatibility with the app image, MMU page size - since ESP IDF 5.4) and will refuse to boot the app image if the structure is not present at the correct offset.

The above means that even baremetal images which do not support OTA now need to have this structure present in them at the correct offset.

• This is tracked here. This is an esp-hal thing.

There is an additional bug in that for newer chips (esp32c6 and others) espflash does not place the esp_app_desc_t structure at the correct offset of 32 in the binary app image.

• This is tracked here

Secure Download mode

espflash cannot flash when the MCU has secure Download mode enabled

• This is tracked here

.. and no, --no-stub does not help. Interestingly, espmonitor does work with Secure DL enabled:

espflash monitor --no-stub -b no-reset-no-sync --chip esp32s3 --elf ./my-firmware

... does work.

Secure Boot (V2)

While preparing a Secure Boot V2 image in theory does not have anything to do with "flashing", there is one place where these two intersect: converting an ELF image to a .bin one.
For SB to be operational, it is necessary for the .bin image - during the conversion process - to be padded to the MMU page size (right?) and the bootloader - to the 4K page size.

• This is tracked here

Native Rust equivalent to espsecure

To generate a SB V2 image, one has to append to it (after the padding from above?) the SB signature block.

• One option is to just use the Espressif espsecure Python tooling - perhaps even in the "Rust wrapped" dressing I'm referring to here.
• Another is to embed an espsecure pure Rust equivalent in espflash. Like this library.

Flash Encryption

IF one follows this Espressif workflow - then rather than relying on the bootloader to do its magic and re-encrypt the plaintext images flashed initially, one needs to have a tool to (a) generate a random Flash encryption key (b) a utility to encrypt the flash images (bootloader, app image and other stuff ending up in encrypted flash partitions) before flashing.

• One option is to just use the Espressif espsecure Python tooling
• Another is to create a similar Rust tooling on our own

Note that since encryption is position-dependent, whatever Rust tooling we come up with (if any) needs to "know" about the position/partition offset where the payload would ultimately reside: esp-rs/espflash#717 (The topic of Sergio)

There is also this opened PR, but I'm not sure yet what it does: esp-rs/espflash#718

eFuse-ing

This is probably real tough. Only option is to use Espressif Python's espefuse currently, and I guess it would take a lot of work to implement something similar in espflash?

Philosophical topic

The PR pointed to by @SergioGasquez also touches a bit on - when implementing the above bits and pieces - whether we should (a) go with a CLI which looks similar to the Espressif Python tooling (i.e. a bunch of commands where each does exactly one thing, but can be a bit more annoying to use) or (b) we can "innovate" and come up with a different, "more user friendly" CLI.

While I have a preference for (a), I don't think I have a very good grasp of the above topics, so take my opinion with a big grain of salt.

UPDATE: Irrespective of the shape of the future CLI, I think at least on a library API level we need to have well defined "single-purpose" API endpoints. An example is this current API which - roughly speaking - should convert an app image ELF to .BIN. However, it does not just do that. It also converts to BIN the bootloader and the partition table and returns "one thing" which contains them all. But I don't need all these things to be returned to me by the API, so I'm relying on something which might be a hack to extract the firmware app image .BIN from what the API returns...