4. HSM启动流程与安全启动链

在AURIX TC3xx这类带独立HSM子系统的芯片上，上电后的启动并不是“CPU直接跑用户程序”这么简单。芯片内部存在两条相互耦合又彼此独立的启动路径：一条是Host侧（TriCore主核）的启动路径，另一条是HSM侧（ARM Cortex-M核）的启动路径。二者共享BootROM、共享部分Flash与SRAM资源，但各自有独立的固件镜像、独立的校验逻辑和独立的复位控制。理解这两条路径的时序关系、校验节点和失败恢复机制，是HSM固件开发与整车项目集成的基础。

一、BootROM：两条启动路径的共同起点

芯片上电或复位释放后，首先执行的是固化在芯片内部ROM中的BootROM代码。BootROM不属于用户可修改区域，它承担几项关键职责：采样启动模式引脚（如HWCFG引脚组合）确定是从内部Flash启动、从外部启动还是进入调试/引导加载模式；初始化最基础的时钟与看门狗；然后根据启动配置分别引导Host侧和HSM侧。

在TC3xx中，BootROM会先检查HSM的使能状态。如果HSM被使能（通过UCB中的HSM配置或一次性烧写的使能位），BootROM会先释放HSM核的复位，让HSM开始执行其BootROM流程，同时Host侧可能被保持在等待状态，直到HSM完成必要的初始化或校验。这个“谁先谁后”的关系，正是Host与HSM启动时序的核心。

二、HSM固件加载与安全启动校验

HSM固件通常存放在主Flash的专用区域（HSM Flash区），也可能包含一段由BootROM直接加载的引导代码。HSM启动时，其BootROM会读取HSM固件头（Header），头中包含固件长度、入口地址、版本号以及最重要的——签名与哈希信息。安全启动校验的基本流程是：BootROM或HSM引导代码对固件镜像计算哈希（如SHA-256），再用存储在UCB或HSM专用OTP区域中的公钥验证签名（如ECDSA或RSA）。只有签名验证通过，HSM固件才会被允许执行。

这里有一个工程上极易踩坑的点：HSM固件的签名密钥与Host侧安全启动使用的密钥可以是同一套，也可以是分开的。如果项目要求HSM与Host分别由不同团队维护，通常建议使用独立的密钥层级，避免一方密钥轮换影响另一方。校验失败时，HSM不会跳转到固件入口，而是进入BootROM定义的错误处理路径。

三、Host与HSM启动时序的工程含义

从上面的时序图可以看到，HSM的启动校验发生在Host用户程序执行之前。这意味着：如果HSM固件校验失败，Host侧即使自身固件完好，也不应该继续启动。在整车项目中，这通常通过“HSM就绪信号”或共享状态寄存器来实现——Host在跳转用户程序前，必须确认HSM已经完成安全启动并进入服务状态。

实际配置中，HSM与Host的启动顺序可以通过UCB中的启动配置进行微调。例如，某些项目要求Host先完成基础外设初始化，再释放HSM；另一些项目则要求HSM先启动并提供安全服务，Host才能访问加密模块。这两种顺序没有绝对优劣，取决于整车E/E架构对启动时间和安全服务可用性的要求。

四、启动失败恢复策略

安全启动校验失败并不等于“芯片报废”。AURIX提供了多级恢复机制，工程上需要根据项目安全等级选择合适策略：

• 复位重试：HSM校验失败后触发一次受控复位，重新尝试启动。通常配合重试计数器，超过阈值后不再重试，避免无限复位循环。
• A/B分区回滚：如果Flash中同时存放两份HSM固件（A区和B区），当前分区校验失败时可切换到备份分区启动。这是整车OTA场景下最常用的策略。
• 安全降级模式：HSM不提供完整安全服务，但允许Host以受限功能启动，用于诊断或紧急救援。此模式必须严格限制可执行的操作，并记录安全事件。
• 调试接口锁定：校验失败后永久或临时锁定调试接口，防止通过调试口绕过安全启动。该策略通常与HSM生命周期状态绑定。

五、一个可参考的启动校验参数示例

以下是一组用于教学说明的示例参数，并非某款芯片的实测值。假设HSM固件镜像大小为256 KB，使用SHA-256哈希和ECDSA P-256签名：

在调试阶段，可以通过HSM的调试接口读取启动状态寄存器，确认校验是否通过、失败原因是什么（哈希不匹配、签名无效、公钥未烧写等）。这些状态信息对于定位启动失败问题至关重要，建议在项目早期就建立对应的读取和记录机制。

总结来说，HSM启动流程与安全启动链的核心在于：BootROM负责最底层的启动决策，HSM固件加载与校验构成第一道安全闸门，Host与HSM的时序关系决定了系统启动的依赖顺序，而恢复策略则保证在异常情况下系统仍能可控地响应。这四者共同构成了AURIX HSM安全启动的完整闭环。