MCUboot get a wrong image header when using ext flash

[yang.hu]

Hi, 

I am using NCS 2.2.0, nRF5340.

A few days ago, i add NSIB to my project, but i can't upgrade MCUboot. I find some puzzled quetionns after reading the MCUboot code.

In loader.c, path ${NCS_ROOT}/bootloader/mcuboot/boot/bootutil/src/loader.c

static int
boot_validated_swap_type(struct boot_loader_state *state,
                         struct boot_status *bs)
{
    int swap_type;
    fih_int fih_rc = FIH_FAILURE;
    bool upgrade_valid = false;

#if defined(PM_S1_ADDRESS) || defined(CONFIG_SOC_NRF5340_CPUAPP)
    const struct flash_area *secondary_fa =
        BOOT_IMG_AREA(state, BOOT_SECONDARY_SLOT);
    struct image_header *hdr = (struct image_header *)secondary_fa->fa_off;
    uint32_t vtable_addr = 0;
    uint32_t *vtable = 0;
    uint32_t reset_addr = 0;
    /* Patch needed for NCS. Since image 0 (the app) and image 1 (the other
     * B1 slot S0 or S1) share the same secondary slot, we need to check
     * whether the update candidate in the secondary slot is intended for
     * image 0 or image 1 primary by looking at the address of the reset
     * vector. Note that there are good reasons for not using img_num from
     * the swap info.
     */

    if (hdr->ih_magic == IMAGE_MAGIC) {
        vtable_addr = (uint32_t)hdr + hdr->ih_hdr_size;
        vtable = (uint32_t *)(vtable_addr);
        reset_addr = vtable[1];
#ifdef PM_S1_ADDRESS
#ifdef PM_CPUNET_B0N_ADDRESS
        if(reset_addr < PM_CPUNET_B0N_ADDRESS)
#endif

> struct image_header *hdr = (struct image_header *)secondary_fa->fa_off;

It is ok when using internal flash but ext flash.

When i using ext flash, the image header should read from ext flash not 'secondary_fa->fa_off'.

At this point, it will generate erasing the secondary when upgrading target is not the first item later.

if (reset_value < min_addr || reset_value> (max_addr)) {
            BOOT_LOG_ERR("Reset address of image in secondary slot is not in the primary slot");
            BOOT_LOG_ERR("Erasing image from secondary slot");

            /* The vector table in the image located in the secondary
             * slot does not target the primary slot. This might
             * indicate that the image was loaded to the wrong slot.
             *
             * Erase the image and continue booting from the primary slot.
             */
            flash_area_erase(fap, 0, fap->fa_size);
            fih_rc = fih_int_encode(1);
            goto out;
        }

Is this question is true?

Best regards,

Yang Hu

[Einar Thorsrud]

Hi,

I do not see any issues here. Also, we use external flash extensively with MCUBoot in both SDK examples and reference designs, bot for nRF5340 and other devices. I see you have made other threads for specific issues so I suggest you continue in those and we close this (as it seems like it is just based on misunderstandings while reading the MCUboot code, if I am not mistaken).

[yang.hu]

Hi,

Thanks for your reply.

If i use internal flash,  after this line 'struct image_header *hdr = (struct image_header *)secondary_fa->fa_off;' , i can get the true image_header data, and IMAGE_MAGIC is hdr->ih_magic.

But if i use ext flash, after this line 'struct image_header *hdr = (struct image_header *)secondary_fa->fa_off;'  the hdr means nothing. The 'secondary_fa->fa_off' is only an address in ext flash which identify Image Header. Then, we should use ' flash_area_read()' to get the true data of Image Header.

This thread is Using a ext flash problem, and others threads is upgrade MCUboot problem.

If you think the two threads is the same issue, i will turn to other threads.

Best Regards,

Yang Hu

[yang.hu]

By the way, this problem only happen when NSIB is added.

I have a project that can upgrade application and not adding NSIB.

[Einar Thorsrud]

There is an issue when using secure boot (NSIB) on the nRF5340 with external flash in nRF Connect SDK 2.2.0 This is only triggered when using ISIB. In this case MCUboot assumes all images goes to the netcore for some reason. We are looking into this but I do not have a solution at the moment.

(A colleague of mine is looking into this and have a private case with a colleague of yours (case ID 301063)).