2408404_en-US

[#1]

Secure boot in imxrt1024..5A

I am trying to implement secure boot on the i.MX RT1024 EVK.

1. I have generated the private and public key pair using SPT.
2. I have a led_blinky.bin file, which is already a bootable image. It contains the FCFB block at offset 0x00, the IVT block at 0x1000, and the other required boot components.
3. In SPT, I selected Boot → Authenticated (HAB) and then selected the authentication key as IMG_1 + CSF1_1. After generating the signed image, I noticed that the FCFB block is no longer present. The binary now starts directly with the IVT.
4. However, when I use write_image_win.bat to write the image to the EVK (after erasing the flash), and then read the image back from flash, I can see that the FCFB block is present again. From what I understand, write_image_win.bat is creating/adding the FCFB block.

This leads to my main question:

Suppose I have my own bootloader and application firmware, and both already contain the required FCFB block. For production, I only want to sign the firmware; I do not want the signing process to modify or remove the existing FCFB block, and I also don't want the signing tool to actually write the image to the flash.

My concern is that signing the image through SPT appears to remove the FCFB block.

Am I misunderstanding the SPT signing process? What is the correct way to sign an already bootable image while preserving its existing FCFB block?

i.MXRT 102xRe: Secure boot in imxrt1024..5A

Hi @Abhay2080 ,

Thanks for your interest in NXP MIMXRT series!

Your observation is correct, and the behavior you are seeing is by design.

1. Why the FCFB disappears after signing

The signed output from SPT (_nopadding.bin) is defined as starting at the IVT — it never contains the FCFB. This is explicitly documented in the official SPT User Guide (Write Image section):

"The binary image must be in 'nopadding' form without the FCB block, as the FCB block is written in a separate step." — MCUXpresso Secure Provisioning Tool User Guide, Write Image section

This is not a tool bug. The BootROM reads the FCFB first — before HAB is even invoked — to initialize the FlexSPI controller. HAB authentication only covers the region starting from the IVT.  FCFB is architecturally outside the HAB signing scope.

2. Production solution: manual merge

SPT does not automatically preserve the FCFB in the signed binary output. The correct approach for producing a complete, programmer-ready image without using the Flashloader is to merge manually:

• Use SPT with Boot → Authenticated (HAB) to sign your image. Output: signed_nopadding.bin (starts at IVT, no FCFB).
• Extract the FCFB from your original bootable binary.
• Concatenate: final_image = fcfb_block + signed_nopadding.bin.
• Flash final_image using your production programmer.

Please check this post : NXP Community: RT1064 Signed & Encrypted bootloader – production JTAG flashing

Also, if you're familiar with the CST tool, it should allow you to specify the signature scope directly. However, I haven't tried this approach locally.

I hope this clarification is helpful to you!

Best regards,
Gavin