Make mcuboot select recovery app

[Patrick Guenzel]

Hello

We are planning to build a product without physical pins and currently evaluating different recovery options. For that we want to use OTA via BLE/SMP in a dedicated recovery app. Following this thread it is not advised to add the BLE stack to the mcuboot itself so we thought about writing a regular Zephyr app that is loaded when a bootstrapping pin is active or something similar.

The documentation of mcuboot here describes the capabilities of mcuboot to have multiple application images but it sound like these are only intended as library/soft-device type of dependencies for the application in use.

What we are thinking of would look like the following:

+-------------------+
|       NSIB        |
+-------------------+
|   mcuboot 0       |
+--------------------+
|   mcuboot 1        |
+--------------------+
|    app primary     |
+--------------------+
|    app secondary   |
+--------------------+
| recovery primary   |
+--------------------+
| recovery secondary |
+--------------------+

and when the bootstrap pin condition (or something similar) is given mcuboot boots the recovery app (execute in place) or deletes the primary app and copies the recovery app before booting it.

The question now is: Is this possible with stock mcuboot? Would a modification of it be reasonable to do? Is there maybe another, more elegant way of handling the situation?

Thanks in advance

Patrick

[Sigurd Hellesvik]

Hi Patrick,

I will continue on this case.

I think my colleague Simon added an extra pair of slots for MCUBoot in his unofficial multi image dfu sample.
Does this look like the type of extra slots you want to add?

If you want to boot into another slot on pin toggle, you probably need to fork MCUBoot and make some changes to it.
It should not be a problem though, as this functionality is a lot less complicated than Bluetooth Low Energy.
You could have a look at the MCUBoot main() to see how this is handled for Serial Recovery(which is triggered by holding a pin on reset).

Execute In Place(XIP): The way MCUBoot works, is that it can swap an image from one of the slots to the primary slot, then boot from the primary slot.
If you have the recovery partition in an extra slot, I do not think you need to do XIP, as the recovery can just be swapped to run.
Does that make sense?

-----------------------------------------------------------------------------------------

For your overall plan, I think it sounds like a reasonable design. It will of course use a lot of storage space, so external flash might be needed. But I do not see any way to have recovery Firmware Over The Air(FOTA) without using the extra space.

In other words, I can not think of any better solution myself.
For a second opinion, I will ask my colleague Simon if he agrees on the solution.
I will return here when I hear from him.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

I talked to Simon about this, and we have a couple of questions to try and understand the problem you want to solve with your design:

You say: "For that we want to use OTA via BLE/SMP in a dedicated recovery app."
Am I correct to say that this aims to protect against the following scenario?

Your application runs a SMP Server. You update the application. The tests you run on your device completes without issue, so the new application is verified. Some time later, the application breaks fatally, and will not even be fixed on reboot. You can no longer update the application, since you need the application to do FOTA. And since you verified the application, MCUBoot will not roll back to the previous, working, version.
So you hold a button on reboot to enter the recovery partition on reboot, and can now do FOTA with the recovery partition.

If I am wrong, please correct me.
Are there additional reasons for having the recovery partition?

Regards,
Sigurd Hellesvik

[Patrick Guenzel]

Hi Sigurd

Yes that is exactly our scenario.

We first thought about integrating the Bluetooth stack of Zephyr into the MCUBoot application itself but did not follow it because of the first linked post in my original question. In general our company is doing bootloading via RF for some years now but on a different tech and with a self-written protocol stack and a different bootloader. So our initial idea was to replicate that with MCUBoot and BLE.

[Sigurd Hellesvik]

Here are some more thoughts on the issue:

Button and not recovery partition
If you already have a button on the device, would it be enough for the button press to simply roll back to the previous version of the application?
In this case the, both the new version of the application AND the old version must be fatally broken so that both break in order for your device to be bricked. Which should be very very unlikely, right?

Buttonless recovery partition?
However, maybe the recovery partition might make button-less FOTA recovery be possible.
I have not tried it, but maybe it could be possible to make MCUBoot always boot into the recovery partition.
Then the recovery partition waits a bit, and if there are no FOTA updates coming, it will boot into the main application?

[Patrick Guenzel]

The "rollback on recovery" approach is actually quiet neat. Haven't thought about that yet.

The second suggestion basically comes back to my initial question: How does the upgrade management inside of mcuboot work to redirect it, so that it works with a fixed and two upgradable  partitions? The recovery app would be something like a 2nd stage bootloader in this case but we don't have much interest in replicating all the upgrade/rollback/verification mechanisms, that are already in mcuboot.

[Sigurd Hellesvik]

I think that it is the information in the image trailer that chooses what mcuboot will do on next boot.

These are for example changed using mcumgr image test or the bl_validate_firmware().

Since it is summer vacation here, we have limited staff. So for now all I can to is to point you to the docs.

Regards,
Sigurd Hellesvik