mcuBoot multi-image

mastupristi — Wed, 23 Jul 2025 20:26:46 GMT

hi,

I am trying to modify the mcuboot_opensource example for RT1020 to support two images.
I ended up with both mcuboot and ota_mcuboot_basic handling 2 images. However despite being able to get an image written to the secondary slots, then mcuboot never makes the copy to the primary slot.
Could you tell me what steps I should follow?

best regards

Re: mcuBoot multi-image

Gavin_Jia — Thu, 24 Jul 2025 06:12:26 GMT

Hi @mastupristi ,

Thanks for your interest in NXP MIMXRT series!

To test, you need to program the mcuboot_opensource project first, then, write the signed mcuboot_basic project to 0x60040000, and the second image to 0x60240000. Note that when signing, the two images use different version numbers.

Best regards,
Gavin

Re: mcuBoot multi-image

mastupristi — Thu, 24 Jul 2025 08:22:26 GMT

Hi @Gavin_Jia

Thank you for your answer. I think there may have been a misunderstanding regarding my setup. Let me clarify my current situation and what I’m experiencing with MCUBoot.
I want to use MCUBoot on RT1020 to manage two images, each with its own pair of slots (primary/secondary):

I have configured MCUBoot for two images (standard multi-image, e.g. second-stage-bootloader + main-app), each with its own primary and secondary slot.
I have programmed secondary slot of second-stage-bootloader image with valid, signed firmware images.
On boot, MCUBoot does not copy the images from the secondary to the primary slot, and it does not boot any image.
The boot log seems to recognize the images (see below), but it never completes the swap or boot:

hello sbl. Bootloader Version 2.1.0 Non-optimal sector distribution, slot0 has 254 usable sectors (256 assigned) but slot1 has 256 assigned Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 Secondary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3 Boot source: none Image index: 0, Swap type: test Non-optimal sector distribution, slot0 has 254 usable sectors (256 assigned) but slot1 has 256 assigned Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 Boot source: none Unable to find bootable image

It looks like MCUBoot detects the images, but fails the image dependency check, and ends up without a bootable image.
I am not sure if I have misconfigured some option, or if the images (or image trailers) are missing a required field for the dependencies mechanism.

My questions:

What could cause MCUBoot to skip the swap/copy phase even when a valid image is present in the secondary slot (with good magic, etc.)?
Is there something I need to explicitly set in the images or in MCUBoot config to satisfy the dependency checks?
Can I get some hint on how to debug which dependency check is failing?

I already confirmed both images are signed, with different version numbers.
The flash layout seems correct and matches the MCUBoot config.

Any advice or steps to debug this would be greatly appreciated.

Here some details:

in mcux_config.h added:

#define CONFIG_UPDATEABLE_IMAGE_NUMBER 2

in flash_partition.h modified:

#define BOOT_FLASH_ACT_UPD 0x60040000 #define BOOT_FLASH_CAND_UPD 0x60140000 #define BOOT_FLASH_ACT_APP 0x60240000 #define BOOT_FLASH_CAND_APP 0x60340000

in flash_partition.c modified:

const char *boot_image_names[MCUBOOT_IMAGE_NUMBER] = {"UPD", "APP"}; struct flash_area boot_flash_map[MCUBOOT_IMAGE_SLOT_NUMBER] = { /* Image 0; slot 0 - Main Application Primary Slot */ {.fa_id = 0, .fa_device_id = FLASH_DEVICE_ID, .fa_off = BOOT_FLASH_ACT_UPD - BOOT_FLASH_BASE, .fa_size = BOOT_FLASH_CAND_UPD - BOOT_FLASH_ACT_UPD, .fa_name = "UPD_PRIMARY"}, /* Image 0; slot 1 - Main Application Secondary Slot */ {.fa_id = 1, .fa_device_id = FLASH_DEVICE_ID, .fa_off = BOOT_FLASH_CAND_UPD - BOOT_FLASH_BASE, .fa_size = BOOT_FLASH_CAND_UPD - BOOT_FLASH_ACT_UPD, .fa_name = "UPD_SECONDARY"}, #if 2 == MCUBOOT_IMAGE_NUMBER /* Image 1; slot 0 - Main Application Primary Slot */ {.fa_id = 2, .fa_device_id = FLASH_DEVICE_ID, .fa_off = BOOT_FLASH_ACT_APP - BOOT_FLASH_BASE, .fa_size = BOOT_FLASH_CAND_APP - BOOT_FLASH_ACT_APP, .fa_name = "APP_PRIMARY"}, /* Image 1; slot 1 - Main Application Secondary Slot */ {.fa_id = 3, .fa_device_id = FLASH_DEVICE_ID, .fa_off = BOOT_FLASH_CAND_APP - BOOT_FLASH_BASE, .fa_size = BOOT_FLASH_CAND_APP - BOOT_FLASH_ACT_APP, .fa_name = "APP_SECONDARY"}, #endif };

modified flash_api.c

int flash_area_id_from_multi_image_slot(int image_index, int slot) { switch (slot) { case 0: case 2: return FLASH_AREA_IMAGE_PRIMARY(image_index); case 1: case 3: return FLASH_AREA_IMAGE_SECONDARY(image_index); default: return -1; /* flash_area_open will fail on that */ } }

I couldn't find any tutorials on how to add more images to the flash map, so everything I did I did following what I thought was right.

So what are the steps I should have followed?

best regards

Max

Re: mcuBoot multi-image

mastupristi — Thu, 24 Jul 2025 15:29:11 GMT

Hi @Gavin_Jia

I may have understood the problem.

Version 2.1.0 of mcuboot (bundled in SDK 25.06) has at least one probable bug that plagues my case.

in fact if you see

https://github.com/mcu-tools/mcuboot/blob/v2.1.0/boot/bootutil/src/loader.c#L1883C1-L1884C76

the image number is checked against the slot number. Very strange.

This was corrected in commit eb942067989569f9cf319b087d0bb16b16effd86 which is one of 333 commits between version 2.1.0 and 2.2.0 (a lot of fix are included)

I would like to ask you to update mcuboot to the latest version as soon as possible

best regards

Max

topic Re: mcuBoot multi-image in MCUXpresso SDK

mcuBoot multi-image

Re: mcuBoot multi-image

Re: mcuBoot multi-image

My questions:

Re: mcuBoot multi-image