I.MX RT1060EVA OTA mcuboot example: faulty image

[xuteng0]

I'm running the evkmimxrt1060_ota_mcuboot_client_enet example with the default SBL from the evkmimxrt1060_mcuboot_opensource example on the EVA board using MCUXpresso version 11.10.0. I followed the readme files for both examples but encountered an issue where the bootloader treated the signed binary as faulty.

The serial log shows the following:

hello sbl.
Disabling flash remapping function
Bootloader Version 1.10.0
Primary slot: version=1.0.0+0
Image 0 Secondary slot: Image not found
Erasing faulty image in the primary slot.

after further investigation, I found in the "boot_select_or_erase" function

    if (active_swap_state->magic != BOOT_MAGIC_GOOD ||
        (active_swap_state->copy_done == BOOT_FLAG_SET &&
         active_swap_state->image_ok  != BOOT_FLAG_SET)) {
        //print status
        BOOT_LOG_INF("magic: 0x%lx, copy_done: 0x%lx, image_ok: 0x%lx",
                     (unsigned long)active_swap_state->magic,
                     (unsigned long)active_swap_state->copy_done,
                     (unsigned long)active_swap_state->image_ok);
        /*
         * A reboot happened without the image being confirmed at
         * runtime or its trailer is corrupted/invalid. Erase the image
         * to prevent it from being selected again on the next reboot.
         */
        BOOT_LOG_DBG("Erasing faulty image in the %s slot.",
                     (active_slot == BOOT_PRIMARY_SLOT) ? "primary" : "secondary");
        rc = flash_area_erase(fap, 0, flash_area_get_size(fap));
        assert(rc == 0);

        flash_area_close(fap);
        rc = -1;
    }

"state" was read to

magic: 0x3, copy_done: 0x3, image_ok: 0x3

I'm using the imgtool and the private key provided with the SDK. Here's my script for signing the binary:

python3 ../sign_tool/imgtool.py sign \
    --key ../sign_tool/sign-rsa2048-priv.pem \
    --align 4 \
    --header-size 0x0400 \
    --pad-header \
    --slot-size 0x200000 \
    --max-sectors 800 \
    --version "1.0" \
    binaries/evkmimxrt1060_ota_mcuboot_client_enet.bin \
    binaries/app_binary_SIGNED.bin

Any idea what might be going wrong?

[maxshaffer]

I was running into the same issue while loading a signed firmware image into the primary slot (address 0x6004000) with a Segger JLink. When signing an image with imgtool, you need to include --pad --confirm in the argument list. This is actually described in the readme for the MCUBoot example application (see Important Note). These options are not needed when signing firmware upgrade images that are intended to be transferred in an OTA process.

[gusarambula]

Hello Xuteng,

Are you still having trouble running the evkmimxrt1060_ota_mcuboot_client_enet and evkmimxrt1060_mcuboot_opensource examples? Do the examples run correctly with the default configuration from respective readme documents?

Regards,
Gustavo

[xuteng0]

Hi,

Yes, I am still encountering issues. The two examples are built without any modifications. Interestingly, I can build and debug the evkmimxrt1060_ota_mcuboot_client_example at address 0x60000000 without the bootloader. However, I am still unable to use the bootloader to load the app.

[diego_charles]

Hi @xuteng0 

My apologies for the delayed response, due to internal backlog. 

How are you flashing both SBL and target image?

Have you tried writting both using MCUXPresso secure provisioning tool ?

I just want to be sure that you where not losing any header or information from the target image.

Best regards, 

Diego