Add support of shared upgrade slot feature in simulator#2665
Add support of shared upgrade slot feature in simulator#2665DOAR-Infineon wants to merge 1 commit into
Conversation
d3zd3z
left a comment
d3zd3z
left a comment
There was a problem hiding this comment.
Overall, this looks really good. It isn't clear to me where this will get covered in CI tests. We might want to consider, in the future, whether we want a bit more coverage of some of the power-loss test cases in this configuration.
But this is really good for testing what we do have.
| | Mode | Supported | Scratch needed | Device | Notes | | ||
| |------|-----------|----------------|--------|-------| | ||
| | Overwrite-only | **Yes** | No | `PSOCEdgeE8xSpiFlash` | Simplest layout | | ||
| | Swap-using-scratch | **Yes** | Yes (1 sector) | `PSOCEdgeE8xSpiFlash` | Equal primary/secondary sizes | |
There was a problem hiding this comment.
Given that we're trying to deprecate swap-using-scratch, I wonder if we should have this line at all (or the scratch column). I suppose it is here for completeness.
DOAR-Infineon
force-pushed
the
fork/shared_upgrade_slot_support
branch
2 times, most recently
from
804654e to
2a725b9
Compare
Signed-off-by: INFINEON\DovhalA <artem.dovhal@infineon.com>
DOAR-Infineon
force-pushed
the
fork/shared_upgrade_slot_support
branch
from
e324503 to
162bd6e
Compare
| > If they differ, boot will print *"Cannot upgrade: slots are not | ||
| > compatible"* and refuse to swap. | ||
|
|
||
| ### Staggering the trailers |
There was a problem hiding this comment.
can you explain why this is needed? The MCUboot header https://github.com/mcu-tools/mcuboot/blob/main/boot/bootutil/include/bootutil/image.h#L166 includes uint32_t ih_load_addr; which gives the exact address to load to which maps to one image only
There was a problem hiding this comment.
To prevent the image header and trailers to colide with each other - to overcome the case when both headers and trailers are valid, but only 2nd application slot is programmed - in such case, during the MCUBoot flow (for multiimage) 1st application integrity will be broken and mcuboot gonna erase 1st application upgrade image slot, causing the second application image to be corrupted/erased.
There was a problem hiding this comment.
but it's not valid to have an update to image 2 without a valid image 1, MCUboot will not boot, given that it cannot boot, so the workflow here makes no sense
d3zd3z
dismissed
their stale review
Jamie's (nordicjcm)'s question needs to be addresses. They are apparently doing this without needing any staggering.
4 participants
Summary
Adds simulator device configurations and tests that validate the shared upgrade slot feature — a multi-image layout where multiple images share a single physical flash region for their secondary (upgrade) slots. This significantly reduces flash usage in systems where only one image is upgraded at a time.
Motivation
In the standard MCUboot multi-image configuration, each image requires its own dedicated secondary slot. For a 2-image system with 64 KB slots, this means 128 KB of flash reserved for upgrades. With the shared upgrade slot layout, both secondary slots overlap on the same physical SPI flash region, reducing upgrade flash to ~68 KB — a savings of ~47%.