sysflash: Correct ALL_AVAILABLE_SLOTS when MCUBOOT is not image 2 #444
Conversation
…image 2 Consider an nRF5340 application with the following sysbuild config: ``` SB_CONFIG_BOOTLOADER_MCUBOOT=y SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y SB_CONFIG_SECURE_BOOT_APPCORE=y SB_CONFIG_SECURE_BOOT_NETCORE=y SB_CONFIG_NETCORE_APP_UPDATE=y SB_CONFIG_MCUBOOT_NRF53_MULTI_IMAGE_UPDATE=y SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y ``` In this case, we have a total of 3 updatable images (app, net, mcuboot). `MCUBOOT_IMAGE_NUMBER = 2` (i.e. `CONFIG_UPDATEABLE_IMAGE_NUMBER = 2`), as the app secondary partition is reused for MCUBoot secondary. `CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER = 2` as the net core image has index 1. In this case, we should fall through to the definition of `ALL_AVAILABLE_SLOTS` that caters for 2 updatable images.
ball-hayden
force-pushed
the
pm-sysflash-netcore
branch
from
dbf1826 to
5458fb4
Compare
|
There was a problem hiding this comment.
not sure what this is trying to fix but it does not look valid, there are 2 images which the application sees, that is application and network core, for MCUboot itself it has it's own update slot, and that is already handled by this code in the same file:
#if CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER != -1
#ifdef CONFIG_NCS_IS_VARIANT_IMAGE
#define MCUBOOT_S0_S1_SLOTS PM_S0_ID, PM_MCUBOOT_SECONDARY_ID,
#else
#define MCUBOOT_S0_S1_SLOTS PM_S1_ID, PM_MCUBOOT_SECONDARY_ID,
#endif
#else
#define MCUBOOT_S0_S1_SLOTS
#endif
...
static inline uint32_t __flash_area_ids_for_slot(int img, int slot)
{
static const int all_slots[] = {
ALL_AVAILABLE_SLOTS
MCUBOOT_S0_S1_SLOTS
};
return all_slots[img * 2 + slot];
};
therefore the change here does not make sense
|
Thank you @nordicjm. Please see https://devzone.nordicsemi.com/f/nordic-q-a/113100/nrf5340-mcuboot-issue-with-multi-image-update-when-sb_config_secure_boot_appcore-is-enabled/537541 for reproduction steps for the issue this is trying to solve. Without the change, This is because the conditions on line 34 hold ( |
I cannot replicate this, taking so as can be seen, all 3 images are present and set |
|
Let me expand some macros to demonstrate. Our desired end result is the following, as we have 2 images to update with MCUboot - the app image (image number 0) and the net image (image number 1) - and the MCUboot image itself (image number 2): static inline uint32_t __flash_area_ids_for_slot(int img, int slot)
{
static const int all_slots[] = {
PM_MCUBOOT_PRIMARY_ID, PM_MCUBOOT_SECONDARY_ID,
PM_MCUBOOT_PRIMARY_1_ID, PM_MCUBOOT_SECONDARY_1_ID,
PM_S0_ID, PM_MCUBOOT_SECONDARY_ID,
};
return all_slots[img * 2 + slot];
};From In the application image, Separately, If we expand We get: #if (2 == 1) || (2 == 2 && 2 != -1)
This falls through to
This leaves us with static inline uint32_t __flash_area_ids_for_slot(int img, int slot)
{
static const int all_slots[] = {
PM_MCUBOOT_PRIMARY_ID, PM_MCUBOOT_SECONDARY_ID,
PM_S0_ID, PM_MCUBOOT_SECONDARY_ID,
};
return all_slots[img * 2 + slot];
};This results in MBUboot looking at the MCUBoot secondary slot while deciding whether it should update the net core, rather than looking at |
Using Please try with You should see that the process looks like it succeeds, but if you observe the MCUBoot logs you will see that image 1 (the net core image) did not swap when it should have, and the version printed by the net core will not have changed. |
|
It looks like our main disagreement is over the value of forces this to
If I set this to 3, as you suggest, I get the following compilation error: Compiler ErrorThis makes sense, as there are no flash slots for image 2 - image 2 is MCUboot, so should be sharing the other partitions, as you've said earlier. It's worth calling out that This means some of the functions from |
Yes. The whole thing does not make sense. I was very confused. I'm still very confused. The indirection is massive, and it took me several days to come to the proposed solution. |
|
@ball-hayden this looks like an issue on DFU application side - as reverse of staging image for update made the difference. |
|
I'm glad you've been able to see the issue @nvlsianpu. I still feel like from the application image the images are being incorrectly reported, but I'm happy to accept suggestions for different approaches here. |
|
For context, I've used both the nRF Connect app (on iOS and Android) and https://pypi.org/project/smpclient/ while debugging this. The higher-level MCUMgr Image Group definitely thinks it has set both image 0 and 1 to the test slot, but when MCUBoot is reading the image trailers it finds that image 0 is set to test, but image 1 is not. |
|
@ball-hayden Issue is somewhere in libraries used by the application. I confirmed this with Nordic verification team. Known workaround is sequence of image activation you already discovered. |
|
We will take action for fixing the bug. |
Consider an nRF5340 application with the following sysbuild config:
In this case, we have a total of 3 updatable images (app, net, mcuboot).
MCUBOOT_IMAGE_NUMBER = 2(i.e.CONFIG_UPDATEABLE_IMAGE_NUMBER = 2), as the app secondary partition is reused for MCUBoot secondary.CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER = 2as the net core image has index 1.In this case, we should fall through to the definition of
ALL_AVAILABLE_SLOTSthat caters for 2 updatable images.