Open MabezDev opened 3 weeks ago
mcuboot-rs
hasn't been touched in ~9 months, I don't see that being a viable option.
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?
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.
Let me add some info here and some experience from working in NON-ESP-IDF systems...
Currently, on C-Based systems, there are 4 options of booting Espressif devices:
And we can add a Rust solution to the list.
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 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.
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.
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.
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
mcuboot-rs
mcuboot-rs is a implementation of mcuboot, but in Rust. It is currently in PoC status.
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.