Zephyr build image(sample blinky application) not getting flash through NXP Secure Provisioning Tool V4.0 for i.MX RT 1166EVK

[vishnusudhan]

I am using NXP MCU Secure provisioning tool V4.0 to flash the zephyr based sample blink application , I could able to flash the sample code through JTAG (JLink Segger).

Now, I need to flash the application with zephyr using USB-HID/UART, so , I choose the NXP secure provisioning tool to flash the application image . When I try to select the required binary image (build with zephyr) to flash through secure provisioning tool V4.0 , I am getting **
error like bootable image not supported , image without header must be used
**
Is there any reference available how to remove header ? so I will try to flash the image without header . Also please refer , where I need to find the exact start address to flash the required image(layout) ?

[vishnusudhan]

I had tried few things as below on i.MX RT1060 EVK,

Tried to build the zephyr sample application using west build command for i.MX RT1060 EVK platform & could able to generate the required binary.
The same binary I could able to provide input to the Secure provisioning tool V4 & able to flash over USB & UART. Even with the SPT could able to sign using HAB (PKI management) with that binary image.

Same procedure I followed with the i.MX RT1160 EVK platform. I could not able to provide input on SPT V4, its showing error as "bootable image is not supported,image without header must be used" .

Kindly suggest how to overcome this problem?

[vishnusudhan]

In addition to above check, tried few checks on zephyr binary image with SPT

1. Removed boot header in the binary image from 0x00 to 0x2000 bytes(has FCB,IVT,BD,DCD) & try to provide input on SPT, now the SPT can able to recognize the image & able to built the image.
2. In Zephyr menuconfig option, can able to related boot header select/deselect option.
   a. If we select the boot header and built the image , the binary image creating with boot header from 0x00 to till 0x2000
   b. If we deselect the boot header option, the generated binary image from 0x00 to till 0x2000 filled with 0's & the SPT can't recognize the image(same issue: “image without header must be use").
   Kindly provide the suggestions for below query
   1. Is it fine to remove the header manually till 0x2000?
   2. In zephyr , how to remove the boot header completely(refer 2.b)?

[DerekSnell]

Hi @vishnusudhan ,

I am glad you found a manual workaround.

Is it fine to remove the header manually till 0x2000?

Your final boot image needs the header to properly boot. But if you are using SPT to generate and add that header to your image, yes you can manually remove the header from the Zephyr binary.

In zephyr , how to remove the boot header completely(refer 2.b)?

I would also try using Kconfig settings to do this, like you are looking into. But I do not have the specific steps required yet; this will require some investigation. Best regards

[vishnusudhan]

Hi @DerekSnell ,

Have you get any chance to investigate this issue further?

Is it possible to generate zephyr binary image without boot header(starting with application content).
Because in MCUXpresso IDE sample examples , if set XIP_BOOT_HEADER_ENABLE as 0. The Boot header image completely gets removed & only the application content alone getting generated & the SPT can able to recognize that.

Is the same way the zephyr binary can be generate(should start from application content) to provide input in the SPT?

[danieldegrasse]

Hi @vishnusudhan

To enable building a Zephyr image targeting the RT1166 EVK that does not have a boot header or any form of padding prior to the image, you may set the following configuration settings in your project's prj.conf:

# Produce a hex image, for convenience (not strictly required)
CONFIG_BUILD_OUTPUT_HEX=y
# Move image base address in flash from 0x30000000 to 0x30002000 to
# leave space for the boot header
CONFIG_FLASH_BASE_ADDRESS=0x30002000
# Remove NXP FlexSPI boot header
CONFIG_NXP_IMX_RT_BOOT_HEADER=n

Note that unless you provide DCD data to initialize the onboard SDRAM, you may need to change the RAM bank that the application targets to OCRAM. You may do so by adding a devicetree overlay file with the following contents to your project:

/ {
     chosen {
          zephyr,sram = &ocram;
    };
};

You can use this devicetree overlay file by passing the variable -DDTC_OVERLAY_FILE to west build (for more detail, see here)

The resulting hex file should work with SPT.

[vishnusudhan]

Hi @danieldegrasse

I tried the above mentioned changes in the MCUBoot (prj.conf), Now, I can able to detect the image in SPT & able to flash. After flashing the image , the board getting rebooting continuously upon trying to Jump to the first image slot(entering application).

1. If I flashed MCUBoot only (erased application) @30002000 location, can able to bootup the MCUBOOT successfully .
2. In application side , enabled boot option as MCUBoot bootloader support & flashed the application @30020000(slot0 location), now i am getting rebooting issue continuously.
3. If i try to remove the header as manually (first ,0x2000) in MCUBoot image(commented changes in MCUBOOT prj.conf file), its works fine & even application also bootup successfully.

Have you come across this kind of issue after adding the above changes? kindly suggest how to rectify this issue?

[DerekSnell]

Hi @vishnusudhan ,
I replicated the issue you saw with the MCU continually rebooting. We found that changing CONFIG_FLASH_BASE_ADDRESS caused further complications in MCUboot. We found another solution instead, and we have confirmed this works with MCUboot, and works with the OTA updates using mcumgr. This solution is to change the start address of the boot_partition in the device tree. For example:

	boot_partition: partition@2000 {
			label = "mcuboot";
			reg = <0x00002000 DT_SIZE_K(56)>;
		};
	};

I am listing the full steps here to replicate what I did, for the benefit of others who may want to do something similar. I am working with Zephyr v3.1.0 release. But I find MCUboot does not build for the MIMXRT1160-EVK yet (there are open PRs to fix this), so the attached
MCUboot_RT1160_SPT.zip includes a Kconfig file for MCUboot and this board. This Kconfig file also removes the boot header in the MCUboot image as discussed above. The ZIP also includes a devicetree overlay for this change of the boot_partition start address. These are the Kconfig changes I used:

# increase number of sectors for MCUboot to match slot partition size of 3MB
CONFIG_BOOT_MAX_IMG_SECTORS=4096

# enabled optimizations to fit in 64MB boot partition
CONFIG_SIZE_OPTIMIZATIONS=y

# Produce a hex image, for convenience (not strictly required)
CONFIG_BUILD_OUTPUT_HEX=y

# Remove NXP FlexSPI boot header to use with Secure Provisioning Tool
CONFIG_NXP_IMX_RT_BOOT_HEADER=n

Then I build MCUboot with the command:

west build -b mimxrt1160_evk_cm7 -d ..\..\mcuboot_RT1160 ..\bootloader\mcuboot\boot\zephyr --pristine  -- -DDTC_OVERLAY_FILE="./boards/mimxrt1160_evk_cm7_spt.overlay"

The MCUboot image built is included in the ZIP as zephyr_MCUboot.hex.
Then I use the MCUXpresso Secure Provisioning Tool (SPT) v4.0.1 to build the image file for SPT. Using the SPT, I found an easy option to include the DCD in the generated image. Our Zephyr support for our EVKs use the same DCD provided by the MCUXpresso SDK and our Config tools. The ROM bootloader uses that DCD to configure the hardware before any application like MCUboot or Zephyr app executes. With this DCD included, you no longer need the OCRAM overlay that Daniel suggested earlier. The steps for using SPT are:

• set the source image to the MCUboot application (bin or hex)
• include a custom DCD, the tool will default to this DCD file shown
• click the Build Image button

The generated file from SPT is zephyr_MCUboot_nopadding.bin in the ZIP attachment. I then setup the EVK and use SPT to program this file to the flash, with these steps:

• On MIMXRT1160-EVK, SW1 boot config DIP switches to Off-Off-Off-On
• Connect USB cable to J20 for USB Serial Downloader update. Power the EVK (or reset the EVK if already powered)
• In SPT, click the "Write Image" tab
• Click the "Write Image" button to program the file
• Reset SW1 DIP switches to Off-Off-On-Off to boot from flash
• Connect a USB cable to J11, and connect a terminal program to that Debug Console serial port
• Reset the EVK, and MCUboot will boot, but no application is loaded yet

Next I build the hello_world sample for MCUboot, and flash to the EVK using these steps:

west build -b mimxrt1160_evk_cm7 -d ..\..\mcb_hello_RT1160 samples\hello_world --pristine -- -DCONFIG_BOOTLOADER_MCUBOOT=y -DCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"bootloader/mcuboot/root-rsa-2048.pem\" 

west flash -d ..\..\mcb_hello_RT1160

This application file hello_world_for_MCUboot.bin is included in the ZIP.
After flashing, MCUboot will boot, find the hello_world image in Slot0, and boot that app:

*** Booting Zephyr OS build zephyr-v3.1.0  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: primary slot
I: Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
*** Booting Zephyr OS build zephyr-v3.1.0  ***
Hello World! mimxrt1160_evk_cm7

Let us know if that works for you. Best regards

[vishnusudhan]

@DerekSnell

Thanks for your detailed steps, I have tried the above mentioned changes. Its working fine now.

I have few query,

1. For this issue , the MCUBOOT partition gets change as 56k. In our case, it may required till 128k. shall i increase the boot partition size?
2. In case if i increase the boot partition , the respective slot partition starting address will change accordingly. that changes alone is enough to proceed further?

[DerekSnell]

Hi @vishnusudhan ,
Yes, that is right. If your build of MCUboot does not fit in the default size for a board, you will need to increase the size of the flash boot_partition to fit in the devicetree, and then adjust the starting addresses of the partitions that follow in the flash memory map.

Best regards

[vishnusudhan]

Hi @vishnusudhan , Yes, that is right. If your build of MCUboot does not fit in the default size for a board, you will need to increase the size of the flash boot_partition to fit in the devicetree, and then adjust the starting addresses of the partitions that follow in the flash memory map.

Best regards

@DerekSnell so , the above boot header reboots issue wont get affect right? if we increase the boot partition size? because you have provided optimization flag to fit the MCUBOOT into 64kb. if we increase MCUBOOT partition above 64kb . we can remove that flag & run the MCUBOOT? the solution for boot header issue wont get affect right?

[DerekSnell]

Hi @vishnusudhan ,
The issue with boot header addressed above, which was causing the reboots was related to the flash offset of 0x2000. The boot header is located from 0x0 to 0x1FFF, which is included in the Zephyr app when CONFIG_NXP_IMX_RT_BOOT_HEADER=y. Or can be added by SPT when CONFIG_NXP_IMX_RT_BOOT_HEADER=n. Then the application (which is MCUboot in your case) needs to start at flash offset 0x2000. Zephyr builds already do this when CONFIG_NXP_IMX_RT_BOOT_HEADER=y. For SPT with CONFIG_NXP_IMX_RT_BOOT_HEADER=n, we needed to change that offset of the boot_partition to 0x2000.

So yes, regardless of CONFIG_NXP_IMX_RT_BOOT_HEADER, you can change the size of the boot_partition to fit the size of MCUboot bootloader.

My example above, I selected CONFIG_SIZE_OPTIMIZATIONS=y to squeeze MCUboot into the existing boot_partition size. Another option, you can increase the boot_partition size to fit the bootloader with whatever optimization setting you prefer.

Best regards