Add support for RAMLOAD mode with revert #2197

danieldegrasse · 2025-02-05T22:02:49Z

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

de-nordic · 2025-02-05T23:03:13Z

boot/bootutil/include/bootutil/boot_status.h

@@ -119,6 +119,7 @@ extern "C" {
 #define BLINFO_MAX_APPLICATION_SIZE_IMAGE_2 0x07
 #define BLINFO_MAX_APPLICATION_SIZE_IMAGE_3 0x08
 #define BLINFO_MAX_APPLICATION_SIZE_IMAGE_4 0x09
+#define BLINFO_FLASH_AREA           0x0A


Isn't this already done vis BLINFI_RUNNING_SLOT?

RUNNING_SLOT gives the index of the active slot, but for the MCUBoot subsystem code in Zephyr we need access to the flash area ID. For example, Slot 0 on the RT1050 has flash area ID 1 (because the MCUBoot partition has area ID 0)

We could change the value set by RUNNING_SLOT, but I wanted to avoid breaking any APIs so I added this. It was needed in order to get features like confirming a running image working with MCUBoot

You have to convert from running slot to flash area ID in your application itself, as img mgmt does e.g. https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/grp/img_mgmt/src/zephyr_img_mgmt.c#L128 the flash area ID has no meaning between different applications e.g. application could have bootloader slot split into 2 in future, now you open the wrong thing

Ahh, ok. I was testing this with the DFU subsystem- so would it make sense to call img_mgmt_flash_area_id here in boot_fetch_active_slot: https://github.com/zephyrproject-rtos/zephyr/pull/85254/files#diff-696b0049cfb981ee66f0191ccaf755f25a632c35b86da7dc1d739c3de8a60ed3L78? Otherwise, functions like marking the image as pending weren't working, since boot_fetch_active_slot is really fetching the flash area ID of the active slot, not the slot number.

That returns either:

#define BOOT_PRIMARY_SLOT 0 #define BOOT_SECONDARY_SLOT 1

Which should then be used to check if it's slot0 if 0 or slot1 if 1 (it doesn't care about additional images since they are not "running"),

de-nordic · 2025-02-05T23:11:58Z

boot/bootutil/src/boot_record.c

+    if (!rc) {
+        rc = boot_add_data_to_shared_area(TLV_MAJOR_BLINFO,
+                                          BLINFO_FLASH_AREA,
+                                          sizeof(fap->fa_id), (void *)&fap->fa_id);
+    }


Three issues:

i am trying to disentangle MCUboot from Flash Map API as this entanglement blocks us from freely modifying both Zephyr and MCUboot, and so the usage of flash area id and flash_area within MCUboot is going to be phased out. There is also problem with flash area functions having different prototypes and flash_area objects having different members, depending on a system.

area id in MCUboot and Zephyr app that got boot does not have to be the same; it is enough if there is storage before images that gets removed with overlay in mcuboot and numbering will differ

mcuboot should not directly access flash_area objects, rather use getter functions like flash_area_get_id.

Ok, makes sense. I have no issue changing this, really all I want is a workable solution for indicating the flash area that Zephyr's MCUBoot subsystem should use when marking an image as confirmed. Is there an API for mapping the boot slot number back to a flash area we can use?

nordicjm

can use retention for running image slot so that commit should be dropped, can you also add a section to the documentation similar to direct-xip with revert https://github.com/mcu-tools/mcuboot/blob/main/docs/design.md?plain=1#L452 and add a file here https://github.com/mcu-tools/mcuboot/tree/main/docs/release-notes.d with a small note on adding this (see other files in directory for examples and for maximum line length and style, think it's 64 characters or so

nordicjm · 2025-02-06T08:58:05Z

boot/zephyr/Kconfig

+	bool "Enable the revert mechanism in ramload mode"
+	depends on BOOT_RAM_LOAD
+	help
+	  If y, enables the revert mechanism in ramload similar to the one in


Suggested change

If y, enables the revert mechanism in ramload similar to the one in

If y, enables the revert mechanism in ram-load similar to the one in

djr-spectrummfg · 2025-02-26T22:51:24Z

I would like it to be possible to downgrade images while using the RAM load mode

danieldegrasse · 2025-02-28T00:33:18Z

@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

danieldegrasse · 2025-03-11T15:55:29Z

@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 friendly ping- hoping to try and move this forwards now that the Zephyr release is complete and merge window is open

nordicjm · 2025-03-12T09:02:19Z

zephyrproject-rtos/zephyr#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

nordicjm · 2025-03-12T09:04:57Z

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

nordicjm · 2025-03-12T09:10:59Z

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

danieldegrasse · 2025-03-12T14:11:31Z

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

… boards Add ram load overlays for nrf52840dk and mimxrt1050_evk boards. These ram load overlays are moved from the Zephyr in tree smp_svr sample, to enable ram load support for multiple platforms. Signed-off-by: Daniel DeGrasse <[email protected]>

Add support for revert mode when using ramloading. This includes the same restrictions as revert mode with direct-xip, namely that an image must have a valid BOOT_MAGIC value in order for mcuboot to attempt to load it. Signed-off-by: Daniel DeGrasse <[email protected]>

Add documentation and release notes entry for ram-load with revert support in mcuboot. Signed-off-by: Daniel DeGrasse <[email protected]>

danieldegrasse · 2025-03-12T14:38:18Z

Updated this PR and the Zephyr side. Just a note- I tested this using the following sequence:

flash smp_svr sample 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.bin created for the smp_svr application using mcumgr-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)

danieldegrasse · 2025-03-12T14:39:57Z

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

danieldegrasse requested review from nordicjm, de-nordic and davidvincze as code owners February 5, 2025 22:02

de-nordic reviewed Feb 5, 2025

View reviewed changes

danieldegrasse mentioned this pull request Feb 5, 2025

modules: mcuboot: enable support for RAMLOAD mode with revert zephyrproject-rtos/zephyr#85254

Open

nordicjm reviewed Feb 6, 2025

View reviewed changes

danieldegrasse force-pushed the feature/ramload-revert branch from 7641f6a to ea55e12 Compare February 28, 2025 00:32

danieldegrasse requested a review from d3zd3z as a code owner February 28, 2025 00:32

danieldegrasse added 3 commits March 12, 2025 09:28

doc: update documentation for mcuboot to document ram-load with revert

c6b373d

Add documentation and release notes entry for ram-load with revert support in mcuboot. Signed-off-by: Daniel DeGrasse <[email protected]>

danieldegrasse force-pushed the feature/ramload-revert branch from ea55e12 to c6b373d Compare March 12, 2025 14:31

nordicjm approved these changes Mar 13, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for RAMLOAD mode with revert #2197

Add support for RAMLOAD mode with revert #2197

danieldegrasse commented Feb 5, 2025

de-nordic Feb 5, 2025

danieldegrasse Feb 5, 2025

nordicjm Feb 6, 2025

danieldegrasse Feb 24, 2025

nordicjm Feb 25, 2025

de-nordic Feb 5, 2025

danieldegrasse Feb 5, 2025

nordicjm left a comment

nordicjm Feb 6, 2025

djr-spectrummfg commented Feb 26, 2025

danieldegrasse commented Feb 28, 2025

danieldegrasse commented Mar 11, 2025

nordicjm commented Mar 12, 2025 •

edited

Loading

nordicjm commented Mar 12, 2025

nordicjm commented Mar 12, 2025

danieldegrasse commented Mar 12, 2025

danieldegrasse commented Mar 12, 2025

danieldegrasse commented Mar 12, 2025

	If y, enables the revert mechanism in ramload similar to the one in
	If y, enables the revert mechanism in ram-load similar to the one in

Add support for RAMLOAD mode with revert #2197

Are you sure you want to change the base?

Add support for RAMLOAD mode with revert #2197

Conversation

danieldegrasse commented Feb 5, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nordicjm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

djr-spectrummfg commented Feb 26, 2025

danieldegrasse commented Feb 28, 2025

danieldegrasse commented Mar 11, 2025

nordicjm commented Mar 12, 2025 • edited Loading

nordicjm commented Mar 12, 2025

nordicjm commented Mar 12, 2025

danieldegrasse commented Mar 12, 2025

danieldegrasse commented Mar 12, 2025

danieldegrasse commented Mar 12, 2025

nordicjm commented Mar 12, 2025 •

edited

Loading