mcuboot+application don't start on mimxrt1050_evk

[blemouzy]

Describe the bug

With default flash SPI partitions layout, flashing an application seems to erase mcuboot on mimxrt1050_evk.

Tested with Zephyr v3.7.0 and Zephyr main (39917ae).

To Reproduce

1. Flash mcuboot

cd bootloader/mcuboot/boot/zephyr/
echo "CONFIG_BOOT_SIGNATURE_TYPE_NONE=y" >> prj.conf
west build -b mimxrt1050_evk@hyperflash
west flash --runner=jlink --erase

==> mcuboot starts as expected:

*** Booting MCUboot v2.1.0-rc1-36-gfb2cf0ec3da3 ***
*** Using Zephyr OS build v3.7.0 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
W: Failed reading image headers; Image=0
E: Unable to find bootable image

2. Flash application

cd zephyr/samples/basic/blinky/
echo "CONFIG_BOOTLOADER_MCUBOOT=y" >> prj.conf
echo "CONFIG_MCUBOOT_GENERATE_UNSIGNED_IMAGE=y" >> prj.conf
west build -b mimxrt1050_evk@hyperflash
west flash --runner=jlink

==> nothing is printed on serial like application programming erased mcuboot.

Expected behavior

mcuboot and application start:

*** Booting MCUboot v2.1.0-rc1-36-gfb2cf0ec3da3 ***
*** Using Zephyr OS build v3.7.0 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: none
I: Bootloader chainload address offset: 0x100000
I: Jumping to the first image slot
*** Booting Zephyr OS build v3.7.0 ***
LED state: OFF
LED state: ON

Additional context

I made some tests and with the following flash SPI partition change, mcuboot and application start as expected:

zephyr/boards/nxp/mimxrt1050_evk/mimxrt1050_evk_mimxrt1052_hyperflash.overlay

partitions {
    compatible = "fixed-partitions";
    #address-cells = <1>;
    #size-cells = <1>;
    boot_partition: partition@0 {
        label = "mcuboot";
        reg = <0x00000000 DT_SIZE_M(1)>;
    };
    /* The MCUBoot swap-move algorithm uses the last 14 sectors
        * of the primary slot0 for swap status and move.
        */
    slot0_partition: partition@100000 {
        label = "image-0";
        reg = <0x00100000 DT_SIZE_M(3)>;
    };
    slot1_partition: partition@400000 {
        label = "image-1";
        reg = <0x00400000 DT_SIZE_M(3)>;
    };
    storage_partition: partition@700000 {
        label = "storage";
        reg = <0x00700000 DT_SIZE_M(57)>;
    };
};

I hope this is helpful.

EDIT: fix storage_partition partition size

[butok]

Hi @blemouzy

Going to order the board.
Are you using the IMXRT1050-EVKB board (https://www.nxp.com/part/IMXRT1050-EVKB)?

Meanwhile, could you try the the MCUBoot sysbuild sample:

• west build -p always -b mimxrt1050_evk --sysbuild samples/sysbuild/with_mcuboot
• west flash

[blemouzy]

Hi @butok

Are you using the IMXRT1050-EVKB board (https://www.nxp.com/part/IMXRT1050-EVKB)?

Yes (revision B1).

Meanwhile, could you try the the MCUBoot sysbuild sample:

* west build -p always -b mimxrt1050_evk --sysbuild samples/sysbuild/with_mcuboot

* west flash

Same issue.

[danieldegrasse]

Looking at this more, I suspect the issue might be a bit deeper, but related to the partition alignment. The datasheet for the S26KS512S hyperflash on the RT1050 claims erases may only be performed on 256 KB sectors, and the driver implementation aligns with this:

zephyr/drivers/flash/flash_mcux_flexspi_hyperflash.c

Line 513 in 6798064

if (offset % SPI_HYPERFLASH_SECTOR_SIZE) {

I believe the change in 03d1eab is probably the root cause here. We reduced the size of the mcuboot boot partition, which shifted the alignment of the image-0 and image-1 partitions to no longer be on 256KB boundaries. I suspect this breaks the flash loader algorithm debuggers use, since we cannot erase at the 128KB boundary.

I think the partition alignment @blemouzy proposed is right- we need all partitions to be aligned to a 256KB boundary, or I doubt we will be able to run upgrades correctly with MCUBoot.

[dleach02]

I posted a PR based on @blemouzy. In the sample suggested by @butok it worked on my board.

But if this is a 256KB alignment, seems like we really only need to bump the boot_partition size from 128 to 256?

[butok]

I posted a PR based on @blemouzy. In the sample suggested by @butok it worked on my board.

But if this is a 256KB alignment, seems like we really only need to bump the boot_partition size from 128 to 256?

Hi @danieldegrasse and @dleach02
For both mimxrt1050 qspi and hyperflash erase-block-size = 4096
If "S26KS512S hyperflash on the RT1050 claims erases may only be performed on 256 KB sectors" is true.
the device tree must be fixed to erase-block-size = DT_SIZE_K(256). Right?

[blemouzy]

But if this is a 256KB alignment, seems like we really only need to bump the boot_partition size from 128 to 256?

It looks fine (application starts) with 256 KiB boot_partition:

partitions {
	compatible = "fixed-partitions";
	#address-cells = <1>;
	#size-cells = <1>;
	boot_partition: partition@0 {
		label = "mcuboot";
		reg = <0x00000000 DT_SIZE_K(256)>;
	};
	slot0_partition: partition@40000 {
		label = "image-0";
		reg = <0x00040000 DT_SIZE_M(3)>;
	};
	slot1_partition: partition@340000 {
		label = "image-1";
		reg = <0x00340000 DT_SIZE_M(3)>;
	};
	storage_partition: partition@640000 {
		label = "storage";
		reg = <0x00640000 (DT_SIZE_M(57) + DT_SIZE_K(768))>;
	};
};

Note: is the following comment still relevant?

/* The MCUBoot swap-move algorithm uses the last 11 sectors
 * of the primary slot0 for swap status and move.
 */

Do we need the extra DT_SIZE_K(44) in slot0_partition?