-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zephyr v3.4.0: MCUBoot doesn't clear the pending flag when configured to operate in RAM_LOAD mode (non-XIP). #1856
Comments
That is what it says, yes: https://github.com/mcu-tools/mcuboot/blob/main/boot/zephyr/Kconfig#L249 |
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) |
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. |
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
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:
The text was updated successfully, but these errors were encountered: