modules: mcuboot: enable support for RAMLOAD mode with revert #85254

danieldegrasse · 2025-02-05T23:15:23Z

This PR adds support for RAMLOAD mode with revert in MCUBoot, and enables a testcase for it with the mcumgr subsystem. RAMLOAD mode with revert functions similar to the direct xip mode with revert- MCUBoot will not ramload an image that is not confirmed or marked pending.

~~This PR also modifies the method of getting the active slot number when using ramload modes- we need to query the flash area ID, not the active boot slot for use with mcuboot boot utilities~~

zephyrbot · 2025-02-05T23:16:19Z

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff

✅ All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

danieldegrasse · 2025-02-05T23:21:28Z

Note: this PR requires mcu-tools/mcuboot#2197 from MCUBoot. It also contains commits from #85096, because I validated this support on the RT1050-EVK

nordicjm · 2025-06-30T09:53:42Z

subsys/dfu/boot/mcuboot.c

+	case 1:
+		fa_id = FIXED_PARTITION_ID(SLOT1_PARTITION);
+		break;


needs #if here too

Added- thanks. What will we need to do on the MCUBoot side to synchronize this? I think this change will have to go in when we update MCUBoot to include mcu-tools/mcuboot#2197 since we are moving the overlays as well

nordicjm · 2025-06-30T09:54:09Z

Build sample with CONFIG_MCUMGR_GRP_IMG_ALLOW_ERASE_PENDING=n, flash to device, then without changing any Kconfigs or anything or rebuilding just upload the slot1 image using MCUmgr with any supported tool from file zephyr.slot1.signed.confirmed.bin and reboot - at this point the device will boot from slot 0 not slot 1 as it should according to the flags, then try uploading an image or erasing the slot using MCUmgr, you will get an error that there is no free slot to place the image, and your device is "bricked" because you can no longer load a firmware update to it (without erasing the flash with a debugger, that is)

Ahh ok- now this makes sense, thank you- I've made the following change in this push, should fix it:
diff --git a/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c b/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c
index 5333d651c9f..1860269d87f 100644
--- a/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c
+++ b/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c
@@ -332,7 +332,8 @@ img_mgmt_slot_in_use(int slot)
        int active_slot = img_mgmt_active_slot(image);

 #if !defined(CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP) && \
-       !defined(CONFIG_MCUBOOT_BOOTLOADER_MODE_RAM_LOAD)
+       !defined(CONFIG_MCUBOOT_BOOTLOADER_MODE_RAM_LOAD) && \
+       !defined(CONFIG_MCUBOOT_BOOTLOADER_MODE_RAM_LOAD_WITH_REVERT)
        enum img_mgmt_next_boot_type type = NEXT_BOOT_TYPE_NORMAL;
        int nbs = img_mgmt_get_next_boot_slot(image, &type);
I believe we just want to always allow erasing a pending/confirmed image if it is inactive- otherwise the user can flash two images that are both confirmed, and effectively brick their device

Great, is working now! One outstanding issue then looks good

d3zd3z

The change looks good. Once mcuboot has moved to a supporting version, I can give an approval.

d3zd3z · 2025-07-11T16:26:47Z

west.yml

@@ -23,6 +23,8 @@ manifest:
      url-base: https://github.com/zephyrproject-rtos
    - name: babblesim
      url-base: https://github.com/BabbleSim
+    - name: mcuboot


I have merged 2197 into mcuboot, so once this makes it into the Zephyr module, we can directly refer to that.

Great- I think we will need to be careful with synchronization here- the MCUBoot side change moves some overlay files into the MCUBoot repo that were previously defined here (used for the ramload sample). So I think that these changes (or a subset) will be needed with the PR that bumps the mcuboot manifest revision.

d3zd3z · 2025-07-11T16:27:34Z

modules/Kconfig.mcuboot

+	  from there. The image must be linked to execute from RAM, the address that it is copied
+	  to is specified using the load-addr argument when running imgtool.
+	  This option automatically selectes MCUBOOT_BOOTLOADER_NO_DOWNGRADE as it is not possible
+	  to swap back to older version of the application.


This is a little ambiguous to me, since the revert does kind of go back to an older version of the application. Not sure how to word it more clearly, though.

Yeah, that is true. Perhaps

This option automatically selectes MCUBOOT_BOOTLOADER_NO_DOWNGRADE as MCUBoot will automatically select the highest revision of the application to boot. Note however that MCUBoot will select an older revision of the application if the booted revision does not mark itself as confirmed.

MCUMgr ram load support was hardcoding the overlay file for the nrf52840dk. To make this support generic, move the _ram_load overlay file to the MCUBoot repository, as part of the mcuboot application. Signed-off-by: Daniel DeGrasse <[email protected]>

MCUBoot RAMLOAD mode relies on CONFIG_XIP=n, but FLASH_MCUX_FLEXSPI_XIP y-selects this symbol. Disable CONFIG_FLASH_MCUX_FLEXSPI_XIP for the case where we are using MCUBoot ramload mode. Signed-off-by: Daniel DeGrasse <[email protected]>

Add support for using the ramload mode of MCUBoot on the mimxrt1050_evk Signed-off-by: Daniel DeGrasse <[email protected]>

Add Kconfigs for RAMLOAD_WITH_REVERT mode in MCUBoot. This mode works in a manner similar to DIRECT_XIP_WITH_REVERT- namely, mcuboot will only boot an image that is either confirmed or marked as pending. If both images are confirmed, mcuboot will still select the one with the higher version, so downgrading is not possible using this mode. Signed-off-by: Daniel DeGrasse <[email protected]>

Add BOOT_RAM_LOAD_REVERT as a defined Kconfig to the whitelist Signed-off-by: Daniel DeGrasse <[email protected]>

danieldegrasse · 2025-07-30T16:18:28Z

Updated now that Zephyr's copy of MCUBoot includes the relevant ramload support

JarmouniA · 2025-07-30T16:32:22Z

share/sysbuild/image_configurations/MAIN_image_default.cmake

@@ -39,6 +39,11 @@ if(SB_CONFIG_BOOTLOADER_MCUBOOT)
    set_config_bool(${ZCMAKE_APPLICATION} CONFIG_MCUBOOT_BOOTLOADER_MODE_RAM_LOAD y)
    set_config_bool(${ZCMAKE_APPLICATION} CONFIG_XIP n)
    set_config_int(${ZCMAKE_APPLICATION} CONFIG_FLASH_SIZE 0)
+  elseif(SB_CONFIG_MCUBOOT_MODE_RAM_LOAD_WITH_REVERT)
+    # RAM load mode requires XIP be disabled and flash size be set to 0


Unrelated to the core of the PR, do you know why RAM_LOAD mode requires XIP=n, but SINGLE_APP_RAM_LOAD does not?

I don't, no- not familiar with SINGLE_APP_RAM_LOAD. @nordicjm do you know why this is the case?

An oversight probably

@edersondisouza

XIP is orthogonal to SINGLE_APP_RAM_LOAD - it simply loads the image to RAM. If the image was linked to run from the area in the RAM it is going to be loaded, it can use XIP.

XIP is orthogonal to SINGLE_APP_RAM_LOAD - it simply loads the image to RAM. If the image was linked to run from the area in the RAM it is going to be loaded, it can use XIP.

Can you perhaps clarify this in the Kconfig help text, I think it's a very important point that will help many users.

XIP is orthogonal to SINGLE_APP_RAM_LOAD - it simply loads the image to RAM. If the image was linked to run from the area in the RAM it is going to be loaded, it can use XIP.

that is not consistent with what the Kconfig does:

help This option allows the kernel to operate with its text and read-only sections residing in ROM (or similar read-only memory). Not all boards support this option so it must be used with care; you must also supply a linker command file when building your image. Enabling this option increases both the code and data footprint of the image.

so XIP is execute from flash, non-XIP is execute from RAM

samples/subsys/mgmt/mcumgr/smp_svr/sample.yaml

When signing for ramload mode, respect the write alignment size setting. This is required when creating a confirmed image, as the BOOT_MAGIC value changes based on the alignment size in use. Signed-off-by: Daniel DeGrasse <[email protected]>

Prefer flashing the confirmed image when one is created with CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE. This way, the west runner will flash this image over the signed image if it exists. Signed-off-by: Daniel DeGrasse <[email protected]>

…cies CONFIG_FLASH_MCUX_FLEXSPI_XIP should also be disabled when using MCUBoot ramload mode with revert support. Signed-off-by: Daniel DeGrasse <[email protected]>

Much like in RAMLOAD mode, RAMLOAD_WITH_REVERT requires that mcuboot subsystem fetch bootloader information via the retention subsystem. Signed-off-by: Daniel DeGrasse <[email protected]>

boot_fetch_active_slot needs to map the slot number to a flash ID, as this is what the DFU subsystem expects when interacting with the flash partition. Signed-off-by: Daniel DeGrasse <[email protected]>

We should not block erasing pending images when using ramload with revert mode, because uploading multiple confirmed images with the same version would brick the device (preventing future FW updates). Update the dependencies of img_mgmt_slot_in_use to account for this. Signed-off-by: Daniel DeGrasse <[email protected]>

Add testcase to build mcuboot and smp_svr application using ramload with revert mode Signed-off-by: Daniel DeGrasse <[email protected]>

sonarqubecloud · 2025-08-01T17:17:17Z

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

zephyrbot added area: Build System area: Continuous Integration area: Sysbuild area: MCUBoot area: mcumgr area: DFU Device Firmware Upgrade area: Samples Samples platform: NXP NXP area: Coding Guidelines Coding guidelines and style labels Feb 5, 2025

zephyrbot requested review from 57300, carlescufi, d3zd3z, de-nordic, dleach02, fabiobaltieri, jeremybettis, jfischer-no, kartben, keith-zephyr, nashif, nordicjm, simhein, stephanosio and tejlmand February 5, 2025 23:16

zephyrbot assigned nordicjm Feb 5, 2025

zephyrbot added manifest manifest-mcuboot DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Feb 5, 2025

nordicjm reviewed Jun 30, 2025

View reviewed changes

danieldegrasse force-pushed the feature/mcuboot-ramload-revert branch from aa6490d to 0c5ec1d Compare July 1, 2025 15:28

d3zd3z reviewed Jul 11, 2025

View reviewed changes

danieldegrasse added 5 commits July 30, 2025 12:15

samples: subsys: mgmt: mcumgr: add support for ramload on mimxrt1050_evk

c9f27d1

Add support for using the ramload mode of MCUBoot on the mimxrt1050_evk Signed-off-by: Daniel DeGrasse <[email protected]>

scripts: ci: exempt BOOT_RAM_LOAD_REVERT from checks

28790dc

Add BOOT_RAM_LOAD_REVERT as a defined Kconfig to the whitelist Signed-off-by: Daniel DeGrasse <[email protected]>

danieldegrasse force-pushed the feature/mcuboot-ramload-revert branch from 0c5ec1d to 1b596bf Compare July 30, 2025 16:18

github-actions bot removed manifest manifest-mcuboot DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Jul 30, 2025

JarmouniA reviewed Jul 30, 2025

View reviewed changes

samples/subsys/mgmt/mcumgr/smp_svr/sample.yaml Show resolved Hide resolved

danieldegrasse added 7 commits August 1, 2025 11:51

soc: nxp: flexspi_xip: Update FLASH_MCUX_FLEXSPI_XIP ramload dependen…

8b90114

…cies CONFIG_FLASH_MCUX_FLEXSPI_XIP should also be disabled when using MCUBoot ramload mode with revert support. Signed-off-by: Daniel DeGrasse <[email protected]>

dfu: mcuboot: update dependencies for RAMLOAD_WITH_REVERT

8c46a99

Much like in RAMLOAD mode, RAMLOAD_WITH_REVERT requires that mcuboot subsystem fetch bootloader information via the retention subsystem. Signed-off-by: Daniel DeGrasse <[email protected]>

dfu: boot: mcuboot: fix boot_fetch_active_slot

c4f2cb7

boot_fetch_active_slot needs to map the slot number to a flash ID, as this is what the DFU subsystem expects when interacting with the flash partition. Signed-off-by: Daniel DeGrasse <[email protected]>

samples: mgmt: mcumgr: add testcase for ramload with revert

bb8c665

Add testcase to build mcuboot and smp_svr application using ramload with revert mode Signed-off-by: Daniel DeGrasse <[email protected]>

danieldegrasse force-pushed the feature/mcuboot-ramload-revert branch from 1b596bf to bb8c665 Compare August 1, 2025 16:51

nordicjm approved these changes Aug 5, 2025

View reviewed changes

de-nordic approved these changes Aug 5, 2025

View reviewed changes

fabiobaltieri merged commit 7765485 into zephyrproject-rtos:main Aug 5, 2025
31 checks passed

JarmouniA mentioned this pull request Aug 5, 2025

drivers: flash: stm32 xspi flash read with memcopy when executing #93762

Open

danieldegrasse deleted the feature/mcuboot-ramload-revert branch August 7, 2025 00:13

modules: mcuboot: enable support for RAMLOAD mode with revert #85254

modules: mcuboot: enable support for RAMLOAD mode with revert #85254

Uh oh!

Conversation

danieldegrasse commented Feb 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zephyrbot commented Feb 5, 2025 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danieldegrasse commented Feb 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nordicjm commented Jun 30, 2025

Uh oh!

d3zd3z left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danieldegrasse Jul 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danieldegrasse commented Jul 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sonarqubecloud bot commented Aug 1, 2025

Quality Gate passed

Uh oh!

Uh oh!

Uh oh!

danieldegrasse commented Feb 5, 2025 •

edited

Loading

zephyrbot commented Feb 5, 2025 •

edited by github-actions bot

Loading

danieldegrasse Jul 11, 2025 •

edited

Loading