企业官网建设流程全解析

1. 项目概述与核心价值

对于任何一位嵌入式开发者而言，深入理解你所使用的SoC（片上系统）的启动流程，就如同一位赛车手必须熟悉他座驾的引擎点火、变速箱换挡和四轮驱动系统如何协同工作一样。这不仅仅是“知道它能跑起来”，而是要精确掌握从按下电源键到第一个用户程序开始执行，这中间电信号和数据流究竟经历了怎样的旅程。AM261x作为德州仪器（TI）旗下的一款高性能、多核异构处理器，其启动机制设计精巧且复杂，融合了安全启动、多核协同和灵活的引导策略。

很多工程师在初次接触这类复杂SoC时，往往只关注如何编译和下载一个“helloworld”程序，对于Bootloader（引导加载程序）的理解停留在“黑盒”阶段。一旦遇到系统无法启动、镜像加载失败或者安全认证出错的问题，排查起来就犹如大海捞针，只能盲目地尝试重新烧录，效率极低。实际上，AM261x的启动流程是一套环环相扣的精密协议，从硬件上电的瞬间，到R5F核心执行你的应用程序，每一个步骤都有其明确的目的和严格的时序。

本文将为你彻底拆解AM261x的完整启动流程。我们将从最基础的硬件启动条件讲起，一步步深入到ROM代码（RBL）的内部架构，剖析R5F核心与HSM安全核心之间如何通过IPC“对话”，并详细解读OSPI、UART、USB DFU等多种启动模式下的硬件配置与软件行为。我的目标不仅是让你“知道”流程，更是让你“理解”每个环节背后的设计逻辑和潜在陷阱。无论你是正在评估AM261x进行硬件设计，还是已经深陷启动失败的调试泥潭，这篇文章都将提供从原理到实操的完整路线图。

2. AM261x启动流程全景解析

AM261x的启动不是一个单一线程的任务，而是一个由硬件状态机、固化ROM代码和用户可编程软件共同参与的、多阶段、多核心协同的复杂过程。我们可以将其宏观地划分为三个主要阶段：硬件启动过程、ROM引导加载程序过程和次级引导加载程序过程。这三个阶段层层递进，责任分明。

2.1 三阶段启动模型详解

第一阶段：硬件启动过程这个阶段完全由硬件逻辑和外部电源管理芯片控制，软件尚未介入。其核心任务是建立SoC能够正常工作的最基本物理环境。这主要包括两个子过程：

1. 预初始化：在芯片上电之前，我们必须确保所有必要的硬件输入信号处于正确状态。这包括：
   • 电源：所有电源轨（Core, DDR, IO等）需要按照数据手册规定的时序和电压值进行上电。
   • 时钟：为芯片提供参考时钟源。
   • 复位信号：确保复位信号（PORz/RSTz）干净、无毛刺地释放。
   • 启动模式引脚：这是本阶段最关键的一步。BOOTMODE[3:0]等引脚必须通过上拉/下拉电阻或跳线帽，在电源稳定前就被设置为期望的启动模式（如OSPI、UART）。芯片会在复位释放的瞬间采样这些引脚的状态，并将其锁存到内部状态寄存器中，作为后续ROM代码的“行动指南”。
2. 电源、时钟、复位爬升序列：通常由一颗专用的电源管理芯片（PMIC）按照特定顺序控制完成。错误的时序可能导致部分电路模块工作异常，甚至无法启动。

注意：硬件启动阶段的配置失误是导致后续所有软件启动失败的根本原因之一。务必在PCB设计阶段就确认好启动模式引脚的电平，并在上电时使用示波器检查电源时序和复位信号的质量。

第二阶段：ROM引导加载程序过程当硬件条件就绪，复位信号释放后，芯片内部固化的ROM代码开始执行。AM261x的ROM代码是一个多核软件，由两部分组成：

• 公共ROM代码：运行在主应用核心Cortex-R5F0上。
• HSM ROM代码：运行在位于安全岛的Cortex-M4核心上，专门负责安全相关的操作，如镜像的完整性和真实性验证。

这两个ROM核心并非同时启动。HSM ROM会先启动，并确保R5F核心处于复位保持状态。在完成自身基础初始化后，HSM ROM会通过清除R5SS0_COREA_HALT寄存器来释放R5F核心。此后，两者通过共享的邮箱RAM进行基于中断的IPC通信，协同工作。R5F ROM的核心职责是识别启动接口、下载SBL镜像；而HSM ROM则负责审核这个镜像，决定是否允许其执行。

第三阶段：次级引导加载程序过程当R5F ROM和HSM ROM通力合作，成功将SBL镜像加载到内部L2 RAM并通过验证后，HSM ROM会“遮蔽”R5F ROM（使其不可访问），并对R5F核心发起一次复位。随后，R5F核心从地址0x0（即SBL在L2 RAM中的加载地址）开始执行SBL代码。

SBL是第一个完全由用户编写或基于TI SDK定制的软件。它肩负着更复杂的使命：

• 全面SoC配置：初始化PLL、配置DDR内存控制器、设置更多外设的时钟和引脚复用。
• 加载运行时固件：引导HSM运行时（TIFS-MCU）固件，为应用程序提供安全服务（如加解密引擎、密钥管理）。
• 加载最终应用：将最终的用户应用程序（如FreeRTOS任务或裸机程序）从外部存储器加载到DDR或内部RAM中，并跳转执行。

至此，一个完整的、从硬件上电到用户应用运行的链条才真正贯通。

2.2 核心概念与术语精讲

在深入细节前，厘清几个关键术语有助于避免混淆：

• Boot Mode Pins：启动模式引脚。这是硬件配置的物理体现，是ROM代码判断从何处加载镜像的首要依据。用户必须在PCB上通过电阻将其固定为高或低电平。
• RBL：ROM Bootloader，即固化在芯片ROM中的引导程序。它是芯片出厂时就烧写好的，不可修改。
• SBL：Secondary Bootloader，次级引导加载程序。这是由用户开发或配置的，存储在外部Flash（如OSPI）中的程序。它是RBL加载的第一个“用户软件”。
• HSM：Hardware Security Module，硬件安全模块。指SoC中一个独立的、隔离的安全子系统（通常包含一个M4核心、专用RAM、密码学加速器等），用于执行高安全等级的任务。
• IPC：Inter-Processor Communication，处理器间通信。在AM261x启动流程中，特指R5F ROM与HSM ROM之间通过邮箱RAM和中断机制进行的消息传递。
• XIP：eXecute-In-Place，就地执行。指代码直接在外部存储器（如NOR Flash）中执行，无需先拷贝到RAM。AM261x的ROM代码在加载SBL时，不支持XIP，它总是先将SBL镜像拷贝到内部L2 RAM再执行，这保证了执行速度和安全校验的可行性。
• 冗余启动支持：一项提高系统可靠性的设计。当主SBL镜像因存储介质损坏等原因加载或验证失败时，RBL会自动尝试加载存储在备用地址的冗余SBL镜像。

3. ROM代码深度剖析与多核协同机制

理解了宏观流程，我们潜入微观世界，看看ROM代码内部是如何运作的。这是整个启动流程中最精妙也最容易被忽视的部分。

3.1 公共ROM代码架构与执行流

R5F核心上的公共ROM代码是一个结构清晰的软件模块，其架构如下图所示（根据技术参考手册描述还原）：

[公共ROM入口点] | v [主模块初始化] | v [启动循环] ——> [模块层] ——> [驱动层] | | | | | | +——— IPC ——+ | | | v v [与HSM通信] [操作硬件外设]

3.1.1 从入口点到主模块R5F核心被HSM解除Halt后，程序计数器指向ROM的入口点。这里会执行一系列最底层的核心初始化：

1. 清除核心寄存器：为后续执行提供一个干净的上下文环境。
2. 执行PBIST：对TCM B内存进行内置自测试，确保这块关键内存的可靠性。
3. 设置异常栈和主栈：为C语言运行环境和中断处理建立栈空间。
4. 执行TI自动初始化：TI编译器提供的一段代码，用于初始化全局变量。
5. 跳转到main()函数：进入ROM代码的主逻辑。

主模块main()则负责更进一步的准备工作：

• 系统MPU初始化：配置内存保护单元，定义内存区域的访问权限。
• 核心PLL初始化：ROM代码仅初始化核心PLL，将R5F核心时钟设置为400MHz，HSM核心时钟设置为200MHz。其他PLL（如DDR、外设PLL）留给SBL去配置。
• 日志模块初始化：为后续的调试信息输出做准备。
• 系统初始化：包括VIM（向量中断管理器）和RTI（实时中断定时器）的初始化。
• 执行PBIST：对TCM A和L2内存进行测试。
• 初始化IPC模块：准备好与HSM通信的邮箱RAM。
• 发送“Hello”消息：向HSM发送IPC_MsgType_HELLO消息，宣告R5F核心已就绪，可以开始启动流程。

3.1.2 启动循环与接口识别完成初始化后，代码进入启动循环。循环的第一步就是读取启动模式引脚。根据之前硬件阶段锁存的BOOTMODE值，ROM代码会创建一个启动外设列表和配置表。AM261x主要支持三类启动接口：

1. OSPI (NOR Flash)：从外部八线/四线SPI Flash加载。这是最常用的生产模式。
2. UART：通过串口从外部主机（如PC）下载镜像。常用于工厂烧录或深度调试。
3. USB DFU：通过USB接口以设备固件升级模式下载镜像。

识别出接口后，ROM代码会调用相应的驱动层（如OSPI驱动、UART驱动、EDMA驱动）来配置硬件，并利用模块层（如证书模块、X-modem协议模块）来处理上层协议。

3.2 HSM与R5F的IPC通信协议详解

R5F ROM和HSM ROM的协同工作是安全启动的基石。它们通过位于接收处理器子系统的共享邮箱RAM进行通信，这是一种基于中断和消息队列的机制。

3.2.1 邮箱与中断映射

• 处理器编号：R5FSS0 Core0 编号为 0， HSM M4 编号为 6。
• 邮箱地址：
  • R5的发送邮箱：0x44000000
  • R5的接收邮箱：0x72000000
  • （HSM的邮箱地址在另一侧，由HSM ROM访问）
• 中断线：
  • R5邮箱读请求中断：158
  • R5邮箱读完成应答中断：159
  • HSM邮箱读请求中断：0
  • HSM邮箱读完成应答中断：40

3.2.2 消息传递流程（以R5发送，HSM接收为例）这是一个严谨的“握手”协议，确保消息不丢失：

1. R5写消息：R5将消息内容写入HSM的接收邮箱（从R5视角是“写对方邮箱”）。
2. R5触发中断：R5通过写自己控制空间（R5_CTRL）的特定位，向HSM产生一个“写完成”中断。
3. HSM响应中断：HSM收到聚合中断，检查自己的控制寄存器（HSM_CTRL），发现R5的位被置1，得知有新消息。
4. HSM清除中断标志：HSM写HSM_CTRL中对应R5的位为1，以清除中断标志。
5. HSM读取消息：HSM从自己的邮箱中读取消息内容。
6. HSM发送应答：HSM写HSM_CTRL中的应答位，向R5产生一个“读完成应答”中断。
7. R5处理应答：R5收到聚合应答中断，检查自己的控制寄存器，发现HSM的位被置1。
8. R5清除应答标志：R5写R5_CTRL中对应HSM的位为1，完成一次完整通信。

3.2.3 启动过程中的关键消息流在启动过程中，HSM扮演着一个“安全审查官”的角色，其状态机与R5F的交互如下：

1. 等待Hello：HSM解除R5 Halt后，就进入等待IPC_MsgType_HELLO消息的状态。收到后，表明R5已初始化完成。
2. 等待证书：R5从启动接口（如OSPI Flash的固定偏移地址）读取SBL镜像的证书部分，并通过IPC_MsgType_CERT消息发送给HSM。HSM根据设备的安全状态（HS-FS或HS-SE）验证证书的签名和有效性。
3. 接收镜像：证书验证通过后，R5开始将SBL镜像的数据部分分块（每块>=2KB）发送给HSM，消息类型为IPC_MsgType_IMAGE。HSM同步进行两项操作：
   • 计算SHA512哈希：对收到的每一个数据块计算哈希值，在整个镜像接收完毕后，将此计算出的哈希值与证书中携带的哈希值进行比对，验证镜像完整性。
   • 镜像解密：如果证书中启用了加密选项，且证书和完整性校验均通过，HSM会使用其安全模块对镜像进行解密。
4. 裁决与移交：
   • 成功：如果所有验证（及可能的解密）均成功，HSM ROM会“遮蔽”R5 ROM（使其地址空间不可访问），然后触发R5核心的软复位。复位后，R5核心将从L2 RAM的0x0地址开始执行刚刚验证通过的SBL。
   • 失败：如果任何一步验证失败，HSM会通知R5，整个流程可能回退到“等待证书”状态，尝试加载冗余备份镜像（如果支持），或者最终失败进入某种错误状态（如UART回退模式）。

这套机制确保了只有经过授权和完整性校验的SBL才能被加载执行，是构建可信启动链的第一道坚实防线。

4. 启动模式实战：以OSPI为例的硬件与软件配置

AM261x支持多种启动模式，由BOOTMODE[3:0]引脚的电平组合决定。我们以最常用、也最复杂的OSPI启动为例，进行深入剖析。

4.1 启动模式引脚配置详解

BOOTMODE引脚在芯片复位释放时被采样，其值决定了ROM代码的首要行为。以下是AM261x支持的主要启动模式映射表：

实操心得：在设计电路板时，务必根据选定的启动模式，使用电阻准确上拉或下拉这些引脚。绝对不能让它们悬空，悬空会导致电平不确定，进而引发启动行为异常。通常建议使用4.7kΩ或10kΩ的电阻。对于“保留”或“未使用”的引脚，也应按照数据手册建议固定接高或接低。

4.2 OSPI启动模式的硬件连接与引脚复用

当BOOTMODE设置为OSPI启动时，ROM代码在初始化阶段会自动配置一组GPIO引脚作为OSPI外设的功能。这一点至关重要：这意味着你不需要在SBL中再去初始化这些引脚的复用功能，ROM已经帮你做好了。但是，你必须确保PCB上这些引脚连接到了正确的OSPI Flash芯片引脚上。

以ZCZ封装的AM261x在OSPI (8S)模式下的引脚配置为例（摘自技术参考手册）：

关键点解析：

1. 引脚复用：注意OSPI0_D4到OSPI0_D7在芯片内部复用了MCAN功能的引脚。ROM代码通过设置PinMux Mode#为2，将它们切换到了OSPI功能。这意味着，如果你在硬件上将这些引脚用于OSPI，那么它们就不能同时用作CAN通信。必须在硬件设计初期就规划好外设资源的分配。
2. 时钟配置：ROM代码会根据启动模式自动配置OSPI控制器的时钟。例如，在8S模式下，时钟源为200MHz的SYS_CLK，分频因子为6，得到约33MHz的OSPI接口时钟。在4S和1S模式下，分频因子为4，得到50MHz时钟。
3. 一个已知的硬件勘误：技术手册提到，在OSPI启动模式下，ROM会尝试配置GPIO61作为OSPI0_RESET_OUT0来复位外部Flash。但由于控制器的一个配置错误，这个复位信号在复位后可能无法被正确释放（即一直保持低电平）。如果你的Flash复位引脚连接到了GPIO61，会导致Flash一直被复位，从而启动失败。
   • 解决方案：参考TI的《AM26x硬件设计指南》和勘误文档，可能的规避方法包括：不将Flash复位引脚连接到GPIO61，或者通过外部电路确保该引脚在上电后处于正确电平。

4.3 OSPI Flash的兼容性与配置要求

ROM代码对OSPI Flash设备有一定要求，并非所有Flash都能直接使用：

• JESD216 SFDP支持：ROM代码依赖Flash的SFDP（串行Flash可发现参数）表来获取设备信息，特别是“四线使能”位。对于支持9个以上参数字的SFDP版本，ROM可以直接读取。对于只支持9个参数字的旧版本，ROM无法获取该位，需要预先通过编程工具将Flash的QE（Quad Enable）位设置为1，否则在四线模式下无法正常工作。
• 容量与地址模式：ROM代码默认使用3字节地址模式（24位地址，寻址空间128Mb）。如果你使用的Flash容量大于128Mb，必须选用带硬件复位（RESET）引脚的Flash型号。因为当你的应用程序（或SBL）切换到4字节地址模式后，如果发生芯片复位，ROM代码会再次运行并期望3字节模式，此时需要硬件复位信号将Flash拉回3字节模式，否则启动会失败。
• 操作模式：ROM代码支持多种读取指令：
  • 1S模式：使用标准读命令0x0B（Fast Read）。
  • 4S模式：使用四线快速读命令0x6B。
  • 8S/8D模式：使用八线读命令0x8B或通过SFDP获取的命令。
  • 所有模式都假设命令和地址阶段为单线（1S），数据阶段为多线。并会插入8个 dummy cycles（空周期）以匹配Flash的延迟。

4.4 OSPI启动的软件加载流程

无论哪种OSPI模式，其加载流程本质一致，且都不是XIP：

1. 硬件初始化：ROM代码根据BOOTMODE配置OSPI控制器的时钟、引脚复用、工作模式（如时钟极性相位为Mode 3）。
2. 读取镜像头：ROM代码从OSPI Flash的0x0000_0000地址（内存映射地址0x6000_0000）开始读取数据。它首先寻找一个特定格式的“证书”或“镜像头”，其中包含了镜像长度、加载地址、哈希值等信息。
3. 分块传输与验证：R5 ROM通过DMA（EDMA）将镜像数据分块从Flash搬移到内部L2 RAM。同时，每块数据都被发送给HSM进行SHA512哈希计算。
4. 完整性校验与解密：HSM在接收完所有数据后，对比计算出的哈希值与证书中的哈希值。如果启用加密，则在此之后进行解密。
5. 控制权移交：验证通过后，HSM遮蔽R5 ROM，复位R5核心，R5核心跳转到L2 RAM的0x0地址执行SBL。

注意事项：SBL在L2 RAM中的加载地址（默认为0x0）是固定的，由ROM代码决定。你在编译链接SBL时，需要确保它的链接地址（Load Address）和运行地址（Run Address）都设置在这个区域（例如0x70000000开始的L2 RAM空间）。TI的SDK工具链（如CCS或makefile）通常会处理好这些内存映射关系。

5. 其他启动模式与高级功能解析

除了主流的OSPI启动，AM261x也提供了其他启动路径，用于开发、调试和生产维护。

5.1 UART启动模式

这是一种非常关键的调试和工厂烧录模式。当BOOTMODE配置为UART模式时：

• 协议：ROM代码使用XMODEM协议与主机通信。你需要一个支持XMODEM的文件传输终端软件（如Tera Term, SecureCRT）或使用TI提供的uart_bootloader工具。
• 参数：固定为115200波特率，8位数据位，无校验位，1位停止位，无流控。
• 流程：上电后，ROM代码会等待主机发送SBL镜像。主机通过XMODEM协议将镜像文件发送过来，ROM代码将其接收并存入L2 RAM，后续的验证和执行流程与OSPI模式相同。
• 应用场景：
  • 初始Flash编程：在空板或Flash为空时，通过UART将SBL和应用程序烧写到OSPI Flash中。
  • 紧急恢复：当Flash中的镜像损坏导致无法启动时，可以通过UART重新下载一个可工作的镜像。
  • 深度调试：直接下载并运行镜像，无需反复烧写Flash，提升调试效率。

5.2 USB DFU启动模式

USB Device Firmware Upgrade模式提供了另一种高速的镜像下载方式。

• 特性：支持USB 2.0高速模式（480 Mbps），速度远快于UART。
• 流程：ROM代码将USB控制器初始化为设备模式，等待主机（通常是PC）发起DFU事务。主机通过DFU协议将镜像传输到设备端的L2 RAM。
• 工具：需要在PC端使用DFU工具（如dfu-util）配合特定的驱动程序。
• 优势：比UART更快，比操作Flash更灵活，适合需要频繁更新镜像的开发阶段。

5.3 冗余启动支持

这是一个提升产品现场可靠性的重要功能。其核心思想是在外部Flash中存储多个SBL镜像副本（例如一个主镜像，一到两个备份镜像）。ROM代码在加载时会遵循以下顺序：

1. 尝试从主镜像地址（如0x000000）加载并验证SBL。
2. 如果失败（原因可能是CRC错误、签名验证失败、哈希值不匹配等），ROM代码会自动跳转到预定义的冗余镜像地址（例如0x040000）进行尝试。
3. 可以配置多个冗余备份，ROM会按顺序尝试，直到有一个成功或全部失败。
4. 如果所有备份都失败，ROM可能会尝试进入UART回退模式，等待主机通过串口介入。

实操心得：在设计和部署固件更新（FOTA）机制时，冗余启动是实现“安全回滚”的关键。当更新失败时，系统能自动回退到上一个已知良好的版本，避免设备“变砖”。实现时，需要在SBL或应用程序中设计一套机制，来管理主镜像和备份镜像的烧写与验证。

5.4 DevBoot开发模式

此模式主要用于早期软件开发和安全配置。

• 行为：在此模式下，R5 ROM的功能被“遮蔽”，PLL不初始化，部分内存（TCMA, TCMB, L2）的PBIST和初始化也不执行。
• 主要用途：
  1. SBL开发：开发者可以直接通过JTAG连接芯片，将SBL代码加载到RAM中运行和调试，而无需依赖ROM的引导流程，简化了SBL本身的开发过程。
  2. 密钥烧写：对于HS-SE（安全强制启用）设备，客户密钥需要通过JTAG和特定的KeyWriter工具在安全环境中烧写到芯片的eFuse中。这个操作通常需要在DevBoot模式下进行。
• 注意：这是工厂生产或安全配置时的特殊模式，普通应用开发中较少使用。

6. 常见启动问题排查与调试技巧

即使理解了所有原理，在实际硬件上调试启动流程仍可能遇到各种问题。以下是我在多年项目中总结的一些常见故障场景和排查思路，希望能帮你快速定位问题。

6.1 问题排查流程图与速查表

当你的AM261x板卡上电后没有任何反应，或者无法加载SBL时，可以按照以下逻辑树进行排查：

[板卡上电无反应] | v 检查电源、时钟、复位信号 --> [用示波器测量各路电源时序、电压幅值、复位信号是否干净] | | | (正常) | (异常) v v 检查启动模式引脚电平 --> [万用表测量BOOTMODE[3:0]引脚电压，确认与目标模式匹配] 修复电源/复位电路 | | | (正确) | (错误) v v 连接JTAG调试器 <----------------------------------- 调整上下拉电阻 | v 能否连接并暂停R5核心？ --> [使用CCS或Lauterbach尝试连接] | | | (能) | (不能) v v 检查ROM代码执行日志 <----------------------------------- 检查JTAG连接、芯片是否彻底损坏 | v [通过UART0查看ROM输出] --> [ROM代码的Logger模块会通过UART0输出启动信息，波特率115200] | v 分析日志信息

常见启动失败现象与可能原因速查表：

6.2 关键调试手段与工具

1. UART日志输出：这是最宝贵的信息源。确保将板卡的UART0（通常是调试串口）连接到PC，使用串口工具（如Putty, Tera Term）以115200波特率监听。ROM代码会在关键步骤输出信息，如：

   • Boot Mode: OSPI (4S)
   • Starting OSPI initialization...
   • Loading certificate from address 0x60000000...
   • HSM Validation passed/failed...
   • Jumping to SBL at address 0x70000000这些日志能直接告诉你流程卡在了哪一步。

2. JTAG调试：当UART无输出或需要更深入的信息时，JTAG是终极武器。

   • 连接时机：在芯片上电复位后即可连接。如果ROM代码正在运行，你可以暂停R5核心，查看其程序计数器（PC）和寄存器状态。
   • 查看HSM状态：HSM核心的调试访问可能受到限制（尤其在HS-SE模式下），但一些状态寄存器或共享内存区域可能提供错误代码。
   • 内存查看：通过JTAG直接读取OSPI Flash内存映射区域（0x60000000开始）的内容，确认镜像是否被正确烧写。读取L2 RAM（0x70000000开始）的内容，确认SBL是否被正确加载。

3. 信号测量：对于硬件相关的问题，示波器必不可少。

   • 测量电源：检查上电时序、电压纹波。
   • 测量复位信号：确保释放干净，无毛刺。
   • 测量OSPI信号：在启动阶段，测量CLK, CS#, D0等信号，看是否有波形活动。如果完全没有，可能是引脚复用或Flash片选问题。如果有波形但乱，可能是信号完整性问题。

4. 使用TI工具链：

   • uniflash：TI提供的Flash烧写工具，支持通过JTAG、UART等方式烧写OSPI Flash，并能生成正确格式的镜像。
   • signing_tool：用于为SBL和应用镜像生成证书和签名，是启用安全启动的必备工具。
   • CCS (Code Composer Studio)：集成开发环境，强大的调试器，可以查看反汇编、内存、寄存器，是分析复杂问题的利器。

6.3 安全启动失败专项排查

如果启动卡在HSM验证阶段，问题通常出在镜像的安全属性上：

• 确认设备安全状态：你的芯片是HS-FS状态还是HS-SE状态？在HS-FS状态下，HSM不会强制进行认证，任何镜像（甚至未签名的）都能被加载。在HS-SE状态下，则必须使用匹配的密钥进行签名。
• 检查签名工具和密钥：确保你使用的signing_tool版本与SDK匹配，使用的密钥对（公钥/私钥）与烧写到芯片eFuse中的公钥哈希一致。
• 检查镜像格式：使用hexdump或CCS查看生成的.bin或.tiimage文件头部，确认证书、镜像长度等字段是否正确。TI的镜像格式有特定的结构。
• 查看HSM错误码：如果可能，通过调试接口或共享内存区域读取HSM返回的详细错误码，这能精确指出是签名错误、证书过期还是哈希不匹配。

启动流程的调试是一个需要耐心和系统方法的过程。从电源开始，逐级向后，利用好日志和调试工具，大部分问题都能被定位和解决。最忌讳的是在没有明确方向的情况下盲目修改代码或电路，那只会让问题变得更复杂。