2. Sitara安全启动架构解析

要理解 Sitara 的安全启动，不能只把它看成“上电后校验一下镜像”这么简单。它实际上是一条由硬件固化代码发起、逐级传递信任、最终把控制权交给应用固件的完整链路。这条链路的起点是芯片内部只读的 ROM Code，终点是运行在 DDR 或片上 RAM 中的用户程序。中间每一级都要完成三件事：验证下一级镜像的完整性与真实性、确认验证通过后再跳转、并把信任依据（公钥或证书）传递给下一级。本节围绕 ROM Code 启动流程、信任根建立、启动介质选择、安全启动链各阶段职责以及硬件安全模块概览展开。

ROM Code：不可更改的信任起点

Sitara 系列（如 AM335x、AM437x、AM57x 等）在芯片出厂时，ROM 中固化了一段引导代码，通常称为 ROM Code 或 RBL（ROM Boot Loader）。这段代码位于芯片内部掩膜 ROM，上电后由 ARM 核从固定地址取指执行，用户无法修改，也无法绕过。正因为不可更改，它才成为整条信任链的“信任根”（Root of Trust）。

ROM Code 上电后的典型流程是：先做最基本的时钟与电源初始化，然后读取启动模式引脚（SYSBOOT）确定从哪个介质启动；接着从该介质加载第一级引导镜像（在 Sitara 上通常是 MLO 或 tiboot3.bin 之类的头部镜像）；如果启用了安全启动，ROM Code 会用芯片内固化的公钥哈希（或密钥哈希）去验证镜像头中的证书与签名，验证通过才把镜像搬入内部 RAM 并跳转执行。这里有一个关键点：ROM Code 只信任“用与芯片内哈希匹配的公钥签名过的镜像”，其他任何镜像都会被拒绝，从而在源头阻断非法固件。

信任根如何建立

信任根的建立依赖两个要素：一是芯片内不可篡改的信任锚，二是外部可验证的签名机制。Sitara 的安全启动通常采用基于证书的签名方案：镜像头部携带一段证书，证书中包含公钥、镜像哈希以及用私钥对哈希的签名。ROM Code 内部保存的是该公钥的哈希（Key Hash），它先计算证书中公钥的哈希，与内部值比对；一致后再用该公钥验证镜像签名。这样即使攻击者替换了镜像和证书，只要私钥不泄露，就无法伪造出能通过校验的签名。

信任根一旦建立，后续每一级引导都沿用同样的逻辑：上一级验证下一级，验证通过后把下一级的公钥或证书纳入信任范围。于是信任像接力棒一样从 ROM Code 传到 SPL、再传到 U-Boot、最后传到内核与根文件系统。

启动介质选择与镜像布局

Sitara 通过一组 SYSBOOT 引脚在上电时决定启动介质。ROM Code 会按引脚编码的顺序依次尝试：例如先试 MMC0，失败再试 SPI，再试 UART。每种介质对第一级镜像的存放位置和格式都有约定。以 MMC/SD 为例，MLO 通常放在 FAT 分区的根目录，ROM Code 按固定偏移读取；而 SPI NOR 则从 0 地址开始读取镜像头。镜像头中除了证书和签名，还包含加载地址、镜像长度、入口地址等字段，ROM Code 依据这些字段把镜像搬到正确位置。

安全启动开启后，镜像必须经过签名工具处理，生成带证书的头部。常见的做法是使用 TI 提供的签名脚本或工具链，对 MLO、U-Boot、内核 FIT 等分别签名。未签名的镜像在安全模式下会被 ROM Code 直接拒绝，表现为串口无输出或停在“Authentication failed”之类的提示。因此调试安全启动时，第一步往往是确认镜像是否已正确签名、公钥哈希是否已烧录到 OTP 或写入密钥存储区。

各阶段职责与硬件安全模块

整条链路上，ROM Code 负责最底层的验证与跳转；SPL 负责初始化 DDR 等关键外设，并验证 U-Boot；U-Boot 负责加载并验证内核与设备树；内核再通过 IMA/EVM 或 dm-verity 等机制保护根文件系统。每一级都只信任上一级传递下来的公钥或证书，形成逐级收敛的信任边界。

硬件安全模块为这条链路提供底层支撑。Sitara 内部通常集成 AES/SHA 加速器、真随机数发生器、OTP 熔丝区以及安全计时器等。OTP 区用于存储公钥哈希或密钥，一旦烧录不可更改；安全计时器用于防回滚，防止攻击者把固件降级到存在漏洞的旧版本。理解这些模块的位置和作用，有助于在配置安全启动时判断哪些参数必须一次性规划好，哪些可以在后续阶段调整。

总体来看，Sitara 的安全启动架构是一条从 ROM Code 出发、经 SPL、U-Boot、内核逐级验证的信任链，配合启动介质选择和硬件安全模块，构成从芯片上电到应用固件运行的完整防护体系。掌握每一级的职责与验证方式，是后续进行安全固件升级和故障排查的基础。