Multiple SoCs have flash configurations unsupported by MCUboot

[d3zd3z]

Some newer devices have flash configurations that are not supported currently by MCUboot. This issue attempts to collect these in one place to help with the design of any solutions to handle this situation.

Known devices:

• LPC55S69, 512-byte writes, 512-byte erase
• PSOC6x, 512-byte writes, 512-byte erase
• SAM-X70, 16-byte writes, 128k-byte erase

[jameswalmsley]

STM32H7 (43) 32 bytes write, 128K erase

A further complication with STM32H7 is that the internal flash has an integrated ECC. Writing to the same flash word twice has a high probability of causing an ECC error, and if it's a double ECC error then a read results in a bus error. Does MCUboot rely on being able to write to the same flash word more than once?

[utzig]

Does MCUboot rely on being able to write to the same flash word more than once?

No, it only writes once to any "word΅ which is the alignment size for the flash supplied by the OS.

I have MCUboot working on a PoC level on STM32H7. This required changing both BOOT_MAX_ALIGN and BOOT_MAGIC_SZ to 32. The boot_img_magic array had to be changed as well (one copy in bootutil_misc.c, one in image.py, one in Zephyr's mcuboot.c, maybe more) because it's only 16 bytes which is less than the alignment. All in all it's simple changes, but just changing BOOT_MAX_ALIGN for everyone isn't backwards compatible.

Is there any good reason to not make BOOT_MAX_ALIGN configurable? A user could set it to e.g. 32, which would then cause the magic to be padded to 32 bytes. (Or 16, or 512?). Everyone else would keep it at 8 and keep compatibility.

[jameswalmsley]

I'd like to confirm also that I have been running MCUBoot on STM32H7 for 12 months now. We made the same changes as you described above. We did find its possible to get an ECC error if we lost power during an image swap, and so MCUBoot would cause a hard-fault during swap-resume. We solved this by: 1. Using a watchdog if an ECC fault is triggered. 2. If boot-reason is due to a watchdog in the bootloader then we erase the image, and scratch areas. 3. We provide a recovery mode, where we wait for a repair image over DFU. 4. Just before we boot the application we set a flag to say the firmware was booted. If the firmware triggers WD then we don't cause recovery. 5. If firmware crashes multiple times without a power-cycle, recovery is triggered. (We also count the number of watchdog resets). Due to the possibility of getting an ECC error during resume, we have disabled resuming of partial image-swaps.. Interruption of image swaps will cause a recovery. Probably sounds a bit complex, but this has worked really well for our application. We went for catching ECC faults with a watchdog and recovery mode to ensure that all eventualities are covered, and no matter what happens we can recover the device. Best J

[nvlsianpu]

I have MCUboot working on a PoC level on STM32H7. This required changing both BOOT_MAX_ALIGN and BOOT_MAGIC_SZ to 32

@d3zd3z @utzig What is your opinion about making this configurable?

[utzig]

@d3zd3z @utzig What is your opinion about making this configurable?

If someone is gonna tackle it, the person has to fix bootutil, the simulator, imgtool, mcumgr and newt, maybe the integrations in the supported Oses, and maybe other stuff which I fail to remember. Probably a bit more work that it might seem at first, but I don't think there are any big technical impediments.

[d3zd3z]

The other thing that is going to come up is that adding simulator support for this type of configure is going to point out the "rare" or "occasional" failures, and we'll need to actually figure out a way to fix them. Having some percentage of upgrade devices need recovery really isn't something I'd consider acceptable for a regular option.

We do have a completely different swap strategy that is under development that is intended for devices where the writes are larger (and typically use ECC), however this more requires the erase size to be fairly small. Having 8k erases would waste quite a bit of flash for these sectors.

However, the existing swap code should be assuming that each write block can only be written once, so this is probably a corner case bug, perhaps because of the larger write size.

@jameswalmsley Your description of how you handled ECC errors on STM32H7 by involving the watchdog did not fill me with joy. So I came up with a different way to solve the problem, by trapping ECC errors and returning them as -EIO in the flash API. Normally a bus fault can't be trapped, but there is a way around that.

I've opened zephyrproject-rtos/zephyr#33140 with a description of the problem, my proposed solution, and I link to some code that shows that it can work. The code fiddles with some architectural registers, so it would be good to get some feedback from someone who knows more about how those registers interact with the rest of the system.