3. 复杂SoC启动流程与TRACE32调试介入点

复杂SoC的启动不是一次跳转，而是一条由多个固件阶段接力完成的链路。以典型的ARMv8-A多核SoC为例，上电后最先运行的是芯片内部固化的ROM Code，它根据启动引脚或eFuse选择从SPI Flash、eMMC、UFS或串行下载口加载BootROM（或称SPL/FSBL）。BootROM完成DDR初始化、时钟与电源域配置后，把ATF（ARM Trusted Firmware）的BL2/BL31镜像搬入内存；ATF在EL3建立安全监控环境，再依次加载BL33（通常是U-Boot）并跳转；U-Boot完成外设初始化、镜像校验与设备树传递，最后引导Linux内核，由内核接管异常向量并启动用户空间。整条链路上，每一级都可能成为“黑屏无输出”的故障点，而TRACE32的价值就在于能在这些阶段之间插入可控的观察与干预。

要理解调试介入点，先要理解启动链路的“交接”本质。每一级固件在跳转前都会设置好下一级的入口地址、异常向量基址（VBAR_ELx）、栈指针和必要的系统寄存器。如果某一级没有正确设置VBAR，一旦发生异常就会跳飞到未知地址，表现为反复复位或挂死。TRACE32通过调试探针（如Lauterbach的JTAG/SWD或Trace接口）在CPU复位释放前就附着到目标，因此可以捕获复位向量处的第一条指令，这是软件打印无法替代的能力。

复位向量捕获是整条链路的起点。在TRACE32中，通常先执行 SYStem.Up 让CPU从复位状态释放并停在第一条指令处，此时用 Register.View 查看PC值。以某ARMv8 SoC为例，复位向量可能位于0xFFFF0000或0x00000000，具体取决于芯片的ROM映射。确认PC后，用 List 窗口反汇编当前地址，单步执行前几条指令，观察是否跳转到预期的BootROM入口。如果PC值异常或反复复位，需要检查复位引脚时序、启动模式引脚和电源域状态。

启动阶段断点的设置需要区分“硬件断点”和“软件断点”。在ROM Code和BootROM阶段，代码通常运行在只读存储器或未初始化DDR中，软件断点（替换指令为断点指令）可能无法写入，此时必须使用硬件断点。TRACE32中通过 Break.Set /Hard 设置硬件断点，数量受CPU硬件断点寄存器限制（通常4~8个）。建议在ATF BL31入口、U-Boot的 board_init_f 和Linux的 start_kernel 三处各设一个硬件断点，形成阶段检查点。每次命中后，用 Register.View 检查VBAR_EL3、VBAR_EL1、SCTLR_ELx和TTBR0_EL1等关键寄存器，确认异常向量基址和内存映射是否符合预期。

异常向量跟踪是定位“跑飞”问题的核心手段。ARMv8的异常向量表每个入口占128字节，共16个入口，分别对应当前EL和较低EL的Synchronous、IRQ、FIQ、SError异常。当CPU发生异常时，硬件自动将返回地址写入ELR_ELx，异常原因写入ESR_ELx，并跳转到VBAR_ELx加上偏移量处的向量入口。在TRACE32中，可以先读取VBAR_EL3和VBAR_EL1的值，然后在向量表入口处设置断点。一旦命中，立即查看ESR_ELx的EC字段（异常类别）和ISS字段（具体信息），判断是数据中止、指令中止、未定义指令还是系统调用。例如，EC=0x25表示数据中止，此时需要检查FAR_ELx（故障地址寄存器）确认访问了哪个非法地址。

Trace指令流回溯是TRACE32的独特优势。当异常发生时，如果目标芯片支持指令Trace（如ETM/ETB或芯片内置Trace Buffer），可以在 Trace.List 窗口中查看异常发生前执行的指令序列。这对于分析“为什么跳到了异常向量”至关重要——因为异常向量本身只是结果，真正的原因往往在异常发生前的几条指令中。例如，如果Trace显示在异常前执行了一条对未映射地址的加载指令，那么问题就定位到了该加载指令的地址计算或页表配置上。

启动链路的调试难点在于“不可见”——很多阶段没有串口输出，或者输出在DDR初始化之前就丢失了。TRACE32的介入点恰好填补了这些盲区：复位向量捕获解决了“第一条指令在哪”的问题，阶段断点解决了“每一级是否正常交接”的问题，异常向量跟踪解决了“跑飞后去哪了”的问题。三者结合，就能把从ROM到OS的整条链路变成可观察、可干预、可回溯的调试过程。