Overwrite updates using multiple secondary slots

[sjlongland]

Hi all,

I'm trying to port an existing project over to using Zephyr and MCUBoot. The old project used a custom-made bootloader (yes, in hindsight should have looked at MCUBoot but I didn't know it existed then) which "overwrote" the active image (stored in on-chip executable flash) from one of two possible image partitions in a SPI flash chip.

The bootloader did SHA-256 verification with the application itself checking authenticity. It's been a reliable workhorse which we've had in use for about 5 years now. The application signalled to the bootloader which of the off-chip images it was to load, and the bootloader would erase the main flash and copy the image off off-chip storage into main flash.

The image format was largely a raw MCU image, but there were some reserved parts at fixed addresses that allowed for metadata to be stored (version number, SHA-256 hash, digital signature).

The advantage of this was three-fold:

1. if there was an interruption, we had valid images in the off-chip flash, we might forget which image we were supposed to load, but if we pick one there's a 50% chance of getting the right one. (Worst case, if we get the wrong one, we should still boot up successfully and OTA mechanisms will trigger a retry loading the right one.)
2. the running image is always backed up to at least one of the off-chip slots prior to OTA, which means we can flip between the two versions if we need to roll-back. (Bad releases sometimes happen.)
3. this method put much less stress on the flash erase cycles

The only real downside is you need space for three image slots (primary and the two secondaries), with one of them being a copy of the active image.

At the moment MCUboot only seems to support a single "secondary" image which is used for a "next image" partition so I'd have to do something like this:

I reserve a partition to be slot1 that's for MCUBoot use. My application's OTA partitions (image0 and image1) are separate, and when I want to load one onto the MCU, I copy it to slot1.

Advantages:

1. MCUBoot should already support this
2. image0 and image1 can exist in a filesystem if so desired (e.g. LittleFS)

Disadvantages:

1. We unnecessarily create additional wear on the "temporary" slot1 sectors during an update
2. We need flash space for 4 images not 3 (active, next, and the two image partition slots)
3. The application needs to spend time re-programming the temporary partition instead of simply pointing MCUBoot to an alternate partition it could reach itself.

If MCUBoot supported a second secondary partition, I'd have to nominate which one I was intending to use, but then MCUBoot would proceed with an overwrite like normal.

Is there something I missed that in fact, does allow something like this to be implemented? If not supported, are there any plans to add such support?