背景：我正在使用痞子衡开发的 NXP‑MCUBootUtility 为 i.MXRT106x 开发 HAB 签名。当我将固件二进制文件加载到该工具中时，它报告：**无法从可引导文件头中找到有效的中断向量表地址**。
使用十六进制编辑器检查二进制文件后：
- IVT 入口点为 `0x20209401`，而映像加载基地址为 `0x20208000`，对应于文件偏移量 `0x1400`。
- 此代码段与启动相关的启动数据流相同，直到偏移量 `0x2000`。
- 通常情况下，IVT 条目应指向复位向量地址（参考示例指向偏移量 `0x2005`）。但在我的固件中，IVT 入口点指向偏移量 `0x1400`。我怀疑这是工具解析失败的根本原因。
对CST工作流程的进一步研究：
我理解 CST 签名的高级逻辑：在固件中找到一个空闲块，将 IVT CSF 指针设置为该位置，使用标准 CSF 模板，并修改 `[Authenticate Data]` 块部分来配置签名验证的起始地址和大小范围。
我的固件是一个完整的可启动映像，包含 FCB、IVT、DCD 和 BootData，它可以在没有 HAB 关闭的情况下在硬件上正常启动。
我将 CSF 模块配置如下：
Blocks=0x20208000 0x1000 0x126c0 "my_firmware.bin"同时更新了证书路径。
我运行了 CST v3.00.01 命令：
cst.exe -i .\input_resign.csf -o sig.binCST 执行完成，未出现任何错误，并生成了 `sig.bin`。
将输出结果与原始二进制文件进行比较，发现恰好有 2 处变化：
1. 更新 IVT 中偏移量为 `0x1018` 处的 CSF 指针字段。
2. CSF 签名数据附加在偏移量 `0x136c0` 处。
当我将此签名镜像刷入硬件时：
1.在 HAB 未关闭（SEC_CONFIG 未关闭）的情况下，固件运行完美。
2. 烧录 SRK 熔丝位并关闭 HAB 后，固件无法启动。
我通过 JTAG 从内存地址 `0x2020523c` 转储了长度为 256 字节的 HAB 日志，日志内容如下所示：
-----------------------------------------------------------------------------------------
| 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我的问题：
1.实际的HAB事件代码在哪里？根据相关资料，HAB认证通过/失败应生成明确的事件代码。但是我的日志只记录到 `AUTHENTICATION_STATUS` 就停止了，没有后续事件条目。如何判断HAB认证是成功还是失败？
2. 我尝试了 `blhost` 工具，但找不到任何适用于 i.MXRT1061 的 HAB 日志读取命令。还有其他方法可以读取完整的有害藻华状态吗？
3. 我的签名流程是否有效？我的镜像使用了非标准的 IVT 入口点（指向偏移量 `0x1400` 而不是重置向量偏移量 `0x2005`）。这样的图像能否用 CST 正确进行 HAB 签名？
偏移量为 `0x1000` 处的附加 IVT 标头字节：
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 工具版本：3.00.01
嗨@eleven ，
谢谢你的更新。首先，我认为我们应该确认 boot.bin 的第一个字节是 FCB 还是 IVT。如果是 FCB，可能仍然存在对准问题。
此外，本指南在读取和解释 HAB 故障代码的过程中应该会有所帮助： https://community.nxp.com/t5/i-MX-Security/HAB-event-in-a-Closed-i-MX-chip/ta-p/1120239
如果仍然无法找出问题的根本原因，使用 MCUBootUtility 直接生成 HAB 签名，然后运行二进制差异可能是交叉验证结果的另一种方法。
此致，
加文
非常感谢您的详细回复。我觉得我在之前的帖子中没有完整地描述我的测试设置。
我已经按照您的建议调整了模块配置。我两种都测试过了：
Blocks = 0x20208000 0x1000 0x126c0 "my_firmware.bin"
并拆分成多个块条目进行身份验证，从 IVT 开始一直到固件结束：
Blocks = 0x20209000 0x0 0x40 "启动.bin",\
0x20209080 0x80 0xf80 "boot.bin",\
0x2020a000 0x1000 0x11c00 "boot.bin"
我的目的是从 IVT 开始进行身份验证，一直到应用程序代码的末尾。然而，这些更改之后，启动行为仍然没有改变。
我使用的是 MCUBootUtility v6.5.1。其内置的启动日志分析和手动 JTAG 内存转储都给出了完全相同的日志结果。
另外，我了解到 或非 的最小启动偏移量为 0x1400。我想澄清的是：我的 IVT 入口点指向与启动相关的代码，而不是像参考示例中那样指向位于偏移量 0x2005 处的典型复位向量。
再次感谢您的指导。我将使用 sdphost 进行更多测试，以收集更多调试信息。希望我能从中获得更多线索。
此致，
十一
嗨@eleven ，
根据您的 IVT 数据、CST 配置和 ROM 日志，我发现了一些潜在问题。
1. CST [Authenticate Data] Blocks 地址/偏移量不匹配（主要问题）
从你的图像中， BootData.start = 0x20208000和IVT.self = 0x20209000建立了映射关系：文件偏移量0x1000对应于内存地址0x20209000 ，而不是0x20208000 。
CST Blocks 语法为
Blocks = 0x20208000 0x1000 0x126c0 "my_firmware.bin" ← address/offset misaligned by 0x1000
使 CST 对文件偏移量 0x1000 处的数据进行签名，同时设备上的 HAB 验证 0x20208000 处的内存（= 文件偏移量 0）。两者偏移了 0x1000，因此签名永远不可能匹配。这就解释了“打开时启动，关闭时失败”：在打开模式下，HAB 验证失败只会记录下来（非致命的），而在关闭模式下，它会阻止执行。
使固定 ：
(sign from IVT): Blocks = 0x20209000 0x1000 0x126c0 "my_firmware_prepared.bin"
另外，在运行 CST 之前，请确保 IVT.csf 字段（偏移量 0x1018）已预先填充最终的 CSF 地址 0x2021b6c0 (= 0x20208000 + 0x136c0)，然后签名，然后追加。签名后不要修改任何已签名的字节（IVT/BootData/DCD 都在已签名范围内）；这样做也会破坏验证。
Q1: HAB事件代码在哪里？如何判断通过/不通过？
从 0x2020523c 读取的是 ROM 启动日志，而不是详细的 HAB 事件日志。在 RT10xx 上，每个条目都打包成一个 32 位字 (event_id<<16) | parameter，参数位于低字节。
要了解详细的失败原因，请调用 HAB ROM API：report_status(&config,&state) 和 report_event(status,index,event,&bytes)。根据 HAB4 API 参考手册附录 A 进行解码
Q2：blhost 无法读取 HAB 日志——还有其他方法吗？
blhost 它与 Flashloader 通信，而不是直接与 BootROM 通信。i.MXRT BootROM 串行下载阶段仅支持 SDP（使用 sdphost）。选项：
- 建议：在应用程序处于打开状态时调用 HAB API，以读取/打印状态和事件。
- 通过 JTAG 从
0x2020523c转储 256 字节（ROM 日志）；或者使用 MCUBootUtility v6.3（sdphost 加载 flashloader，然后 blhost 读取内存）进行自动解析。
重要提示：当应用关闭且验证失败时，ROM 永远不会跳转到您的应用程序，因此应用内report_event无法运行。因此，标准流程必须是——首先确认 HAB_SUCCESS/Open 状态下没有事件，然后烧录 SEC_CONFIG 以关闭。
Q3：非标准 IVT 条目（偏移量 0x1400）能否进行 HAB 签名？
是的——这不是原因。对于 NOR 启动，i.MXRT BootROM 的最小偏移量为 0x1400（0x2000 只是一个推荐值）。
此致，
加文
很抱歉再次打扰您，但这个问题对我来说至关重要。
使用 sdphost 命令可以清楚地观察到 HAB 身份验证错误。然后我通过 JTAG 转储了早期内存区域，发现内存中没有任何固件内容。
进一步测试表明，即使是 NXP-MCUBootUtility 附带的官方演示项目，在配置为 NON-XIP 时也无法通过 HAB 签名验证。只有基于 XIP 的镜像才能正常工作。这个结果让我非常惊讶。
我怀疑我的 eFuse 寄存器配置可能有误。我的板没有启动模式 DIP 开关，所以我只将 boot_cfg 编程为 0x1A 并烧毁了 SRK 熔丝（请参考附件截图）。
我在这个领域还是个新手，可能犯了一些简单的错误。如有任何更正或建议，敬请不吝赐教。
期待您的回复，非常感谢。
嗨@eleven ，
您的观察——即使是官方演示程序，在以非 XIP 方式构建时 HAB 也会失败，而以 XIP 方式构建则可以正常工作——似乎指向了以下根本原因： https://www.cnblogs.com/henjay724/p/18111727
RT1050/1060“非XIP + HAB”BootROM限制在这两款最早的设备上，BootROM保留了部分OCRAM（特别是0x20280000–0x202BFFFF ），并且没有将其开放给HAB认证；其他RT设备没有此限制。您的映像加载到 OCRAM (0x20208000) 中，因此在 HAB 关闭时可以启动，但在 HAB 打开时验证失败，并且固件永远不会复制到内存中。这与您的脑脊液/阻滞无关，这就是为什么之前的改变没有效果的原因。
如果需要非 XIP 模式：请避开保留的 OCRAM 区域，改用外部同步动态随机存取存储器(SDRAM)。或者，根据上面链接中的指南，图像必须严格限制在 HAB 识别区域内。
关于熔丝（截图）：
- 如果没有启动模式 DIP 开关，独立组网 \\(SA\\) 启动需要BT_FUSE_SEL = 1 ；否则启动配置未定义。
- 请根据您的使用案例，逐位验证您的
BOOT_CFG1=0x1A和Conf0=0x40与 RT1060 RM 熔丝图。熔丝是一次性写入 (OTP) 的——请谨慎操作。
此致，
加文