[RFC] Explore and decide on a bootloader option

[MabezDev]

As things currently stand, we've been using the ESP-IDF bootloader, this has historically been for simplicity, but also the fact that we get compatibility with much of the IDF tooling. There is a strong argument to stick with this, but before we make a decision we should evaluate the other options.

I am of the opinion, that other than the esp-idf bootloader, if we choose a bootloader it should be written in Rust, to avoid complicated build steps, or in the case of esp-idf's bootloader, integration with tooling (pre built bootloaders within espflash/probe-rs).

embassy-boot

embassy-boot (docs) is a lightweight bootloader which supports

• DFU upgrades (on chips with USB)
• OTA (one slot only it seems)
• Image signing
• Support is provided mostly through the embedded-storage traits, but may also require some glue code for specific startup code on some chips
• There isn't support for esp-idf's secure boot OOTB, but I believe this could be added with our implementation.

mcuboot-rs

mcuboot-rs is a implementation of mcuboot, but in Rust. It is currently in PoC status.

• Will eventually support all the features of mcuboot
  • This includes secure boot and signed images
• Only supports LPC55S69 right now

ROM bootloader image format

One unresolved issue is how to take a bootloader elf produced from Rust code, and get it into a format where by the ROM code bootloader (in non-direct boot mode) will understand, see this. Post build steps aren't really a thing in cargo, so we'd need a way to solve this. Unless of course we don't, we could just make the bootloader flashing a one-time step that a user has to do from time to time.

[jessebraham]

mcuboot-rs hasn't been touched in ~9 months, I don't see that being a viable option.

[Dominaezzz]

I'm quite ignorant to this bootloader topic but is it possible to let users choose?

Are there parts of the hal that assume esp-idf's bootloader is being used?

[MabezDev]

I'm quite ignorant to this bootloader topic but is it possible to let users choose?

Of course! Sorry, I should have outlined this in the OP. What I meant is that we should decide on an OOTB solution that most users will use. Advanced users can of course do whatever they like. The main reason for this discussion is that OTA is essentially a hard requirement for any project, and OTA requires some level of coordination from the bootloader.

Are there parts of the hal that assume esp-idf's bootloader is being used?

In theory, no, we had direct-boot support for a while and things just worked, but it's possible we may have baked in an assumption here or there over time.

[rftafas]

Let me add some info here and some experience from working in NON-ESP-IDF systems...

Bootloaders for Espressif Devices

Currently, on C-Based systems, there are 4 options of booting Espressif devices:

• Simpleboot: this is dumb naming from us, because it is the lack of a bootloader. No ESP-IDF Partitions. Offers NO security, encryption or Software Application Update features.
• MCUboot - Espressif Port: Specific port of MCUboot, comes with SecureBoot and Flash Encryption. Also, when using a multicore device, it can start each core with a different application (AMP).
• IDFboot - classic.
• DirectBoot - Uses IDF partitions, valid for C3 (AFAIK)

And we can add a Rust solution to the list.

• Embassy-Boot. AFAIK, for Espressif, nothing was implemented, but it may be a good bet for a Rust Solution.
• Other inactive projects floating around (RustBoot, Loadstone, Moonboot, etc - correct if I'm wrong)

That said, I would rule out IDFboot and DirectBoot as there is a lot of code that is ESP-IDF dependent and not much agnostic. I won't mention them forward. Neither any inactive project.

Simpleboot

Simpleboot is more like looking into some functions and translate them to an analog in Rust. Maybe an option for the leanest of the options. The necessity is debatable, as it was only made because some Embedded OSes have a 'bootloader-less' option.

ESP-TOOL was already modified to support this.

MCUboot:

• Part of Zephyr, part of Linux Foundation (means big player)
• It is true, MCUboot-RS is in limbo. We would need to use the C-based meanwhile. OTOH, the process won't change independent of the language it was implemented.
• MCUboot "process" is mature: many projects using it. It is robust and very capable. By process we mean mechanics, image formats, etc.
• 2 sets of code: one, the bootloader itself, the other, the APIs that run on the application and handle the MCUboot images.
• It is already working for Espressif devices.

Embassy Boot

• Backed by Embassy project (means big player)
• Work will be similar to porting MCUboot to Espressif in the first time with added complexity.
• The added complexity: for a pure RUST solution, we would need to rewrite a lot of C-based booting functions.
• Rewriting these functions may give "Simpleboot-Rust" as collateral (may force to pick some changes from ESP-Tool to ESP-Flash)
• Implementing Flash Encryption and SecureBoot may pose a minor complication.

Security

• Flash Encryption: If implemented 'all or nothing' doesn't involve complexity. Best way to do it is to let the device create its own random key and only that device will be able to access that flash. OK for 99% of the applications.
• SecureBoot: Security Chain in Espressif is ROM Bootloader -> Bootloader -> Application. May force upgrades to ESP-Flash.

[bugadani]

embassy-boot is designed for devices without an MMU and while making it work isn't bad, I would not consider it something we should prioritise for. None of the ESP32 devices need to deal with the page-by-page swapping algorithm it uses, which just wears down flash faster than necessary.

[rftafas]

which just wears down flash faster than necessary

I haven't look into it with detail, but as in most cases of update, products usually don't do that often, (lets say a long term devices sees 50 updates in 5-10 years), should not be a problem.

[jessebraham]

Given that, at least to the best of my understanding, we are planning on moving forward with mcuboot support, I guess there is a final decision to be made here and we can close this issue:

Do we plan to support both the ESP-IDF bootloader and mcuboot moving forward? Or are we planning to drop support for the ESP-IDF bootloader altogether?

I would say we should probably support both, but would like to hear some input from others regarding this.

[Dominaezzz]

I would say we should probably support both, but would like to hear some input from others regarding this.

I think there's some value in supporting at least two bootloaders, just to make sure the hal stays bootloader agnostic.

[bjoernQ]

I would say we should probably support both, but would like to hear some input from others regarding this.

+1 for keeping IDF bootloader support

[jamessizeland]

+1 for MCUboot, for a cross-platform option that I've heard is well placed to help with compliance towards the EU Cyber Resilience Act.

[jessebraham]

@MabezDev can this issue be closed? It seems we've reached a consensus that we should support both the ESP-IDF bootloader and mcuboot moving forward, as far as I can tell. We have #2479 for adding mcuboot support, so I see no reason to keep this issue open.

[MabezDev]

Yes, let's close this.

To finalize the thread, we will:

• Use MCUBOOT as our primary bootloader offering - impl tracked here: Add linker scripts (and any additional required code) to support mcuboot #2479
• Still support esp-idf's bootloader in our tooling if users wish to use that instead

[rftafas]

FWIW, there is a tool for field replacement of IDFboot with MCUboot, under development. "Rust" support still pending test.

Once the Reflasher is downloaded by the current app running (as a 'normal' IDFboot-based update), it will normally replace current app with the reflasher, and in sequence the reflasher will replace itself and IDFboot with new bootloader and new application.

More info: https://github.com/espressif/esp-self-reflasher