modules: mcuboot: enable support for RAMLOAD mode with revert

[danieldegrasse]

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]

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

Name	Old Revision	New Revision	Diff
mcuboot	mcu-tools/mcuboot@c8470fb	mcu-tools/mcuboot#2197	mcu-tools/mcuboot#2197/files

Additional metadata changed:

Name	URL	Submodules	West cmds	module.yml
mcuboot	✏

⛔ DNM label due to: 1 project with PR revision and 1 project with metadata changes

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

[danieldegrasse]

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]

This is not working. Do a build with sysbuild and flash using west flash so you have both images. If you run the image info command you get the following:

Slot 0:
    Active
    Confirmed
    Bootable

Slot 1:
    Bootable
    Pending
    Permanent

This state is invalid as when you reboot, it boots slot 0 again. You also cannot erase the update slot or transfer a new image because it thinks an upgrade is in progress when it is not

[danieldegrasse]

This is not working. Do a build with sysbuild and flash using west flash so you have both images. If you run the image info command you get the following:

Slot 0:
    Active
    Confirmed
    Bootable

Slot 1:
    Bootable
    Pending
    Permanent

This state is invalid as when you reboot, it boots slot 0 again. You also cannot erase the update slot or transfer a new image because it thinks an upgrade is in progress when it is not

How are you testing this? The sequence I'm using is the following:

• build using sysbuild, and flash. MCUBoot and image 0 are flashed.
• rebuild sample with CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="0.0.1+0", so the new SMP SVR application has a higher version
• upload the new zephyr.signed.bin to slot1 using mcumgr-client
• Mark the image as pending using mcumgr-client, and reset the board
• Verify that the new smp_svr application has booted, and that it will be reverted after a reboot (since it did not confirm itself)

[nordicjm]

Seems I did not do recover between tests, reproduction is build and flash, then upload the slot1 image without changing version, upgrade is bricked as image flag does nothing, new image is not booted, application cannot erase image because it is persistently marked as test

[nordicjm]

Then after, if you actually do erase the flash of the upgrade slot header, MCUboot shows no secondary image - good, MCUmgr shows no secondary image - good, and try to upload, it fails to upload because of "There is no free slot to place the image" ??? Assuming this is because the flags are still set in the main image but this also bricks updates

[nordicjm]

Actually a bit confused why a slot1 bin file is generated since the slot0 and slot1 bin files would be exactly the same for RAM load, hex makes sense but don't need the bin for slot1, something for me to look into why I did that

[danieldegrasse]

Seems I did not do recover between tests, reproduction is build and flash, then upload the slot1 image without changing version, upgrade is bricked as image flag does nothing, new image is not booted, application cannot erase image because it is persistently marked as test

Trying to reproduce this on my end- the RT1050 build only has bin files, so I'm doing something like the following:

• flash normally using west flash (populates slot0 with a confirmed image, and loads MCUBoot)
• load secondary confirmed image using JLinkExe at offset for slot1 partition (loading zephyr.slot1.signed.confirmed.bin, using loadfile build/smp_svr/zephyr/zephyr.slot1.signed.confirmed.bin 0x603c0000
• reset board, verify image0 still boots and image1 is present
• Rebuild with -DCONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION=\"0.0.1+0\" to set new version
• Upload image to slot 1 using mcumgr-client: mcumgr-client -d /dev/ttyACM0 upload build/smp_svr/zephyr/zephyr.signed.bin
• Mark the image for test mcumgr-client -d /dev/ttyACM0 test 8fe10b45d6b3eae2183c36e11caf736dbe558db8494ab238458bfcd70e5c092b
• Reset board, verify image boots once than is removed on next boot (since it doesn't confirm itself)

Are these reproduction steps right? Not sure if I'm missing something here

[nordicjm]

Build and flash, use a program to upload the secondary image without changing version (not jlink, upload using MCUmgr), mark it as test/confirmed, reboot, device state is stuck