2. i.MX启动架构与安全启动原理
i.MX 系列处理器的启动过程并不是“上电后直接跳到操作系统”，而是一条由硬件固化代码主导、逐级验证、逐级移交控制权的信任链。理解这条链，是配置安全启动、签名镜像、部署 OTA 的前提。本节围绕 Boot ROM、IVT、DCD、HAB、AHAB、TrustZone 六个关键对象，说明它们各自在启动链中的位置、作用以及相互之间的数据与控制关系。
一、启动链的总体结构
i.MX 上电或复位后，最先执行的是芯片内部固化的 Boot ROM。它不受外部修改，因此天然成为整条信任链的根（Root of Trust）。Boot ROM 根据 eFUSE 与 GPIO 引脚决定的启动介质（如 eMMC、SD、QSPI NOR、NAND、串行下载）读取外部镜像，解析镜像头部的 IVT（Image Vector Table），再按 IVT 指向的地址加载 Boot Data、DCD 和应用程序镜像。
在 i.MX6、i.MX7 等较早的平台上，镜像验证由 HAB（High Assurance Boot）完成；在 i.MX8、i.MX9 等新平台上，验证体系升级为 AHAB（Advanced High Assurance Boot），并引入容器（Container）概念。两者目标一致：在把控制权交给下一级镜像之前，用非对称密码学验证其完整性与来源合法性。验证通过后，控制权交给下一级引导程序（通常是 SPL/U-Boot），最终加载内核。整个过程形成一条“Boot ROM → 引导程序 → 内核 → 系统”的信任传递链。
二、Boot ROM 与启动介质选择
Boot ROM 的行为由一组 eFUSE 和启动模式引脚共同决定。以 i.MX6ULL 为例，BOOT_MODE[1:0] 引脚决定是“内部启动”还是“串行下载”；在内部启动下，BOOT_CFG 引脚或 eFUSE 进一步选择 SD、eMMC、NAND、QSPI 等介质。Boot ROM 会按顺序尝试这些介质，找到合法 IVT 后开始加载。
这里有一个工程上非常关键的细节：Boot ROM 只认它自己能解析的镜像格式。镜像的第一个扇区（通常是 1KB 偏移处）必须放置 IVT，且 IVT 的头部标记、各字段地址必须与实际镜像布局一致。如果 IVT 位置错误或校验失败，Boot ROM 会跳到下一个启动介质，最终可能进入 USB 串行下载模式。因此，制作启动镜像时，IVT 的偏移和地址映射必须与芯片参考手册严格对应。
三、IVT 与 DCD 的分工
IVT 是镜像的“目录”。它包含自检标记、镜像入口地址、DCD 指针、Boot Data 指针、以及各段镜像的加载地址。Boot ROM 读取 IVT 后，就知道该把哪些数据搬到内存的什么位置，以及第一条指令从哪里开始执行。
DCD 是“初始化脚本”。它由一系列寄存器写命令组成，典型用途是在加载大镜像之前初始化外部 DDR。因为 Boot ROM 运行时 DDR 尚未配置，而镜像可能很大、必须加载到 DDR 中，所以 DCD 必须先于镜像主体执行。DCD 的命令格式包括写寄存器、检查位、延时等，由芯片的 DCD 解析器逐条执行。
一个常见的教学示例是：DCD 中写入 DDR 控制器的时序参数（如 tRFC、tRAS、CAS 延迟），使 DDR 进入可用状态；随后 Boot ROM 将 U-Boot 镜像从 eMMC 搬到 DDR 的链接地址，再跳转执行。若 DCD 参数错误，典型现象是启动卡死或 DDR 数据校验失败，此时需要借助 JTAG 或串口日志定位。
四、HAB 与 AHAB：验证机制的区别
HAB 使用 CSF（Command Sequence File）描述签名与证书信息。镜像生成时，用私钥对镜像哈希签名，并把证书链、签名值写入 CSF。Boot ROM 用 eFUSE 中烧录的 SRK 哈希（Super Root Key Hash）验证证书链，再用证书中的公钥验证镜像签名。HAB 有“开放”“闭锁”等状态，量产时必须关闭开放状态，否则验证形同虚设。
AHAB 面向 i.MX8 及以上平台，把多个镜像组织成容器（Container），容器头包含签名、证书和镜像清单。AHAB 支持更灵活的镜像组合与回滚保护，验证粒度更细。对 OTA 而言，AHAB 的容器结构更利于把多个固件组件打包成一个可验证单元。
五、TrustZone 与运行期隔离
安全启动解决的是“启动阶段镜像是否可信”，而 TrustZone 解决的是“运行阶段资源是否隔离”。i.MX 处理器把 CPU、内存和外设划分为安全世界与普通世界。安全世界运行可信执行环境（如 OP-TEE），普通世界运行 Linux。通过 TZASC 控制内存区域访问权限，通过 TZPC 控制外设访问权限，密钥、安全存储、加解密引擎等敏感资源只对安全世界开放。
在 OTA 场景中，TrustZone 的价值在于：即使普通世界的 Linux 被攻破，攻击者也无法直接读取安全世界中的签名密钥或篡改安全启动状态。安全世界可以承担镜像验签、密钥管理、回滚计数等职责，与启动阶段的 HAB/AHAB 形成互补。
六、工程视角下的关键检查点
把上述对象串起来，实际工程中需要重点确认以下内容：
- IVT 偏移与地址：镜像中 IVT 的位置、各段加载地址是否与链接脚本、参考手册一致。
- DCD 正确性：DDR 初始化参数是否匹配实际颗粒，是否经过压力测试验证。
- eFUSE 状态：SRK 哈希是否已烧录，HAB/AHAB 是否已闭锁，启动介质选择位是否正确。
- 签名链完整：私钥、证书、CSF/容器是否匹配，签名工具版本是否与芯片兼容。
- TrustZone 配置：安全/普通世界的内存与外设划分是否与软件设计一致。
这些检查点中任何一项出错，都会表现为启动失败、验证失败或安全边界失效。建议在开发阶段保留串口日志与 JTAG 调试通道，量产阶段再关闭调试接口并闭锁安全状态。