Boot: Introduce new swap method using status partition

[romanjoe]

This pull request introduces new swap mode suitable for devices with large minimum write/erase sizes. New mode is based on existing swap move algorithm but uses specially managed flash area called status partition instead of image trailer to store sectors statuses while swapping, as well as other data located in trailer.

This mode is developed using Cypress PSoC6 as hardware platform. PSoC6 has minimum write/erase size of 512 bytes, swap mode using status partition can be easily configured for use with platforms which have different min write/erase size.

Supported:

• swap modes: test, revert, permanent
• power safe swapping (power loss, random resets)
• configurable minimum write/erase size
• flash wear elimination approach (configurable)
• swap status partition size calculations are automated and based on BOOT_MAX_IMG_SECTORS and min write/erase size
• single and multi image mcuboot configurations supported
• existing imgtool compatible

Considerations:

• only tested on cypress hardware
• sim does not support it yet, but @d3zd3z hopes to add it

Any comments, suggestions are welcome.

[romanjoe]

Extracted watchdog related commit and created separate PR for that.

#931

[elcritch]

This code contains a number of Cypress PSoC6 specific changes. Are they related to the new swap status partition or just details for implementing the Cypress chip? I'm going to try and get this running on NXP LPC55S69.

[d3zd3z]

This code contains a number of Cypress PSoC6 specific changes. Are they related to the new swap status partition or just details for implementing the Cypress chip? I'm going to try and get this running on NXP LPC55S69.

One of the requested changes is to split out the new swap status code from any of the Cypress-specific changes needed to use it. It'd be great if you have time to try and get this working on the LPC55S69, which is rather similar constraints on its flash. I had mostly been focusing on getting this running in the simulator, which is also a requirement for being able to merge this.

[elcritch]

One of the requested changes is to split out the new swap status code from any of the Cypress-specific changes needed to use it. It'd be great if you have time to try and get this working on the LPC55S69, which is rather similar constraints on its flash. I had mostly been focusing on getting this running in the simulator, which is also a requirement for being able to merge this.

That sounds good; given it's blocking most of my MCU's I can probably justify spending time on it. Many of the newer automotive rated MCU's seem to have ECC flash now so it'd be useful in the future.

[d3zd3z]

Many of the newer automotive rated MCU's seem to have ECC flash now so it'd be useful in the future.

Is 512-byte write/erase common? We've been trying to track what is in devices in #713, and it'd be nice if you have any better insight into what devices are really being used.

The code in this PR basically set set up to work with devices with small erase units (basically the same as the write size). At least the Psoc and NXP LPC devices are like that. The others with ECC generally seem to do the ECC across a smaller range of bytes, such as 8 bytes.

[elcritch]

Is 512-byte write/erase common? We've been trying to track what is in devices in #713, and it'd be nice if you have any better insight into what devices are really being used.

It seems to be the case for the NXP chips and maybe the TI chips. However, I have a couple of STM32H7 based boards (like NUCLEO-H755ZI-Q) that appear to have 32B write/128kB erase according to their flash manual. So likely those chips will need to use the current trailer method. It'd be wasteful but the upside is that those chips have 1-2k sectors at that 128k sector size (1-2MB) so in theory the trailer method should work?

The code in this PR basically set set up to work with devices with small erase units (basically the same as the write size). At least the Psoc and NXP LPC devices are like that. The others with ECC generally seem to do the ECC across a smaller range of bytes, such as 8 bytes.

It does seem more common, however, perhaps it'll need to be configured on a board-by-board case? I'm hoping to test this out more this week, but not sure if I'll be able get to it yet.

[d3zd3z]

@elcritch you may be interested in #949 which is working on making the slightly-larger write sizes workable.

[elcritch]

@elcritch you may be interested in #949 which is working on making the slightly-larger write sizes workable.

Thanks! I'm hoping to getting back to testing MCUBoot soon. The larger write would be helpful on some of these ECC flash units.

[d3zd3z]

@romanjoe Have you guys gathered any statistics on how much wear this change introduces, specifically to a fairly large device with 512-byte pages? It seems like this would result in a few thousand write/erase cycles on just a small number of page.

[github-actions]

This pull request 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 pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.