MCUBOOT_OVERWRITE_ONLY_KEEP_BACKUP flag is not exposed to config mechanism

[willdean]

MCUBOOT contains a flag  MCUBOOT_OVERWRITE_ONLY_KEEP_BACKUP that stops it erasing a big chunk of the start of the secondary image after an update.

We would like to set this flag, because we do delta-updates against the secondary image over a very low-rate data link, and it's useful to have the previous version of our code still available on the device.

However, there is no method to set this flag via the usual configuration mechanisms (e.g. sysbuild.conf), so we have had to add it to mcuboot_config.h within the SDK code.

Obviously we would prefer not to have to modify the SDK source code -- could this option please be exposed to normal configuration?

[AHaug]

Hi,

I might need some more details from you w.r.t what your goal is:

Out of the box, the DFU procedure uses swap for the DFU procedure and swaps the contents of the primary and secondary slot when doing an update. If you've marked the new image as "confirm", MCUboot will boot from the new image within the primary application slot on the new reboot, but it does not remove the contents of the secondary flash before you upload yet another update image candidate to the MCU.

This means that the old firmware is still on the MCU. What you can't do however, is to revert back to the old firmware due to downgrade protection, since the old image is an older image than what is currently running. See https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_downgrade_protection.html.

Does this change anything for you w.r.t the original case description? If not, I'm not sure what parts of the images you're trying to support, so please feel free to fill in the missing gaps

The support for delta-updates are also AFAIK restricted to modem firmware updates and not for firmware updates

Kind regards,
Andreas

[willdean]

Thanks Andreas.

We are running with SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y, so there is no "swap" going on, the secondary image is simply written into the primary image location.

By default, MCU boot then erases both the "header" and the "trailer" of the secondary image.  The code to do this is around lines 1952-1972 in loader.c (in 2.9.0)

When it erases the "header", it actually erases a large part of the start of the secondary image.   

We don't want our secondary image damaged like this, because our remote update process involves updating the secondary image very carefully and very slowly, and we are able to re-use parts of the previous secondary image, as long as the bootloader hasn't erased them.

Erasing the "trailer" is essential, because that prevents MCUBOOT trying to repeat the update.  We're fine with that.

The feature to preserve the secondary image is ALREADY in MCUBOOT - that's the MCUBOOT_OVERWRITE_ONLY_KEEP_BACKUP flag, which is checked on line 1952 of loader.c.   It stops the "header" erase but leaves the "trailer" erase.

So I am not asking for any new functionally, merely a way to turn on the functionality which is already in MCUBOOT, but which is not currently exposed by Zephyr/Sysbuild.

Thanks.

[AHaug]

Thank you for expanding. Its more clear now.

willdean said:

We are running with SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y

Noted.

willdean said:

The feature to preserve the secondary image is ALREADY in MCUBOOT - that's the MCUBOOT_OVERWRITE_ONLY_KEEP_BACKUP flag, which is checked on line 1952 of loader.c.   It stops the "header" erase but leaves the "trailer" erase.

So I am not asking for any new functionally, merely a way to turn on the functionality which is already in MCUBOOT, but which is not currently exposed by

I've only seen it here https://github.com/nrfconnect/sdk-mcuboot/blob/3a25855215a2cfc64c3f0e2dba3ada3f11df7816/boot/bootutil/src/loader.c#L1969 with no reference to any KConfig defintions for how to set it. I will have to dive deeper into the SDK tomorrow to see if I can find how to enable it.

I'll get back to you before the weekend.

Kind regards,
Andreas

[willdean]

Please don't spend time on this - there is currently no way to enable it other than by modifying the MCUBOOT source.   

I don't actually know if adding this facility would be a job for Nordic, or a job for whoever owns the Zephyr parts of MCUBOOT.

[AHaug]

Hi,

willdean said:

there is currently no way to enable it other than by modifying the MCUBOOT source.   

This is what I've landed on as well.

willdean said:

I don't actually know if adding this facility would be a job for Nordic, or a job for whoever owns the Zephyr parts of MCUBOOT.

Nordic contributes and maintains MCUboot, so if it is a feature request you want to add in you can do so by reaching out to your Nordic Regional Sales Director (let me know if you need their contact information).

Otherwise, there is the option to modify your own fork of the nRF-MCUboot fork that is within nRF Connect SDK as you say, but I understand that you don't want to do this if you wish to keep your version of the nRF-MCUboot in the SDK pristine.

Kind regards,
Andreas