Add swap using offset mode

[nordicjm]

Fixes #2134

165KiB update using swap using move on nrf5340dk: 18 seconds
182KiB update using swap using offset on nrf5340dk: 13 seconds

[Laczen]

@nordicjm this is a very nice improvement. There are some minor documentation nits.

A further possible improvement could be to place the swap state (image trailer) in the update image slot (this will not be erased during the swap, and thus the image could go up to the slot size - trailer size).

[nordicjm]

@nordicjm this is a very nice improvement. There are some minor documentation nits.

A further possible improvement could be to place the swap state (image trailer) in the update image slot (this will not be erased during the swap, and thus the image could go up to the slot size - trailer size).

I left it in the first as with the "move" slot being moved to the second image, the overhead in both slots is now about equal (swap status in primary, move slot in secondary). However I'm not sure if this mode will actually be finished, the simulator is a giant fight and lots of edge cases need handling in application code to account for the secondary slot image being at either offset, and as of right now the simulator failures make no sense to me

[Laczen]

Some food for further thoughts: I have created a similar approach outside of mcuboot, by using a different terminology:
A "backup slot" is defined that starts one sector before the "update slot" and has the same size of the "update slot" and the "image slot", so the backup slot covers a part of the "update slot" (ends one sector sooner).

The image update moves one sector from image to backup followed by a move from update to image, when the update is finished the old image is in the backup slot and the new image is in the image slot. A restore is a move from the backup slot to the image slot.

The method also allows removing the "swap with scratch" as the "scratch" sector can be defined as the first sector of the backup image.

For devices that have plenty of flash the backup slot can also be defined separate from the update slot to enhance the life and keep flash wear equal for all slots (update erases all flash only once).

[nordicjm]

The method also allows removing the "swap with scratch" as the "scratch" sector can be defined as the first sector of the backup image.

The plan is that swap using scratch will be removed in the coming future, but as it stands right now this would not work, e.g. on an stm32 where the sector sizes are 32KiB, 32KiB, 64KiB, 128KiB, 128KiB - making it the first sector give a scratch size of 32KiB which means you can't complete a single swap. The idea is that MCUboot's "sector size" will not be the flash sector size in future, it will be able to be configured so in the case of the stm32 will be 128KiB, in the case of a device with internal and external flash whereby internal flash has 2KiB sectors and external flash has 8KiB sectors, both will be 8KiB - once this change is made it means that swap using scratch can be removed entirely because despite the device have different sector sizes, the move is done in multiples of the largest sector size. The added benefit of this is that the code is smaller and swap status area is smaller too

[butok]

Hi @nordicjm
SWAP_USING_OFFSET is better than SWAP_USING_MOVE.
Are there any cases where SWAP_USING_MOVE is preferable over OFFSET?

[nordicjm]

Hi @nordicjm SWAP_USING_OFFSET is better than SWAP_USING_MOVE. Are there any cases where SWAP_USING_MOVE is preferable over OFFSET?

When building for existing products where the bootloader is configured in swap using move mode, other than that swap using offset should become the new default

[d3zd3z]

Looks good. I think this will make a good default.