Zephyr v3.4.0: MCUBoot doesn't clear the pending flag when configured to operate in RAM_LOAD mode (non-XIP).

[akamath-enphase]

When MCUBoot is configured in non-XIP, RAM-load mode (without swap), the function, context_boot_go() (defined in mcuboot/boot/bootutil/src/loader.c) behaves differently from the same function defined for the XIP/RAM_LOAD case. This is done via a conditional compilation statement (#if !defined(MCUBOOT_DIRECT_XIP) && !defined(MCUBOOT_RAM_LOAD))

The differing behaviour prevents the "pending" flag in the RAM-load case from being cleared, since the image is only verified and then loaded into RAM.

As a result, the following issues are observed:

1. If the pending flag for a given slot is set by the application (or, via MCUMgr), the flag will not be cleared by MCUBoot, which will prevent that slot from being used again for a download by MCUMgr.
2. The image in a given slot will be loaded (if it has a higher version than the other slot) without the need for it to be marked for an upgrade (pending/confirmed), since MCUBoot will only check for validity and versions.

[nordicjm]

The image in a given slot will be loaded (if it has a higher version than the other slot) without the need for it to be marked for an upgrade (pending/confirmed), since MCUBoot will only check for validity and versions.

That is what it says, yes: https://github.com/mcu-tools/mcuboot/blob/main/boot/zephyr/Kconfig#L249

[akamath-enphase]

I see, but the installation of the image, in my opinion, should be controlled via the pending/confirmed flags, otherwise, a reset alone would cause the new image to be loaded. Can a change in the behaviour in RAM_LOAD mode be considered, so that it is similar to XIP-mode/normal mode (run from internal flash)?

[nordicjm]

I see, but the installation of the image, in my opinion, should be controlled via the pending/confirmed flags, otherwise, a reset alone would cause the new image to be loaded. Can a change in the behaviour in RAM_LOAD mode be considered, so that it is similar to XIP-mode/normal mode (run from internal flash)?

No, that would be completely rewriting it and changing behaviour, breaking existing users, and actually RAM LOAD works the same as XIP without revert works (i.e. without marking the image for test)

[edholmes2232]

What is the recommended way to upgrade a potentially bad image with RAM Loading? If I write a bad image but the header and trailer are still valid, with a greater version number than the image in primary, it will just keep trying to boot the faulty image indefinitely.