1. 项目概述与核心价值

在嵌入式系统开发领域，尤其是基于德州仪器（TI）等厂商的复杂SoC（片上系统）时，系统上电后的第一段旅程——启动引导（Booting）——往往是决定项目成败的第一个关键环节。这不仅仅是“按下开关，程序就跑起来”那么简单。想象一下，你设计了一款智能工业网关，设备部署在偏远现场，一旦上电失败，就意味着高昂的现场维护成本和巨大的生产风险。此时，深入理解固化在芯片ROM中的那段“神秘”启动代码，就从一个学术话题变成了实实在在的工程保障能力。

ROM代码，是芯片出厂前就掩膜（Mask）或一次性编程（OTP）在芯片内部只读存储器中的一段不可更改的代码。它就像是设备的“先天本能”，在处理器完成复位、脱离安全启动（Secure Boot）状态后，第一个接过系统控制权。它的核心使命，是在一片“空白”或“未知”的硬件环境中，建立起最基本的运行秩序，并找到用户存储在外部设备中的“主程序”（我们称之为Initial Software，初始软件），然后将控制权平稳地移交给它。

这份技术文档所揭示的，正是一段典型工业级ROM代码的完整引导机制。它没有停留在“支持多种启动方式”的口号上，而是详尽地拆解了从CPU状态初始化、时钟树配置，到构建设备列表、按序尝试内存与外设引导，直至最终跳转到用户代码的每一个齿轮是如何咬合的。对于开发者而言，这份文档的价值在于：第一，它是进行底层系统调试的“地图”，当你的板子无法启动时，你知道该去检查SYSBOOT引脚配置、设备列表顺序，还是NAND Flash的坏块标记。第二，它是进行二次引导开发（如U-Boot SPL）的“设计蓝图”，你知道了ROM代码为你准备好了哪些硬件资源（如RAM布局、异常向量表），以及它期望从外部设备中读到什么格式的镜像。第三，它是系统可靠性的“基石”，理解看门狗（WDT）的超时机制、循环尝试引导的逻辑，能帮助你在设计自己的引导程序时避免陷入死循环，确保设备在最恶劣的条件下也有恢复的可能。

接下来，我将以一个深耕嵌入式系统十余年的开发者视角，带你穿透技术手册的表格与流程图，还原一个真实、立体且充满工程细节的ROM引导世界。我们会从宏观架构走到微观配置，从理论原理落到实操引脚，并分享那些只有踩过坑才能获得的经验。

2. ROM代码的架构与启动序列解析

2.1 三层架构：从硬件抽象到引导逻辑

ROM代码并非一团乱麻，它采用了清晰的三层架构设计，这种设计思想与常见的嵌入式软件（如驱动模型）一脉相承，体现了良好的软件工程实践。

硬件抽象层（HAL）是整个体系的基石。它直接与最底层的硬件基础设施IP（Intellectual Property，知识产权核）打交道，例如直接配置通用内存控制器（GPMC）的时序寄存器、设置UART的波特率发生器、或者操作I2C控制器发送一个START信号。这一层的代码高度依赖具体的芯片型号，其目标是向上层提供一个稳定、统一的硬件操作接口，屏蔽不同IP核在寄存器位定义、操作序列上的细微差异。例如，无论下层是哪种型号的NAND Flash控制器，HAL层提供给上层驱动层的函数可能都叫nand_read_page()。

驱动层建立在HAL之上，负责实现特定外设的通信协议和逻辑。例如，对于NAND Flash，驱动层要实现ONFI或标准Read ID命令的发送、页（Page）读取、坏块检测等逻辑。对于UART引导，驱动层则要实现XMODEM协议的数据包接收、校验和应答。这一层是协议相关的，它利用HAL提供的“砖瓦”，构建起了与具体外设“对话”的能力。

高层逻辑层是ROM代码的“大脑”。它不关心具体如何读NAND的一个扇区，也不关心UART数据包的校验算法。它负责整体的引导策略和流程控制：配置看门狗防止死机、初始化系统时钟树、解析SYSBOOT引脚状态以生成设备引导列表、并按照这个列表顺序，调用相应的驱动层功能去尝试寻找可启动镜像。图4-1所示的架构图，清晰地表明了这种自上而下的调用关系：高层调用驱动，驱动调用HAL。

实操心得：理解架构的意义理解这个分层架构，在调试时能帮你快速定位问题。如果UART引导不通，但UART终端已有输出，那问题可能出在驱动层的协议处理（如XMODEM）或高层对镜像的校验上。如果完全没输出，则可能需要向下检查HAL层的UART初始化，甚至追溯到引脚复用（Pin Mux）配置是否正确。这种分层思考方式，能极大提升排查效率。

2.2 冷启动后的第一步：公共ROM的启动序列

当芯片经历冷复位或热复位后，首先执行的是安全ROM代码，完成信任根验证等安全启动流程。此后，CPU才跳转到公共ROM代码的入口，即地址0x20000处，开始执行我们关注的公共引导部分。

图4-5的启动序列图描述了这个过程：

1. __main()与栈设置：这是由C语言运行环境（通常由编译器提供，如ARM Compiler的__main）自动完成的步骤。它负责初始化零初始化（ZI）段和已初始化数据段，并设置C代码运行所需的栈指针。这意味着，ROM代码的主体部分是用C语言编写的，提高了开发效率和可维护性。
2. 看门狗定时器（WDT）配置：这是一个至关重要的可靠性设计。ROM代码会配置MPU的看门狗定时器2，并将其超时时间设置为3分钟。为什么是3分钟？这是一个工程上的折衷：时间太短，在慢速设备（如需要初始化的NAND Flash）或网络状况不佳的以太网引导时容易误触发；时间太长，一旦引导流程真的卡死，设备“变砖”的恢复时间又过长。这个看门狗是整个引导流程的“总保险丝”。
3. 系统时钟配置：ROM代码会初始化关键的锁相环（DPLL）和时钟分频器，为后续的外设访问和代码执行提供稳定的时钟源。如表4-7所示，它会将ARM核锁定在600MHz，L3互联总线锁定在220MHz，DDR控制器锁定在400MHz，USB相关时钟锁定在960MHz/192MHz。这里有一个关键点：ROM代码的时钟配置是一个“最小可行”配置，旨在满足自身引导需求，并非芯片的最佳性能配置。用户的主程序（如U-Boot、操作系统）在接管后，通常需要根据实际应用重新优化时钟配置。
4. 跳转到引导主循环：完成上述基础初始化后，代码最终跳转到main()函数（此处指引导流程的主函数），开始执行核心的引导逻辑。

2.3 CPU与内存的初始状态：一张白纸

了解ROM代码执行时的CPU和内存环境，对于编写与之衔接的二级引导程序（如SPL）至关重要。

• CPU状态：MMU（内存管理单元）是关闭的，这意味着没有虚拟地址到物理地址的转换，所有访问都是直接的物理地址。L1指令和数据缓存也是关闭的，以确保对内存和外设的访问是确定性的。分支预测同样未启用。公共异常向量表基地址被设置为0x20000（ROM起始地址）。对于多核系统中的从核（Slave CPU），ROM代码不做任何额外配置，保持复位后的默认状态（所有缓存和MMU关闭）。
• 内存映射：如图4-3和4-4所示，ROM和RAM的布局是固定的。
  • ROM区域（0x20000 - 0x2BFFF）：包含异常向量、CRC校验码、一系列“死循环”（Dead Loops）用于调试、代码段、常量数据以及一个API表。其中“死循环”的地址是固定的，当程序跑飞或发生未处理异常时，PC指针可能跳转到这些地址，通过调试器查看PC值就能快速定位错误类型。
  • 公共RAM区域（0x402F0400 - 0x4031FFFF）：这是ROM代码和后续用户代码共享的舞台。其中0x402F0400到0x4031B800约173KB的空间，用于存放从外设（如UART、以太网）下载的引导镜像。0x4031B800开始是6KB的公共栈空间。0x4031D000处是RAM异常向量表，ROM中的异常向量会跳转到这里，为用户提供自定义异常处理程序的入口。0x4031D040开始的区域存放了跟踪向量（Tracing Data），像“黑匣子”一样记录了引导过程的执行路径，是高级调试的利器。

注意事项：RAM使用冲突ROM代码对RAM区域的使用是硬性规定的。如果你的二级引导程序（SPL）或裸机应用也使用这片RAM，必须严格避开ROM代码使用的区域，特别是下载镜像区和栈区，否则会导致数据被覆盖，引发不可预知的崩溃。最安全的做法是，参考图4-4的内存映射图，在自己的链接脚本（Linker Script）中明确分配代码和数据的存放位置。

3. 引导流程的核心：设备列表与两种引导路径

ROM代码引导的核心逻辑，可以用一个简单的决策树来概括：读取配置 -> 生成设备列表 -> 按序尝试 -> 执行或循环。图4-2和图4-6清晰地描绘了这一流程。

3.1 设备列表的生成：SYSBOOT引脚的解码

设备列表不是凭空产生的，它的来源是芯片上的一组专用引脚——SYSBOOT引脚（在文档中常称为BTMODE[4:0]）。这些引脚在上电复位时被硬件锁存，ROM代码通过读取控制模块（CONTROL Module）中的相应寄存器来获取其电平状态。

表4-8是这个过程的“密码本”。它列出了32种（5位引脚，2^5=32）可能的配置模式。每一种模式都定义了一个最多包含4个设备的引导顺序列表。例如，当BTMODE[4:0] = 00000时，引导顺序为：1. UART, 2. XIP w/ WAIT (MUX0), 3. MMC, 4. SPI。ROM代码会严格按照这个顺序，依次尝试从每个设备引导。

常见配置解析：

• UART优先（如00000, 00001）：这是最常用的开发调试模式。板卡上电后，ROM代码会首先尝试从UART0接收镜像。开发者可以通过PC端的工具（如TI的CCS的串口加载器）将编译好的镜像发送给板卡，实现无需烧写Flash的快速迭代开发。
• MMC/SD卡优先（如10110）：这是很多消费类或工业产品的量产模式。将系统镜像文件（如u-boot.img）按照特定格式（如FAT32文件系统中的MLO文件）存放在SD卡中，插入板卡即可启动，便于现场升级和维护。
• NAND Flash优先（如10001）：这是成本敏感的嵌入式产品最主流的量产启动方式。系统镜像被烧录到板载的NAND Flash中，设备上电后从中加载。
• XIP（NOR Flash）优先：适用于对启动速度有极致要求，或系统非常简单无需搬移的场景。代码在NOR Flash中直接运行。
• 以太网（EMAC）或PCIe优先：常用于网络设备或需要从主机直接引导的特定应用场景。

踩坑记录：SYSBOOT引脚的上拉/下拉SYSBOOT引脚内部通常有弱上拉或弱下拉电阻，但其阻值可能不足以在强电磁干扰环境下稳定保持电平。在设计底板时，强烈建议为这些引脚配置明确的外部上拉或下拉电阻（如10KΩ），以确保每次上电时引导模式都准确无误。我曾遇到过因省掉这些电阻，在产线测试时偶尔启动失败的问题，排查良久才发现是引脚电平受干扰浮动。

3.2 内存引导（Memory Booting）：从存储介质直接加载

内存引导，针对的是那些可以作为“启动盘”的非易失性存储介质，包括NOR Flash、NAND Flash、SPI EEPROM和MMC/SD卡。其核心思想是：从存储设备的固定位置，读取一个预先存放好的、格式正确的镜像文件到RAM（或直接在原地执行），然后跳转执行。

图4-8展示了内存引导的通用流程。关键在于区分设备是否为XIP（Execute In Place，原地执行）设备。

• XIP设备（如NOR Flash）：CPU可以通过内存总线直接读取其内容并执行，无需拷贝。ROM代码只需配置好内存控制器（如GPMC）的时序（见图4-9和表4-9），然后直接跳转到NOR Flash映射的地址（通常是0x08000000）去查找并执行镜像。
• 非XIP设备（如NAND Flash, MMC/SD）：这些设备的接口协议复杂，CPU无法直接取指执行。ROM代码需要先将镜像从设备中拷贝（Shadowing）到内部RAM中，然后再从RAM执行。这个过程就是“镜像搬移”。

镜像的查找与验证： ROM代码会在存储设备的特定起始区域（对于NAND/MMC是前几个块，对于SPI是起始地址）搜索一个“有效的镜像”。一个有效的镜像，其开头的4个字节（一个32位字）不能是全0（0x00000000）或全1（0xFFFFFFFF）。这只是一个非常初步的“魔数”检查，更完整的镜像格式校验（如TI的GP Header，包含大小、入口地址、校验和等）通常在镜像被加载到RAM后，由镜像头中的信息引导完成。

3.3 外围设备引导（Peripheral Booting）：从主机动态下载

外围设备引导，是开发阶段的“瑞士军刀”。它通过UART、以太网（EMAC）或PCIe接口，从外部主机（通常是开发PC）动态下载镜像到设备的内部RAM，然后执行。这个过程被称为“下载的软件（Downloaded SW）”引导。

核心价值在于灵活性：

1. 快速开发迭代：无需反复烧写Flash，修改代码后直接通过串口或网络加载运行，极大提升调试效率。
2. 工厂烧录（Pre-Flashing）：这是“外围设备引导”的一个特例。ROM代码可以运行一个特殊的“Flash Loader”小程序，这个小程序再通过USB、UART等接口，接收来自主机的完整固件镜像，并将其编程（烧写）到板载的NAND Flash、SPI Flash等永久存储介质中。这是产品量产时进行固件灌装的关键步骤。
3. 系统恢复：当Flash中的镜像损坏导致设备无法启动时，可以通过预留的UART或以太网口，利用外围引导功能重新下载一个完好的引导程序，进而修复系统。

协议与流程： 外围引导不是简单的数据灌入。ROM代码（作为从设备）和主机工具（作为主设备）之间需要遵循一套主从逻辑协议进行同步。例如，在UART引导中，通常使用XMODEM协议来保证数据传输的可靠性；在以太网引导中，则可能使用BOOTP/TFTP协议。主机必须先与设备建立连接（如UART波特率同步、以太网链路UP），然后发送镜像的二进制内容。ROM代码负责接收、校验并将其放置到RAM的“下载镜像区”（0x402F0400）。

4. 关键设备引导的深入剖析：以NAND Flash为例

在众多存储设备中，NAND Flash因其高容量、低成本成为嵌入式大容量存储的首选，但其引导过程也最为复杂。下面我们深入拆解ROM代码对NAND Flash的引导支持。

4.1 NAND引导的挑战与ROM的应对策略

NAND Flash不是XIP设备，且存在以下特性，使得引导过程比NOR Flash复杂得多：

1. 接口复杂：需要通过命令、地址、数据周期来操作，而非简单的内存读写。
2. 存在坏块：出厂时和在使用中都可能产生不可靠的块，引导程序必须能识别并跳过它们。
3. 需要ECC：NAND Flash存储单元可靠性有限，必须使用ECC（纠错码）来纠正读取过程中可能出现的位错误。
4. 多样化的规格：页大���（512B, 2KB, 4KB, 8KB）、块大小、总线宽度（8位/16位）、厂商命令集等差异巨大。

ROM代码通过一套完整的初始化、检测和读取流程来应对这些挑战，如图4-12所示。

4.2 初始化与设备检测流程详解

第一步：GPMC时序配置ROM代码首先将通用内存控制器（GPMC）配置为访问NAND Flash的模式。图4-11和表4-12定义了具体的时序参数，如读写周期（t_wr,t_rd为30个时钟周期）、片选到输出使能的时间（t_OEon为7个周期）等。这些时序参数是根据典型的NAND Flash器件在55MHz GPMC时钟下的特性预先定义好的，旨在保证读写的稳定可靠。

第二步：设备检测与参数获取这是最关键的一步。ROM代码采用了一种“先ONFI，后查表”的兼容性策略。

1. 尝试ONFI标准：首先发送ONFI（Open NAND Flash Interface）标准的Read ID（0x90）命令到地址0x20。如果器件是ONFI兼容的，它会回复一个包含“ONFI”字符串的签名。随后，ROM代码发送Read Parameter Page（0xEC）命令，从返回的数据页中直接提取页大小、块大小、总线宽度等关键参数（见表4-13）。这是最理想的情况，参数来自器件自身，绝对准确。
2. 回退到查表法：如果ONFI识别失败（旧型号或非ONFI闪存），ROM代码会执行标准的Read ID（0x90）命令到地址0x00。返回的ID字节流中，第二个字节是“设备ID”。ROM代码内部维护了一个庞大的支持器件表（表4-14），通过匹配这个ID来查找对应的参数。表4-15展示了如何从ID的第4个字节解析出页大小、单元类型（SLC/MLC）和块大小。这里有一个重要细节：文档指出，只有容量大于等于2Gb的器件，才会根据第4字节更新块大小参数。对于更小的器件，块大小被硬编码为128KB（当页大小为2KB时）。这意味着，如果你使用一颗小容量但页/块规格特殊的NAND，可能需要使用下文提到的NANDI2C模式。

第三步：坏块检测在确定了前4个块（Block 0-3）是ROM代码搜索镜像的区域后，它必须检查这些块是否是坏块。NAND Flash的坏块信息通常记录在每个块的第一页和第二页的备用区（Spare Area）的第一个字节（8位设备）或字（16位设备）中。如果这个位置的值不是0xFF（或0xFFFF），则该块标记为坏块。ROM代码会跳过被标记为坏块的区域，继续在后续好块中寻找镜像。如图4-13所示。

第四步：ECC配置ROM代码会启用GPMC和ELM（Error Location Module）硬件模块来进行BCH（Bose–Chaudhuri–Hocquenghem）纠错。默认是每512字节扇区纠正8位错误（BCH8）。对于某些特定的大容量MLC器件（如ID为D3h,C3h且制造商码为98h的器件），如果其第4个ID字节指示为特定单元类型，则会启用更强的BCH16纠错。ECC的启用是自动的，无需开发者干预，但这解释了为什么ROM代码需要初始化ELM模块。

4.3 NANDI2C引导模式：应对“非标”Flash

对于无法通过ONFI或标准ID表识别的“非标”NAND Flash，TI的ROM代码提供了一种巧妙的备用方案：NANDI2C引导模式。 在这种模式下，ROM代码不会尝试去识别NAND本身，而是转而通过I2C总线（使用I2C0，从地址0x50）去访问一颗外部的I2C EEPROM（如表4-16所示）。开发者需要预先将这片NAND Flash的几何参数（页大小、块大小、总线宽度、ECC类型等）按照特定格式（表4-17）烧录到这颗EEPROM的0x80起始地址。 ROM代码读取这些参数后，就“知道”了如何与这片NAND通信，然后继续进行坏块检测和镜像加载。这为使用特殊或新型号NAND Flash提供了极大的灵活性。

实操要点：NAND镜像的存放位置ROM代码默认在NAND Flash的前4个块（Block 0-3）中寻找引导镜像。你的二级引导程序（如SPL）必须被烧录在这个区域。同时，你必须确保Block 0是好块。在生产烧录时，烧录工具需要先读取坏块表，避开坏块，将镜像连续地写入好块中。ROM代码在搜索时，会自动跳过它识别出的坏块。

4.4 镜像搬移（Shadowing）过程

对于NAND这类非XIP设备，找到有效镜像后，ROM代码会启动搬移过程（图4-10）：

1. 首次读取：第一次读取一个扇区（512字节）时，数据被暂存到一个临时的RAM缓冲区。
2. 解析镜像头：从临时缓冲区中解析镜像的头部信息（如TI的GP Header），获取镜像的总大小和目的加载地址（Destination Address）。
3. 正式搬移：知道了目的地址和总大小后，ROM代码会重新从NAND Flash的起始位置读取数据，但这次是直接拷贝到目的地址（通常是内部RAM的0x402F0400区域）。镜像头本身在搬移后会被丢弃，因此最终RAM中目的地址起始处就是第一条可执行指令。
4. 跳转执行：搬移完成后，PC指针跳转到目的地址，用户代码开始执行。

5. 高级主题与调试技巧

5.1 快速外部引导（Fast External Boot）

这是一种极简的引导模式，在表4-8中对应BTMODE[4:0] = 01110或11110。当配置为此模式且检测到需要等待监控时，ROM代码会执行一个“盲跳”：

1. 以最少的配置（不配置PLL）初始化GPMC。
2. 直接跳转到地址0x08000000（CS0片选对应的XIP设备地址）开始执行，且CPU处于ARM模式。 如图4-7所示，这个过程极快，几乎不消耗时间。它的目的是将引导的完全控制权交给外部存储设备中的代码。这要求存放在0x08000000处的代码必须是位置无关的，且能自己完成后续所有的硬件初始化（如时钟、SDRAM）。这通常用于对启动时间有极端要求的场景，或者用户希望完全自定义引导流程。

5.2 跟踪向量（Tracing Data）：引导过程的“黑匣子”

位于RAM地址0x4031D040开始的跟踪向量区域（表4-6），是高级调试的宝藏。ROM代码在执行关键步骤（如开始尝试某个设备、设备初始化成功/失败、找到镜像等）时，会将特定的追踪代码（Trace Code）写入这些内存位置。 通过调试器（如JTAG）在设备复位后但用户代码运行前，读取这些区域的值，可以精确还原ROM代码的执行路径。例如，如果设备卡死在引导循环，你可以通过查看追踪向量，判断是死在NAND检测阶段，还是死在了UART连接阶段。TI通常会提供一份非公开的详细追踪代码列表，用于其内部和深度客户支持。对于开发者，意识到这个“黑匣子”的存在，在向原厂寻求技术支持时能提供关键信息。

5.3 异常向量表的重定向

ROM在0x20000处有自己的异常向量表（表4-3）。但除了复位向量，其他异常（如IRQ、FIQ、数据中止等）都被重定向到了RAM中的0x4031D004-0x4031D01C区域（表4-5）。这些RAM位置最初包含加载PC的指令，PC的值则来源于其后的地址（0x4031D024-0x4031D03C），而这些地址默认被初始化为指向ROM中的各个“死循环”（Dead Loops，见表4-4）。这为用户提供了钩子（Hook）：在你的引导程序或早期启动代码中，你可以修改0x4031D024-0x4031D03C这些地址的内容，使其指向你自己的异常处理程序。这样，当在ROM代码执行期间（概率极低）或你的早期代码中发生异常时，就能跳转到你的自定义处理程序，而不是死循环。这为捕获早期启动错误提供了可能。

5.4 常见问题排查指南

基于上述原理，我们可以梳理出一个实用的排查思路：

最后一点个人体会：理解ROM引导机制的最高境界，不是记住所有的表格和地址，而是建立起一个清晰的状态机模型。在脑海里想象：芯片上电 -> 锁存引脚 -> 初始化最小系统 -> 读取配置生成列表 -> 进入循环，尝试A设备 -> 成功则跳转，失败则尝试B设备 -> 全部失败则看门狗复位或重新循环。当你调试启动问题时，沿着这个状态机一步步用工具（万用表、示波器、调试器、串口打印）去验证每个环节的状态，问题自然无处遁形。这份文档，就是绘制这个状态机最权威的图纸。