mcuboot
mcuboot copied to clipboard
Add support for RAMLOAD mode with revert
This PR adds support for ram loading mode with revert to MCUBoot. This mode functions similar to direct XIP mode with revert- MCUBoot will now refuse to load an image to RAM unless the image trailer indicates that the image is confirmed or marked pending.
If multiple images are valid, the one with the highest version will be selected for ramloading, so downgrade is still not possible.
This PR also adds the BLINFO_FLASH_AREA TLV tag to the bootloader boot record, which records the flash area ID in the boot record. This can be used by systems like Zephyr to determine which slot was booted, which is useful for marking an image as confirmed or querying status
Note that this PR includes the commit from #2196, as I validated support for this feature using the RT1050-EVK. If desired, I can rebase this to drop that commit
I would like it to be possible to downgrade images while using the RAM load mode
@nordicjm PR should be updated- commit adding BLINFO_FLASH_AREA has been dropped, and the DFU subsystem has been updated in the Zephyr side PR to map the running slot number to a flash ID per your suggestion. Docs have also been added
@nordicjm PR should be updated- commit adding
BLINFO_FLASH_AREAhas been dropped, and the DFU subsystem has been updated in the Zephyr side PR to map the running slot number to a flash ID per your suggestion. Docs have also been added
@nordicjm friendly ping- hoping to try and move this forwards now that the Zephyr release is complete and merge window is open
https://github.com/zephyrproject-rtos/zephyr/pull/85254 needs a rebase and this could do with one too. Have given this a try on an nrf52840dk and it does not work using the sample from the zephyr PR:
*** Booting MCUboot v2.1.0-rc1-262-g2fc7c0ebcce7 ***
*** Using Zephyr OS build v4.0.0-4467-g59da4986e437 ***
I: Starting bootloader
I: Primary slot: version=0.0.0+0
I: Image 0 Secondary slot: Image not found
D: Erasing faulty image in the primary slot.
I: No slot to load for image 0
E: Unable to find bootable image
Switching back to normal RAM load mode works:
*** Booting MCUboot v2.1.0-rc1-262-g2fc7c0ebcce7 ***
*** Using Zephyr OS build v4.0.0-4467-g59da4986e437 ***
I: Starting bootloader
I: Primary slot: version=0.0.0+0
I: Image 0 Secondary slot: Image not found
I: Image 0 RAM loading to 0x20006000 is succeeded.
I: Image 0 loaded from the primary slot
I: Bootloader chainload address offset: 0x20006000
I: Image version: v0.0.0
I: Jumping to the first image slot
*** Booting Zephyr OS build v4.0.0-4467-g59da4986e437 ***
[00:00:00.000,457] <inf> smp_sample: build time: Mar 12 2025 09:01:31
Seems to be ./smp_svr/zephyr/zephyr.signed.confirmed.hex that is faulty, the ./smp_svr/zephyr/zephyr.slot1.signed.confirmed.hex build file works
Right I see the issue, the nrf52840dk overlay here would need to be changed to delete slot0 and slot1 then re-create them with the same slot sizes
Right I see the issue, the nrf52840dk overlay here would need to be changed to delete slot0 and slot1 then re-create them with the same slot sizes
Makes sense- I'll make that change here so that the sample can be tested on the nrf52840dk
Updated this PR and the Zephyr side. Just a note- I tested this using the following sequence:
- flash
smp_svrsample built with sysbuild (west build -p always -b mimxrt1050_evk//hyperflash -T samples/subsys/mgmt/mcumgr/smp_svr/sample.mcumgr.smp_svr.ram_load_revert.serial) - rebuild, and load the new
zephyr.signed.bincreated for thesmp_svrapplication usingmcumgr-client upload - mark the new application as testable using
mcumgr-client test - reset the target, and verify the new image is loaded in test mode (and will revert if it does not confirm)
As far as sequencing goes, would it make sense to just combine this PR and #2196? Not sure if this will ease the process of getting both in, since they both need sequencing with Zephyr