mcuBoot multi-image

[mastupristi]

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

[Gavin_Jia]

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

[mastupristi]

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:

1. 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.)?

2. Is there something I need to explicitly set in the images or in MCUBoot config to satisfy the dependency checks?

3. 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

[mastupristi]

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