speed-up swap-move upgrade for incoming images using secondary slot image shifted-up

[nvlsianpu]

In swap using move algorithm the first phase of operations is to move-up content of all (but not the last one) flash sectors in the primary slot by one sector up. That operation requires erasing and write of all sectors which are contains image chunks.

It would be possible to save on these operations if the firmware-download (which is up to the application) could be done with one-sector-shift to the secondary slot. For that case it would be possible to proceed with images sector swapping without bumping-up sector of the primary slot as secondary slot is already shifted.

The algorithm would does one erase cycles on the primary slot and one on the secondary slot during each swap. It can be assumed that receiving a new image by the DFU application requires 1 erase cycle on the secondary slot. Flash wear of the secondary slot will be same as in current swap-move algorithm, flash wear of the primary slot will be a half of that.

Pros:

• In most DFU cases (good weather cases) new image are collected and then just swapped. Improvement will speed-up swap process by around 30%.

Cons:

• needs targets DFU libraries adaptations
• asymmetric wear leveling between image slots (negligible but noticed)

to be considered:

• how to distinguish which slot is shifted-up, or whether no better to make this always in one manner

This idea comes from @de-nordic who also want to support us with related mcumgr patches.

[nvlsianpu]

@d3zd3z @utzig If you can comment on this idea it would be helpful. I think it will be one of topics for coming TSC.

[utzig]

@d3zd3z @utzig If you can comment on this idea it would be helpful. I think it will be on of topics for coming TSC.

I don't see any issues, looks like a neat idea.

[Laczen]

@nvlsianpu, @de-nordic, looking at this differently you could say that the backup slot is one sector down from the upgrade slot. Then you can keep the upgrade slot the same size as the run slot. Or to get an even simpler definition it would be possible to define the scratch sector as leading the upgrade slot (in case of swap upgrade), in that case all layouts would use the same definitions: run, upgrade and scratch.

[d3zd3z]

Basically, this would work for an initial image. The slide would still need to be supported in order to do a revert, and as you mention, there is asymmetric wear, but it is always less wear than not having to do the slide. I guess the main disadvantage is that it would take additional code to check for, since the slide very still has to be supported.

[de-nordic]

MCUmgr already breaks the wear balancing because it only erases (when progressive erase is enabled) pages it needs to store image.

[Laczen]

@d3zd3z, should the slide be supported for a revert ? I would say that a revert does not have to copy the "bad" image.

The wear balancing distortion created is just a reduction of the wear on the run slot, it does not reduce the number of upgrades that can be performed.

The proposal does create a compatibility issue, and this might be a reason not to implement it.

[nvlsianpu]

The proposal does create a compatibility issue, and this might be a reason not to implement it.

I was rather thinking about keeping sliding procedures so swap might be done for the unshifted incoming image as well. @Laczen In many cases tested image which was unconfirmed can be dropped. But still for some of them confirmation might require a remote actor which might been unreachable when was needed. For instance when tested app which requires establishing connection with a TCP server. So reverted image might still be the proper image.

[Laczen]

@nvlsianpu, regarding the reverted image being the proper image: is it a good idea to keep retrying updating ?

How do you distinguish between a bad image (that should not be restored) and a bad connection (that should be "reapplied") ? How do you get out of the image switching loop for a really bad image ?

[github-actions[bot]]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.