topic I.MX RT1060EVA OTA mcuboot example: faulty image in i.MX RT Crossover MCUs

I.MX RT1060EVA OTA mcuboot example: faulty image

xuteng0 — Mon, 29 Jul 2024 04:49:39 GMT

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?

Re: I.MX RT1060EVA OTA mcuboot example: faulty image

gusarambula — Wed, 07 Aug 2024 22:52:25 GMT

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

Re: I.MX RT1060EVA OTA mcuboot example: faulty image

xuteng0 — Thu, 08 Aug 2024 04:58:23 GMT

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.

Re: I.MX RT1060EVA OTA mcuboot example: faulty image

diego_charles — Thu, 19 Sep 2024 21:34:23 GMT

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

Re: I.MX RT1060EVA OTA mcuboot example: faulty image

maxshaffer — Wed, 23 Apr 2025 04:57:24 GMT

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.