i.MXRT106x HAB closed boot fail, HAB log stops at AUTHENTICATION_STATUS, non‑standard IVT entry poin Background: I am working on HAB signature for i.MXRT106x, using NXP‑MCUBootUtility developed by 痞子衡. When I load my firmware binary into this tool, it reports: **Cannot find valid interrupt vector table address from bootable file header**. After inspecting the binary with hex editor: - The IVT entry point is `0x20209401`, while the image load base address is `0x20208000`, corresponding to file offset `0x1400`. - This code segment is identical to the boot‑related bootdata flow up to offset `0x2000`. - Normally the IVT entry should point to the reset vector address (reference example points to offset `0x2005`). But in my firmware, IVT entry points to offset `0x1400`. I suspect this is the root cause of the tool parsing failure. Further research on CST workflow: I understand the high‑level logic of CST signing: find a free block within the firmware, set the IVT CSF pointer to this location, use standard CSF template, and modify the `[Authenticate Data]` block section to configure the start address and size range for signature verification. My firmware is a complete bootable image containing FCB, IVT, DCD and BootData, and it boots normally on hardware without HAB closure. I configured my CSF block as: Blocks=0x20208000 0x1000 0x126c0 "my_firmware.bin" Also updated certificate paths accordingly. I ran CST v3.00.01 command: cst.exe -i .\input_resign.csf -o sig.bin The CST execution finished without errors and generated `sig.bin`. Comparing the output against original binary, there are exactly 2 changes: 1. CSF pointer field inside IVT at offset `0x1018` is updated. 2. CSF signature data is appended at offset `0x136c0`. When I flash this signed image to hardware: 1. With HAB not closed (SEC_CONFIG not closed), firmware runs perfectly. 2. After burning SRK fuse bits and closing HAB, the firmware fails to boot. I dumped HAB log from memory address `0x2020523c` with length 256 bytes via JTAG, and the log content is shown below: -----------------------------------------------------------------------------------------
| Log Entry | Description
-----------------------------------------------------------------------------------------
0x00010002: BOOTMODE_INTERNAL
0x000200cc: SEC_CONFIG_CLOSED
0x00030001: DIR_BT_DIS_VALUE1
0x00040000: BT_FUSE_SEL_VALUE0
0x00050000: PRIM_IMAGE_SELECT
0x00060008: PRIM_BOOTDEVICE_FLEXSPI_NOR
0x00070000: DEVICE_INIT_CALL
0x000700f0: DEVICE_INIT_PASS
0x00090000: AUTHENTICATION_STATUS **My questions:** 1. Where is the actual HAB event code? According to references, HAB authentication pass/fail should generate explicit event codes. But my log stops at `AUTHENTICATION_STATUS` with no follow‑up event entry. How can I determine whether HAB authentication succeeded or failed? 2. I tried `blhost` tool, but I cannot find any HAB log read command working on i.MXRT1061. Is there another method to read full HAB status? 3. Is my signing workflow valid? My image uses non‑standard IVT entry point (points to offset `0x1400` instead of reset vector offset `0x2005`). Can such an image be properly HAB‑signed with CST? Additional IVT header bytes at offset `0x1000`: D1 00 20 40 01 94 20 20 00 00 00 00 80 90 20 20
20 90 20 20 00 90 20 20 00 00 00 00 00 00 00 00
00 80 20 20 80 99 01 00 00 00 00 00 00 80 20 20
80 99 01 00 52 44 49 52 00 00 00 00 E4 B8 21 20
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 D2 00 08 41 CC 00 04 04 CST tool version: 3.00.01 Re: i.MXRT106x HAB closed boot fail, HAB log stops at AUTHENTICATION_STATUS, non‑standard IVT entry Hi @eleven ,
Thank you for the update. First, I think we should confirm whether the first byte of boot.bin is an FCB or an IVT. If it is an FCB, there may still be an alignment issue.
In addition, this guide should be helpful during the process of reading and interpreting HAB fault codes: https://community.nxp.com/t5/i-MX-Security/HAB-event-in-a-Closed-i-MX-chip/ta-p/1120239
If you are still unable to pinpoint the root cause of the problem, using MCUBootUtility to generate an HAB signature directly and then running a binary diff might be another way to cross-verify the results.
Best regards, Gavin Re: i.MXRT106x HAB closed boot fail, HAB log stops at AUTHENTICATION_STATUS, non‑standard IVT entry Hi Gavin, Thank you very much for your detailed reply. I think I did not describe my test setup completely in my original post. I have already tried adjusting the Blocks configuration as you suggested. I tested both: Blocks = 0x20208000 0x1000 0x126c0 "my_firmware.bin" and splitting into multiple block entries to authenticate starting from IVT through to the end of firmware: Blocks = 0x20209000 0x0 0x40 "boot.bin",\ 0x20209080 0x80 0xf80 "boot.bin",\ 0x2020a000 0x1000 0x11c00 "boot.bin" My intention was to authenticate starting from the IVT and cover all the way to the end of application code. However, the boot behaviour remained unchanged after these changes. I am using MCUBootUtility v6.5.1. Both its built‑in boot log analysis and manual JTAG memory dump give exactly the same log result. Also, I understand that the minimum boot offset for NOR is 0x1400. What I wanted to clarify is: my IVT entry points to boot‑related code, not the typical reset vector located at offset 0x2005 as seen in reference examples. Thanks again for your guidance. I will run further tests using sdphost to gather more debug information. Hopefully I can get more clues from that. Best regards, eleven Re: i.MXRT106x HAB closed boot fail, HAB log stops at AUTHENTICATION_STATUS, non‑standard IVT entry Hi @eleven ,
Based on your IVT data, CST configuration, and ROM log, I've identified some potential issues.
1. CST [Authenticate Data] Blocks address/offset mismatch (primary issue)
From your image, BootData.start = 0x20208000 and IVT.self = 0x20209000 establish the mapping: file offset 0x1000 corresponds to memory address 0x20209000 , not 0x20208000 .
The CST Blocks syntax is "file" . Your current line:
Blocks = 0x20208000 0x1000 0x126c0 "my_firmware.bin" ← address/offset misaligned by 0x1000
makes CST sign the data at file offset 0x1000 , while HAB on the device verifies memory at 0x20208000 (= file offset 0). The two are offset by 0x1000, so the signature can never match. This exactly explains "boots when Open, fails when Closed": in Open mode a HAB verification failure is only logged (non-fatal), whereas in Closed mode it blocks execution.
Fix :
(sign from IVT): Blocks = 0x20209000 0x1000 0x126c0 "my_firmware_prepared.bin"
Also ensure the IVT.csf field (offset 0x1018) is pre-filled with the final CSF address 0x2021b6c0 (= 0x20208000 + 0x136c0) before running CST, then sign, then append. Do not modify any signed byte after signing (IVT/BootData/DCD are all inside the signed range); doing so will also break verification.
Q1: Where is the HAB event code? How to tell pass/fail?
What you read from 0x2020523c is the ROM boot log, not the detailed HAB event log. On RT10xx each entry is packed into a single 32-bit word as (event_id<<16) | parameter , with the parameter in the low byte.
For the detailed failure reason, call the HAB ROM API: report_status(&config,&state) and report_event(status,index,event,&bytes) . decode per HAB4 API Reference Manual, Appendix A
Q2: blhost can't read the HAB log — any other method?
blhost talks to the Flashloader, not directly to the BootROM. The i.MXRT BootROM serial-download stage supports only SDP (use sdphost ). Options:
Recommended: call the HAB API from your application in the Open state to read/print status and events.
Dump 256 bytes from 0x2020523c via JTAG (ROM log); or use MCUBootUtility v6.3 (sdphost loads the flashloader, then blhost read-memory) for automatic parsing.
Important: When Closed and verification fails, the ROM never jumps to your application, so an in-app report_event cannot run. The standard flow must therefore be — confirm HAB_SUCCESS /no events in the Open state first, then burn SEC_CONFIG to close.
Q3: Can a non-standard IVT entry (offset 0x1400) be HAB-signed?
Yes — this is not the cause. For NOR boot the i.MXRT BootROM's minimum offset is 0x1400 (0x2000 is only a recommended value).
Best regards, Gavin
Re: i.MXRT106x HAB closed boot fail, HAB log stops at AUTHENTICATION_STATUS, non‑standard IVT entry Sorry for bothering you again, but this issue is critical for me. I could clearly observe HAB authentication errors using the sdphost command. Then I dumped the early memory region via JTAG, and found none of the firmware content was present in memory. Further testing showed that even the official demo projects shipped with NXP‑MCUBootUtility fail HAB signature when configured as NON‑XIP. Only XIP‑based images work successfully. This result surprised me a lot. I suspect there might be a mistake in my eFuse register configuration. My board does not have boot‑mode DIP switches, so I only programmed boot_cfg to 0x1A and burned the SRK fuses (please refer to the attached screenshot). QQ截图20260903101741.pngQQ截图20260903101741.png I am a beginner in this area and may have made some simple mistakes. I would appreciate any corrections or suggestions. Looking forward to your reply, thank you very much. Re: i.MXRT106x HAB closed boot fail, HAB log stops at AUTHENTICATION_STATUS, non‑standard IVT entry Hi @eleven ,
Your observation — even the official demo fails HAB when built as Non-XIP, while XIP works — seems to points to this root cause: https://www.cnblogs.com/henjay724/p/18111727
RT1050/1060 "Non-XIP + HAB" BootROM limitation On these two earliest devices, the BootROM reserves part of the OCRAM (notably 0x20280000–0x202BFFFF ) and does not open it to HAB authentication; other RT devices don't have this limit. Your image loads into OCRAM ( 0x20208000 ), so it boots with HAB off but fails verification with HAB on, and the firmware is never copied into memory. This is independent of your CSF/Blocks, which is why earlier changes had no effect.
If Non-XIP is required: avoid the reserved OCRAM region and use external SDRAM instead. Alternatively, according to the guide in the link above, the image must be strictly confined to the HAB recognition area.
On the fuses (screenshot):
With no boot-mode DIP switches, standalone boot requires BT_FUSE_SEL = 1; otherwise the boot configuration is undefined.
And please verify your BOOT_CFG1=0x1A and Conf0=0x40 bit-by-bit against the RT1060 RM Fusemap in your use case. Fuses are OTP (write-once) — proceed carefully.
Best regards, Gavin
查看全文
