芯驰SemiDrive_开发指南

1 · 文档导读与阅读路径

本章说明这份文档的覆盖范围、事实来源与书写约定。车规 SoC 的资料体系横跨芯片手册、SDK 发布说明、内核文档与车规标准，先划清边界比直接跳进技术细节更省时间。

这本指南的定位是「地图」而不是「手册」：手册回答「这个命令什么参数」，地图回答「我现在在哪、要去哪、走哪条路」。所以全篇的组织逻辑比个别细节更重要——三主线（座舱 X9 / 网关 E3 / 控制 MCU M9）贯穿选型、启动、硬件、存储各章，任何一节都可以顺着主线找到上下游。对存储应用工程师，阅读重心建议放在第 5、10、12、16 章与附录 A：这五处覆盖了「烧录、参数、分区、排查」的完整闭环。指南与官方文档的关系是「导读与正典」：这里建立机制层面的理解与排查框架，具体数值、命令细节、寄存器定义一律以官方 datasheet 与 SDK 文档为准。遇到「指南说某处以官方为准」的地方，正确动作是当场去查原文并把结论记在旁边——这份被标注过的指南，用上半年就会变成你自己的项目手册。

1.1 覆盖范围

本文档覆盖芯驰 SemiDrive 车规平台从选型到量产的完整链路，主线是三条产品线：座舱 X9 系列（多屏信息娱乐与座舱域控）、网关 E3 系列（总线汇聚、路由与区域控制）、控制 MCU M9 系列（实时控制与功能安全）。软件侧以 Linux BSP + U-Boot + 设备树为主线，同时覆盖 BootROM 启动机制与安全启动链；硬件侧覆盖供电、时钟、复位、启动配置引脚与外挂 Flash 连接；应用侧覆盖存储驱动与设备树 Flash 参数、车载通信、低功耗与调试。

对存储应用工程师，本文档的重点是第 10 章（存储接口实战：驱动与设备树 Flash 参数）与第 16 章（不开机故障排查速查表）：前者把 SPI NOR / SPI NAND / SD NAND / eMMC 的识别机制、设备树属性与分区表讲透，后者把「点不亮」按先硬件后软件的顺序拆成可执行的排查步骤。

三条主线不是三个平台，而是一套 BSP 之上的三个产品档位：设备树框架、驱动模型、存储子系统是共用的，差异集中在核数配置、外设组合与安全等级上。这意味着在一个型号上积累的启动链与存储经验，可以大部分平移到同族其它型号上——本文档「先共性后差异」的组织方式，就是按这个事实设计的。

「覆盖范围」不是一句口号，它决定了遇到问题时该不该翻开这一章。判断标准很简单：这个问题是否落在「车规平台 × 存储应用」的交叉带上。落在带内的——启动介质怎么选、Flash 参数怎么配、分区怎么划、烧录怎么防错、不开机怎么查——本指南给出完整的机制讲解与排查路径；落在带外的——模拟电路设计细节、功能安全概念层认证流程、具体业务算法——本指南只建立最小够用的背景，然后指向权威资料。覆盖范围的另一个含义是「深度边界」：机制层面讲透（为什么这样设计、坏了会怎样、怎么验证），实现层面克制（寄存器地址、位域、默认值一律不写死，因为那些数字随版本漂移，写进文档就等于埋下过期陷阱）。如果某个问题在本指南里找不到答案，先看它在第 16 章的速查表里挂在哪一节，再顺着交叉引用走——全篇的交叉引用网络就是为这个用途织的。

1.2 不覆盖什么

• 不逐条翻译芯片参考手册（TRM）。寄存器级定义、位域说明请以官方 TRM 为准；本文只写「哪一层负责什么、按什么顺序配、错了什么现象」。
• 不覆盖座舱图形 / 多媒体 / AI 栈的应用层开发。Hypervisor 配置、显示 pipeline、音视频框架只在第 6 章给出入口与机制，具体以 SDK 中间件文档为准。
• 不做功能安全认证流程的完整论述。ISO 26262 相关只在机制层说明（LockStep、ECC、安全岛、看门狗），认证级的安全案例与文档不在范围。
• 不替代 SDK 发布说明与勘误（Errata）。已知缺陷以官方勘误为唯一依据；版本差异以 SDK 发布说明为准。
• 不写商业数据。单价、市场份额、产能、厂商排名一律不出现，选型只谈能力匹配与机制。

边界的价值在排障时才显现：知道「这个问题归谁管」，就能少走一半弯路。比如「启动不起来」可能是硬件（第 7 章范围）、可能是启动配置（第 3 章范围）、也可能是镜像损坏（第 5 章范围）——三类原因的排查工具和负责人完全不同，先分类再动手，这正是第 16 章排查总原则的第一条。

「不覆盖什么」这一节是在保护读者：车规项目的失态里，有相当比例不是「不知道」，而是「知道一点就动手」。模拟与电源设计的细节交给硬件团队，本指南只在排障需要的粒度上讲（怎么量、正常值去哪查）；功能安全的概念体系交给安全团队，本指南只讲与存储应用工程师相关的机制层（安全监控、状态迁移、失效响应）；操作系统内核的通用知识交给内核文档，本指南只讲这个平台上的定制点与坑。对不覆盖的内容，本指南给出「去哪里找」而不是「是什么」——这是刻意的取舍：半桶水的知识比没有知识更危险，因为它会让人跳过验证直接下结论。真要往深走，每章末尾的交叉引用与附录 D 的资料索引就是入口，从那里拿到的是一手资料，而不是二手的转述。

1.3 版本与事实来源标注约定

车规平台的型号规格与 SDK 结构随版本变化较快，本文对三类来源采取不同写法，读到标注时请回到对应来源核对：

凡是本文没有给出精确数值的地方（主频、容量、DDR 频率、分区偏移、波特率），都是刻意不写死：这些数字属于「以正式 datasheet / SDK 为准」的范畴，写进文档反而会在版本切换时误导。本文给的是机制、顺序与判据。

三类来源冲突时的仲裁顺序：官方 datasheet 管硬件事实（电气参数、引脚、strapping），官方 SDK 管软件事实（目录、命令、属性支持），标准编号管机制定义。任何一处「文档说 A、实测是 B」，以实测加官方渠道确认为准，并记录到项目的勘误表（D.4）——这份表积累半年后，会比任何资料都值钱。

「以官方 SDK / datasheet 为准」这个标注在全篇出现几十次，每次都不是免责声明，而是一个动作指令：停下来，去查原文，把结论记下来。为什么敢把机制讲透却不敢写死数值？因为寄存器地址、位域定义、默认配置这些东西的生命周期是按「版本」计的——一次 SDK 升级就可能让文档里的数字全部过期，而过期的数字比没有数字更糟：它会让人信心满满地配错。版本差异的处置有一条纪律：任何跨版本的操作都不要混用，查资料时先确认手上 SDK 的版本号，再找对应版本的文档；拿新版本的截图配旧版本的固件，是「环境漂移」类问题的主要来源。实操建议：把常用数值（时钟频率、分区偏移、 strapping 表）整理成自己项目的「参数速查卡」，每项标注来源文档与版本，随项目演进维护——这张卡比任何通用文档都准，因为它只描述你的板子。

1.4 代码与命令书写约定

• 命令行以 $ 前缀标识；设备树片段、配置文件用代码块整段给出；属性名与命令名用 行内代码。
• 路径分隔符一律用 /，Windows 宿主与 Linux 构建机通用。
• 设备树示例中的频率、片选号、分区偏移均为演示值，板级实现时按实际分区表与器件参数填写。
• 镜像名（SPL、U-Boot、内核 Image、dtb）按功能称呼，实际文件名以 SDK 构建产物为准。
• 引图一律用「第 N 章」文字指向，不用超链接锚点，避免图号重排后错位。

所有命令与代码块都遵循「能照着敲一遍」的标准：上下文完整、占位符明确、不省略关键步骤。如果某一段你照着做却得不到文档描述的结果，优先怀疑环境差异（工具链版本、内核版本、单板配置），而不是文档错了——把差异点记下来，就是下一次排障的线索。

全篇的代码与命令分三类，读法不同。「演示片段」用来展示结构与写法，里面的值是演示值——直接照抄到生产环境之前，每个值都要用自己的 datasheet、原理图、分区规划替换一遍。「维护命令」用来现场操作，执行前先想清楚在动哪个分区、错了怎么退，尤其是带写性质的命令（烧录、擦除、改环境变量），第一条纪律都是先备份。「配置示例」用来对照官方绑定文档检查自己的写法，重点是结构而不是数值。三类内容有个共同点：都是「机制层」的展示，不含任何可以直接投产的参数——这是铁律，不是风格。把演示片段改造成自己项目内容的标准动作是「三查」：查 datasheet 确认电气参数、查原理图确认连接关系、查分区规划确认偏移容量；三查过了再上板，上板后再走「改一处、验一处」的流程。示例的价值在结构清晰，你的责任是填对每一个值。

1.5 阅读路径建议

不同角色的最佳入口不同。下表按角色给出起点与路径，全篇章节相互独立，可按需跳读；但第 16 章建议在读完第 7、8、10 章之后再读，那三章是它的前置。

最后提醒一句「跳读」的副作用：第 16 章的每一步都假设你已经知道启动链分几段（3.1）、strapping 决定什么（3.6）、分区表长什么样（10.6）。跳读没问题，但遇到看不懂的步骤时，回到对应章节补五分钟，比硬猜快得多。

2 · SemiDrive 家族全景与选型

选型的第一刀不是比参数，而是先定应用域：座舱、网关还是控制。域定了，产品线就定了，剩下的问题收窄成「哪一档型号 + 什么存储组合」。本章给出谱系、规格判据、存储搭配与决策树。

阅读路径按「你现在最疼的问题」选，不要按章节顺序硬啃。排障路径（板子出问题了）：第 16 章速查表定位小节 → 顺着交叉引用回第 3（启动链）、第 5（烧录）、第 10（存储参数）、第 12（设备树）看机制 → 附录 A 找命令与 log 关键字。移植路径（旧平台迁过来）：第 2 章选型建立背景 → 第 15 章逐项对差异 → 第 12、13 章补设备树与调试 → 第 16 章兜底。选型路径（新项目立项）：第 2 章 + 附录 B 走完选型逻辑 → 第 7、8 章给硬件团队提需求 → 第 10、11 章定存储方案。三条路径都建议配一份「问题清单」并行记录：读的过程中冒出来的问题、现场遇到的现象、待确认的参数，全部落纸——这份清单的积累速度，就是你上手速度的真实度量。全篇最值得反复回读的是第 16 章：第一遍当流程看，第二遍当字典看，第三遍当检查单看，每一遍的用法都不一样。

2.1 这颗芯片处在什么位置

从 MCU 迁移到车规 SoC，变化的不只是主频，而是软件形态：MCU 是「一个程序管全部」，SoC 是「多核 + 操作系统 + 启动链 + 设备树」。一颗典型的车规 SoC 内部至少有三类处理器核：跑 Linux 的 Arm 应用核（A 核）、跑 RTOS 或安全监控的实时核（R 核）、以及负责验签与密钥的安全子系统（HSM 或安全岛）。存储也分裂成两个角色——启动介质（放 BootROM 之后的第一级镜像）与数据介质（放内核、根文件系统与业务数据），两者可以是同一颗 Flash，也可以是两颗。

芯驰 SemiDrive 的产品线正是按这三个域划分的：X9 系列面向智能座舱，E3 系列面向车载网关与区域控制，M9 系列面向实时控制 MCU。对存储应用工程师来说，选型阶段就要回答三个问题：启动介质用什么、数据介质用什么、容量与温度等级留多少余量。这三个问题的答案会一路影响设备树、分区表、驱动参数，直到第 16 章的排查判据。

理解位置比记住型号更重要：在整车电子电气架构从分布式 ECU 向域控演进的背景下，座舱域、网关域、车身控制域各自需要一颗算力与安全等级匹配的主控。SemiDrive 三条主线对应这三个域位——选型的第一步不是比参数，是确定自己的产品落在哪个域位、面向哪个功能包。

理解「这颗芯片处在什么位置」，要放到整车电子架构里看。车规 SoC 通常坐在域控制器的位置：座舱域管显示与交互、网关域管通信与诊断、车身 / 动力域管实时控制——它上面跑的是多阶段启动链加多核异构的完整软件栈，下面接的是 DDR、Flash、各种车载总线。这个位置决定了三件事。一是「责任重」：域控制器是整车的计算节点，它不启动，对应域的功能全停，所以启动可靠性与故障恢复手段（第 3 章的回退链、第 16 章的变砖恢复）在设计里占的权重远超消费电子。二是「环境苦」：-40 ~ 125摄氏度 宽温、点火干扰、振动，硬件设计与物料选型都要按车规等级做（第 7、11 章）。三是「接口杂」：CAN FD、车载以太网、诊断通道、安全监控都要在软件栈里有一席之地，软件栈因此比同算力的消费平台厚得多。把这三件事想清楚，再看后面的启动链、设备树、存储参数，就知道每个设计点背后「为什么车规平台要这样」。

2.2 产品族谱系一张表

先建立全景。三条产品线共享 BSP 与设备树框架，差异在算力、外设组合与安全等级上。下表按产品线汇总定位与特征，具体型号命名以官方选型手册为准。

谱系全景见下图。注意每一行的「存储特征」——它直接决定第 10 章要配哪些驱动与设备树节点。

读族谱图的要点是「先看列再看行」：列是应用域（座舱 / 网关 / 控制），行是档位梯度。同一列内档位差异主要是算力与成本的平衡，跨列的差异则是架构性的（核类型、安全等级、实时性）。存储特征行单独列在最下，是因为它直接决定启动链设计与分区规划——这是存储应用工程师看这张图的正确姿势。

谱系表的读法是「先分线再分档」：先按用途分三条线（座舱、网关、控制），每条线的基因不同——座舱线重多媒体与显示接口，网关线重通信与低延迟，控制线重实时性与功能安全；再在每条线里按算力、接口数、安全等级分档位。命名规律摸清之后，看到一个新型号能猜个八九不离十：后缀与档位的对应关系、同档位不同封装、同系列不同温度等级。但「猜」只能用来初步筛选，最终确认一律以官方选型资料的规格页为准——同族型号的差异有时就藏在几个不显眼的格子里（某个高速接口的有无、某个安全特性的档位）。另一个实用提醒：代际差异比档位差异更值得关注，跨代际的 SDK、工具链、甚至启动流程都可能有变化，迁移成本要按代际评估而不是按档位评估。项目选型时把「候选型号的三代以内演进路线」问清楚，比死磕当前规格更有长期价值。

2.3 主要型号与关键规格

下表按「型号档位」汇总关键规格维度。本文刻意不写精确主频、核数与容量——这些数字必须从官方 datasheet 取，写进任何二手文档都有过期风险；表中给出的是选型时要核对哪些项。

规格表要横着读、竖着比：横着读是把一个型号的「算力 - 内存 - 存储 - 外设 - 安全」看成一套组合，任何一项短板都会拖累整体；竖着比是同档位跨系列对比，找出同一预算下的能力差异。特别提醒：主频与算力数字在车规场景里很少是瓶颈，真正的瓶颈通常是内存带宽与存储 IO——这也解释了为什么本文档把存储单独拉出两章重点讲。

规格表不要顺着念，要按「门槛项、性能项、生态项」三类分开看。门槛项不过，后面全免谈：温度等级（-40 ~ 125摄氏度 是上车门槛）、车规认证（AEC-Q100 一类）、功能安全等级（按 ISO 26262 的 ASIL 需求）。性能项决定「够不够用」：CPU / GPU / NPU 算力、显示接口数与分辨率、车载网络接口、存储接口带宽——这些按业务的峰值需求加余量评估，不能按平均值。生态项决定「好不好用」：SDK 成熟度、工具链完善度、参考设计数量、社区与原厂支持响应速度——这一项在参数表上完全没有，却最影响项目周期；评估方法是找已经量产过的项目打听，或者申请评估板实际跑一周。规格表的另一个陷阱是「峰值参数」：标称算力和实际可用之间隔着散热设计、内存带宽、软件栈效率三层折扣，看参数表乘个系数再谈「够不够」。存储相关规格（支持的启动介质、接口速率、最大容量）直接翻到 2.5 与第 10 章细看，那是本指南的主场。

2.4 每档型号的典型应用场景：座舱、网关与控制

座舱场景（X9）：一芯驱动仪表、中控、副驾屏甚至后排屏，同时跑 Android / Linux 多系统，外接摄像头与麦克风阵列。存储压力最大——rootfs 动辄数 GB，还要给 OTA 留双分区；启动介质常用 SPI NOR（小、可靠、XIP），数据介质用 eMMC 或 UFS。

网关场景（E3）：把车身各处的 CAN FD、LIN 汇聚到车载以太网，做路由、诊断与区域控制。算力要求不高，但实时性与确定性要求高：报文转发时延、时间同步（PTP / gPTP）、诊断刷写通道。存储以 SPI NOR 启动 + 小容量 eMMC 存配置与日志为主，容量不大但掉电可靠性要求高。

控制场景（M9）：电机控制、车身控制、电池管理（BMS）。程序以实时控制为主，功能安全等级最高（LockStep、ECC、看门狗、安全监控），Flash 常用片内 Flash + 外置 SPI NOR 做参数与校准数据存储，擦写寿命与掉电保护是存储设计的重点。

从场景反推配置比从参数正推更可靠：先描述「这块板子在车上干什么、和谁通信、掉电频率多高、数据量多大」，再决定核数、内存与存储组合。反过来做（先看参数表选一颗，再想能干什么）是选型翻车的标准路径——尤其在存储上，数据量与掉电频率两个场景问题，直接决定介质类型与保护策略。

「场景 → 规格」的推导方法比记住结论重要。座舱场景：驱动规格的是显示路数、分辨率、视频解码能力、以及图形交互的算力需求——存储侧对应的是大容量数据介质（eMMC / UFS 档位）、频繁的地图与媒体写入、开机速度体验（启动时间优化见 13.5）。网关场景：驱动规格的是车载网络接口数量与类型（CAN FD、车载以太网）、协议转换的实时性、诊断通道（DoIP）的可靠性——存储侧对应的是日志与配置的中等容量、写寿命的仔细核算（日志是写大户，11.4）、掉电保护的严格要求（车辆下电不可预期）。控制场景：驱动规格的是实时核能力、功能安全等级、外设接口的丰富度——存储侧对应的是小容量高可靠的启动与参数介质、对启动确定性的要求（不能有秒级抖动）。三个场景对存储的共同要求是「车规等级 + 掉电安全 + 寿命余量」，差异在容量与带宽档位。选型时把自己的场景按这三条线归类，再对照谱系表，候选范围一轮就能收窄。

2.5 存储搭配：各型号支持的启动与数据介质

同一颗 SoC 可以同时挂多种存储介质，各自承担不同角色。下表给出介质与角色的通用对应关系，是否支持以具体型号的 BootROM 能力与 SDK 驱动清单为准。

最常见的组合是「SPI NOR 启动 + eMMC 数据」：NOR 放 SPL 与 U-Boot（小、可靠、掉电不丢），eMMC 放内核、dtb、rootfs 与业务数据。成本敏感方案会把 rootfs 也放进 SPI NAND；极端低成本方案用 SD NAND 替代 eMMC。组合一旦确定，第 10 章的驱动清单与第 12 章的设备树节点就确定了。

存储搭配的一条经验法则：启动介质选「最不容易坏的」，数据介质选「容量与寿命最匹配的」，两者分开。启动介质坏了板子直接变砖（恢复成本见 16.13），数据介质坏了往往还能启动、还有抢修窗口。所以「启动加数据都用同一颗 eMMC」看似省钱，实则把两类风险绑在一起——除非掉电保护做得非常扎实，不建议这么干。

存储搭配的三条硬约束先摆出来，再谈档位。约束一，启动链路要求：BootROM 支持的启动介质与位宽以平台为准（第 3 章），选型时先确认「这颗芯片默认从哪启动、 strapping 能选哪些介质」——启动介质选错，后面全盘皆输。约束二，数据量与写入量：按业务的峰值算，日志与 OTA 是两个最容易被低估的写入源（OTA 一次就是整包容量）。约束三，寿命与掉电：车规介质按整车生命周期的写入量留余量，掉电行为（内部缓存、写流程）要实测。三个约束交叉完，介质组合基本就定了，剩下的才是容量档位的微调。搭配变更的连锁反应要提前想：换启动介质 → strapping 与烧录脚本全改；换数据介质 → 设备树参数、分区表、文件系统全改；容量档位跳档 → 分区表与烧录镜像全改。这些连锁项应该列成一张「变更影响清单」随选型文档走，现场换料时照着清单逐项核对，是防止「换了料忘了改分区表」这类事故的唯一可靠办法。

2.6 SPI NOR / SPI NAND / SD NAND / eMMC 档位怎么选

介质选择的本质是在容量、成本、寿命、掉电可靠性之间取舍。下表给出各介质的适用边界，容量档位与寿命指标以器件 datasheet 为准。

三条实操结论：启动介质优先 SPI NOR（BootROM 支持最广、虚焊与掉电风险最低）；数据盘默认 eMMC（生态最成熟、分区与 boot 分区机制完整）；容量超过 eMMC 经济线或带宽不够时上 UFS。车规项目无论选哪种，温度等级一律选 -40 ~ 125摄氏度 宽温档，并留出擦写寿命余量（见 11.4）。

四个档位的分工可以一句话记住：NOR 管启动与参数，NAND 管大容量数据，SD NAND 管成本敏感的中间档，eMMC 管高性能主力。选档时先回答三个问题：数据量多大、写入多频繁、掉电多常见——三个答案一交叉，可选范围通常只剩一两个，剩下的工作是和原厂确认车规等级与供货。

四类介质的分工先记牢：NOR 管启动与参数（简单、可靠、掉电不丢），NAND 与 eMMC 管数据（容量与带宽），SD NAND 介于两者之间（SD 协议的易用性加 NAND 的成本）。档位选择的思路是「按角色定介质、按余量定容量」。容量余量算多少是个经验活：日志类按「最长无维护周期 × 峰值写入速率 × 3 倍余量」，OTA 类按「两套完整镜像 + 一套下载暂存」，参数类按小容量起步但要能承受格式变更。跳档的决策看两点：当前档位是否触顶（占用率长期超过七成就要规划跳档）、跳档成本是否可控（分区表与烧录镜像的变更工作量）。有个反直觉的经验：容量略有余量比刚好够用更省钱——「刚好够用」意味着每次需求增长都要走一遍改分区、改脚本、重新验证的完整流程，而这些隐性成本远超介质差价。降档设计（用更小容量）则是纯风险行为，唯一的合法场景是成本压力极大且需求被冻结验证过，即便如此也要在文档里写清降档依据与风险。

2.7 与同类车规方案的取舍

车规 SoC 的候选池里，既有国际大厂的成熟平台，也有本土厂商的多家方案。对比时建议只看四个维度，不纠缠宣传口径：SDK 开放度（设备树与驱动的可修改范围、源码交付程度）、存储驱动完整度（你选中的 Flash 料号是否已在支持列表、加新料要走多少流程）、安全启动成熟度（证书链、密钥分级、产线烧录流程是否文档化）、长期供货与本地支持（供货年限承诺、FAE 响应、勘误发布速度）。

对存储应用工程师，第二项往往是隐性成本的大头：如果目标 Flash 料号已经在 SDK 的兼容列表里，工作量是「改几行设备树」；如果不在，要走完整的「加料号 → 验证 → 签名 → 分区」流程（第 10 章与第 16 章展开）。选型阶段就把目标料号拿到手，比项目中期再换料代价小一个数量级。

横向比较的正确姿势是「按自己的清单比」而不是「按对方的宣传比」：先把需求整理成一张检查清单（算力、存储接口、安全等级、温度、供货周期、生态成熟度），再让每个候选方案逐项填。脱离清单的比较会陷入参数军备竞赛——车规项目里，生态成熟度与长期供货的权重，往往比峰值算力更高。

横向对比的正确姿势是「按项目约束加权打分」，不是「参数表谁数字大」。先列自己项目的硬约束：预算上限、开发周期、团队经验栈、既有代码资产、供货周期要求、功能安全等级——每项给权重。再按约束评估候选：生态成熟度（有没有量产参考、工具链是否完善、踩坑资料多不多）、供货能力（生命周期承诺、产能、地缘风险）、迁移成本（从团队现有平台迁过来要改多少）。参数性能在这套评估里往往不是决定性项——车规场景的性能需求通常保守，真正卡项目的是生态与供货。评估方法上，能申请到评估板就申请，实际跑一周比看十份对比文档都准；跑不了评估板的，至少把「启动一个 demo、烧录一次、改一次设备树」的完整流程在候选平台上各走一遍，流程顺滑度的差异会非常直观。最后提醒：对比结论要写下来、注明信息来源与日期——选型是长周期决策，半年后回头看「当初为什么选它」，有记录和没记录是两种结局。

2.8 选型决策树

把前面的判断浓缩成一张决策树：先定应用域，再在域内按屏数 / 总线 / 实时性定档位，最后定存储搭配。

决策树的两个分叉点常被搞反：一是「多屏高算力」未必需要最高档——先算屏幕路数与编解码需求，再回头看核数；二是网关与控制域对存储容量不敏感，但对掉电可靠性与启动时间敏感，别用座舱思路选它们的数据盘。

决策树的价值不在于「选出正确答案」，而在于把隐性假设显性化：每一个分支都是一个必须回答的问题（应用域是什么、数据量多大、要不要安全启动）。走完树的过程，就是把模糊的需求逼成明确规格的过程。走不下去的那个分支，就是需求还没想清楚的地方——先回去想需求，别急着选型。

决策树的用法是「从场景倒推，每个分叉都要判据」。入口是场景（座舱 / 网关 / 控制），第一层分叉通常是硬门槛（功能安全等级、温度等级），不过线的候选直接出局——门槛项没有「努力一下够一够」的空间。第二层分叉是容量与带宽（数据量、写入量、媒体路数），这里需要的是 2.5 的存储搭配分析。第三层分叉是生态与供货（工具链、参考设计、供货周期），评估方法见 2.7。走到叶子节点时，手上应该有一到两个候选而不是一个——单候选没有对比就没有谈判筹码，也没有 Plan B。收敛之后的动作不是「下单」，而是「验证」：申请评估板跑 demo、把关键外设与存储介质在候选平台上各验一遍、把验证结果归档。决策树还有一个隐藏价值：它是团队沟通工具——选型结论用决策树的形式讲一遍，「为什么选它不选它」就不需要反复解释，新人问起时一张图讲完。

2.9 选型时最容易忽略的五件事

1. 启动介质与 strapping 的匹配：BootROM 从哪个介质起跳由启动配置引脚决定，原理图设计时就要和板子实际焊接的介质一致（见 7.4 与 16.4）。
2. DDR 贴片与训练：SoC 的 DDR 参数和具体贴的颗粒强绑定，换 DDR 料号可能要求重新训练与改配置，属于「选型即锁定」项。
3. 存储的温度等级与寿命：座舱内温度剖面恶劣，消费级料号上车是事故源头；同时按写入量估算擦写寿命并留余量（见 11.4）。
4. 安全启动对流程的影响：开启安全启动后，SPL / U-Boot / 内核 / dtb 全部要签名，产线烧录与 OTA 流程都要改（见 3.5 与 5.6），选型时就要确认支持。
5. SDK 版本与内核版本绑定：SDK、U-Boot、内核、设备树绑定文档是配套发布的，跨版本混搭是很多「诡异问题」的根因，升级要整包评估（见 4.5）。

这五件事的共同点是「选型时看不见、量产时才要命」：温度等级不够，环境试验后批量失效；供货周期没确认，量产前换料重做验证；安全启动支持度没核，OTA 方案推倒重来；存储驱动完整度没验，新料号加不进去；软件生态没评估，BSP 缺陷没人修。每一项的核实动作都不大，但漏掉任何一项的返工成本都是以月计。

这五件事有个共同特征：不影响「选型时能不能跑起来」，只影响「量产时会不会出事」——所以它们在选型评审里最容易被跳过，而在售后账单上最贵。逐类说处置。温度与寿命等级：看料号的车规标识与寿命承诺，别按消费级经验推断；拿不准问原厂。供货周期：料号的生命周期承诺、产能、停产预警机制，设计冻结前必须确认——「性能完美但即将停产」的料号是定时炸弹。启动介质支持：确认 BootROM 对目标介质的支持与位宽，别等原理图画完才发现启动链路走不通。掉电行为：介质的内部缓存与写流程决定掉电保护怎么设计，选型阶段就要拿到 datasheet 的电源与写时序章节。维护通道：烧录口、调试口、恢复口在选型时就要规划——量产封掉调试口的方案，售后恢复成本要高一个数量级。五个都过完，建议做成选型评审的固定检查单，缺一项不开会——把「容易忽略」变成「流程保证不忽略」，是这一节唯一可靠的用法。

2.10 供货与长期供货承诺

车规项目的生命周期通常按 10 ~ 15 年计，选型时必须确认三件事：目标料号的长期供货承诺（年限与条件以官方供货政策为准）、温度与车规等级（AEC-Q100 等级与 -40 ~ 125摄氏度 覆盖）、封装与兼容替代（是否有同封装同Pin 的上下延伸料号，便于后期调容量）。量产前建议再核对一次料号状态与发布批次，避免项目中期遇到「不推荐用于新设计」的尴尬。

供货承诺的落实要留证据：长期供货函、车规等级证书、以及关键料号的发布批次记录，都进入项目档案。车规项目的「新设计不推荐」通知有时来得很突然，手里有替代料号的预研记录，就能把一次断供危机降级成一次常规换料验证。

3 · 启动链、BootROM 与安全启动

「不开机」的排查之所以能结构化，是因为启动本身是结构化的：BootROM → SPL → U-Boot → 内核 → 用户态，每一级只做固定的事，失败也只以固定的方式失败。本章把这条链和它的安全变体讲清楚，第 16 章的排查全部建立在这条链上。

启动链的起点是 BootROM，这段固件烧在芯片里、不可更新——这个「不可更新」属性决定了它在排障里的特殊地位：它永远是你手上那套逻辑的「原始裁判」，但也是你永远改不了的「黑盒」。BootROM 的行为因此只能「顺应」不能「修正」：它支持什么镜像格式、认什么 strapping、探测介质的顺序，都以平台固定行为为准，遇到不兼容只有换镜像、改硬件两条路。排障时 BootROM 的价值在于「它吐的每一点信息都是真的」：没有软件栈的缓冲与美化，输出直接反映硬件状态。所以「上电后第一条 log」是全篇排查链的入口（16.6），看不到它时的第一反应不是「串口坏了」，而是「BootROM 都没跑起来，查供电与时钟」（16.2 / 16.3）。安全启动的信任根也在这一段——后面整条证书链的可信度，最终锚定在 BootROM 里那段不可更改的代码上。

3.1 复位后第一条指令与 BootROM 的位置

SoC 上电、复位释放后，CPU 从片内固化的取指向量开始执行第一条指令，指向的是片内 Mask ROM 里的 BootROM 代码。这段固件在芯片流片时写入，用户改不了——升级 BootROM 能力等于换芯片。它的运行环境极其朴素：不依赖外置 Flash、不初始化 DDR，只做最小初始化（关看门狗、起主时钟、建栈），然后立刻去按启动配置找下一级镜像。

BootROM 的行为可以概括成四步：读启动配置 → 按介质协议加载镜像 → 校验镜像 → 跳转执行。它不认识文件系统，只认约定格式的「镜像」；它也做不了复杂外设驱动。理解这一点很重要：BootROM 阶段的失败，几乎全部落在「介质选错、镜像格式错、校验不过」三类上，而不是「驱动没编进去」——后者是内核阶段的问题。

BootROM 的存在解释了很多「反直觉」现象：你的代码还没开始跑，芯片已经做了十几个决策——从哪个介质起跳、镜像合不合法、要不要验签、DDR 参数用哪套。理解这一点，排障时就不会只说「我的程序没反应」，而是会问「BootROM 走到哪一步了」——后者才是可定位的问题。

介质探测与回退链的设计意图只有一个字：容。启动介质会坏（虚焊、磨损、掉电写一半），系统不能因为一次介质故障就变砖，所以 BootROM 按优先级尝试多个介质，全部失败才停。理解这条链对排障的直接价值：boot 卡在探测阶段时，嫌疑范围是「当前优先级介质 + strapping 电平」，而不是整个系统——先用读回比对确认当前介质里的镜像完整，再核 strapping，一轮就能定位。回退链的代价是启动时间：每多一个候选介质，最坏情况就多一段探测时间，所以链的长度是「可靠性 vs 启动速度」的权衡，车机场景常见的是「主介质 + 一个备用介质」。A/B 双分区设计（升级用）和回退链是两层不同的东西：回退链是 BootROM 层的介质级容错，A/B 是应用级的版本级容错，两者叠加时要注意「回退到哪个槽位」的语义别混。量产固件里回退顺序是固定配置，不要指望现场能改——改不了的东西，就要在选型与验证阶段确认它对。

3.2 启动介质探测与回退链

BootROM 按启动配置引脚（strapping）锁存的优先级依次探测启动介质：主介质读不到镜像、镜像头校验不过、跳转后看门狗超时，都会降级到备介质；全部介质失败则进入下载模式（USB / UART 专用协议），等待 PC 端工具烧录——这也是变砖后的救砖入口。

镜像头是「BootROM 与镜像之间的合同」：头里声明的大小、加载地址、入口地址、校验值，任何一项和 BootROM 的期望不符，结果都是拒绝加载。手工拼镜像或改过分区布局后，第一件该做的事就是核对这份「合同」——很多「烧进去了但不启动」的案例，根因都是头与内容对不上。

镜像格式是 BootROM 与构建系统之间的「合同」：头部字段告诉 BootROM 这个文件多大、加载到哪、校验和是多少、有没有签名。合同的含义是双向的——构建系统按格式产出，BootROM 按格式消费，任何一侧对合同的理解变了（SDK 升级、打包工具换版本、启动配置改动），另一边就可能不认。实践中最高频的事故是「内容没错、格式没人认」：手工改过镜像文件、用旧工具打包新配置、或者构建缓存命中了旧版本的中间产物。对策在 4.4 与 5.4：镜像必须来自完整构建流程、烧录前验哈希、烧录后读回比对，三道关卡里任意一道都能拦住「内容对格式错」的镜像。格式兼容性还有个隐性成本：跨 SDK 版本的镜像互不通用是常态，所以「升级 SDK 就要全量重编重烧」不是洁癖，是格式合同的必然要求；试图「只换内核不动 Boot 链」的增量升级，先确认格式合同没变再动手。

3.3 BROM 支持的镜像格式

因为不解析文件系统，BootROM 只支持固定格式的镜像，常见三类：

• 带头部镜像：镜像前部带一个头部，描述镜像长度、加载地址、入口地址与校验值；BootROM 按头部把镜像体拷到目标地址再跳转。这是最常用的形式，SPL 通常就是它。
• 原始二进制：无头部的纯二进制，按约定地址直接执行；只在特定引导场景使用，灵活性差。
• 签名镜像：安全启动开启时，镜像后附加签名与证书链信息，BootROM 先验签再执行（见 3.5）。

镜像由 SDK 的打包工具生成，不要手工拼接或裁剪：头部的加载地址、对齐与校验值任何一个不对，BootROM 都只会表现为「什么都不打印」。格式细节以官方 BootROM 手册为准。

镜像头是「 BootROM 与镜像之间的合同」：头里声明的大小、加载地址、入口地址、校验值，任何一项和 BootROM 的期望不符，结果都是拒绝加载。手工拼镜像或改过分区布局后，第一件该做的事就是核对这份「合同」——很多「烧进去了但不启动」的案例，根因都是头与内容对不上。

SPL 与 U-Boot 分两段不是历史包袱，是硬件逼出来的效率设计：芯片上电初期只有一小片内部高速内存可用，放不下完整的引导器，所以先用一个极小的 SPL 把 DDR 初始化好，再搬完整 U-Boot 进 DDR。这段「先小后大」的结构直接决定了排障时的分段思路：SPL 阶段的症状（无输出、中途停）指向 DDR 与加载链路，U-Boot 阶段的症状（起不来、boot 失败）指向环境变量与启动参数（16.8）。SPL 的职责边界要记清：初始化 DDR、把自己搬进去、跳转，就这三件事，多一件都可能是体积超限或行为异常的来源。U-Boot 最大的价值不是「引导内核」，而是「维护通道」——倒计时按键进命令行，等于给了你一个不依赖 Flash 内容的调试入口，16.13 的恢复手段一大半建立在「还能进 U-Boot」这个前提上。所以量产固件里 U-Boot 的命令行超时与权限要斟酌：完全封死是把最后的自救通道也关了。

3.4 SPL 与 U-Boot 的分工

完整 U-Boot 体积大，放不进 SoC 片内 SRAM，因此拆成两级：SPL（Secondary Program Loader）是精简版，跑在片内 SRAM 里，负责把 DDR、时钟等关键外设初始化起来，再把完整 U-Boot 搬进 DDR；U-Boot跑在 DDR 里，负责环境变量、命令行、网络与加载内核。

SPL 与 U-Boot 通常同源，由 SDK 构建产出两种裁剪版本；文件名与体积以 SDK 为准。排查时记住一条经验规律：log 能打到哪一级，故障就在哪一级的下一跳——U-Boot 命令行都出来了，问题基本不在硬件。

这个分工对排障的指导意义：SPL 阶段的问题几乎都是「环境问题」（DDR、SoC 配置、SPL 自身大小），U-Boot 阶段的问题开始出现「配置问题」（环境变量、设备树、启动参数），内核阶段才是「软件逻辑问题」的主场。看到 log 停在哪一环，就知道该换哪顶帽子。

安全启动的日常运维比理解机制更花时间，三件事要制度化。签名流程：谁签、在哪签、用什么密钥、签完怎么验证——流程要有审批与记录，不能是某个工程师的本机操作；量产镜像的签名密钥和开发密钥必须分离，开发密钥泄露不影响量产件安全。密钥与证书的版本管理：证书会轮换、密钥会更新，每次变更都要能回答「哪些版本固件用哪套证书」——这个问题答不清，现场遇到验签失败时就没有排查基线。验签失败的静默特性：安全设计刻意不在串口输出失败细节，诊断信息在 HSM 侧，所以「安全件无 log 不开机」的排查逻辑和非安全件完全不同（16.7），第一问永远是「最近动过签名链上的什么」。给存储应用工程师的特别提醒：镜像的存储位置与完整性也是安全链的一环——被篡改的镜像（哪怕格式正确）会被验签拦下，这是特性不是故障；反过来，安全件「恢复又变砖」的经典原因是恢复镜像没走签名流程（16.13）。

3.5 安全启动：信任根、证书链与 HSM

安全启动用非对称签名保证「执行的每一级镜像都被授权过」。链条自底向上：信任根是出厂时写入片内熔丝的根公钥哈希，不可更改；一级证书由厂商私钥签名、携带授权公钥；二级证书继续授权镜像签名密钥；最终镜像签名覆盖 SPL、U-Boot、内核与 dtb。BootROM 用信任根验证 SPL，SPL 验证 U-Boot，U-Boot 验证内核与 dtb，逐级放行。

验签运算在 HSM（硬件安全模块）或安全岛里完成，私钥与中间密钥不暴露给普通软件；HSM 同时提供真随机数与密钥存储服务。对开发流程的影响是实打实的：量产镜像必须走签名流程，OTA 升级包同样要签名，私自替换任何一级镜像（哪怕功能完全正常）都会导致验签失败、无法启动。证书格式、密钥分级与产线烧录流程以官方安全启动手册为准。

证书链的分层设计是为了「信任可以委派」：根密钥烧一次终身不变，二级密钥可以按产品线或按批次轮换，镜像签名用最末级密钥完成。工程上的直接好处是量产密钥不必和研发密钥混用，泄露二级密钥不用回炉根密钥。轮换与吊销的具体流程以官方安全文档为准——这套流程的严谨程度，直接决定车规项目的安全审计能否通过。

Strapping 是「用硬件引脚配软件行为」的经典设计：省掉了启动前的软件配置环节，但也把「改配置」变成了「改硬件」。原理图设计阶段有三个考量。可测试性：每个 strapping 脚的上拉 / 下拉要能在板上量到（测试点或足够的可探测性），产线才能快速核对配置对不对——量不到的脚，错了也发现不了。可变更性：需求会变（换个启动介质、调个位宽），如果 strapping 是靠改阻容实现的，每次变更都是改板；预留配置字（EEPROM 一类）承载启动配置的方案，硬件不用动，代价是多一个失效点。组合正确性：多脚组合表达完整意图，设计评审时要按官方 strapping 表逐组合核对，特别注意「半高电平」风险——分压电阻被下游负载拉偏的脚，量着有电平、采样成不确定，这类缺陷只在批量上电偶发失败时暴露。量产变更 strapping 的代价要写进变更流程：改 strapping 等于改硬件版本，涉及重新投板、重新烧录验证、重新环境试验，不是「刷个固件」能搞定的事。

3.6 启动配置引脚与 Strapping

strapping 引脚在复位释放瞬间被采样锁存，决定启动介质顺序、启动模式（正常启动 / 下载模式）、部分时钟来源等。锁存值在一次上电周期内有效：改配置必须断电重上电，按复位键热复位不会重新采样——这是现场调试最常犯的错。

硬件设计上，strapping 引脚的上下拉默认态必须指向「板子实际焊接的介质」：默认态选错，板子会安静地尝试从一颗不存在的 Flash 起跳，表现就是「完全不打印」。电平设计还要考虑车规电压余量（机制层见 7.7）。引脚定义以官方引脚手册为准，原理图互查见 7.4，排障操作见 16.4。

三种表象的排查价值完全不同，先说结论：无输出最难，因为有输出至少知道「电通了、芯活了、串口对了」，无输出意味着信息量为零，只能靠外部手段重建信息。三种表象对应的第一动作：完全无输出 → 硬件四步（16.2 ~ 16.5），先测电流、再看时钟、再核 strapping，不要碰代码；输出乱码 → 先对波特率，再测主时钟，串口本身反而是最后嫌疑；输出到一半停住 → 抓最后一条有效 log，按启动链顺序定位阶段（16.6），这是三种里最「友好」的，因为 log 已经把范围指出来了。方法论上有个通用原则：启动链是顺序推进的流水线，每个阶段的输出是下一阶段的输入，所以「症状出现的位置」等于「故障位置的下界」——输出到某阶段停了，故障就在该阶段或它的上游，不可能在下游。掌握这个原则，三种表象就都有了系统的排查起点，而不是凭运气翻代码。每次排查结束把「表象 → 阶段 → 根因」记进自己的案例库，三个月后这个库会比任何速查表都贴合你的项目。

3.7 启动失败的三种表象

启动失败按串口 log 能观察到的现象分成三种表象，三种表象指向完全不同的排查章节——先分类，再深挖。

三种表象里最迷惑人的是「停在 BootROM」：串口有输出说明供电、时钟、复位大概率没问题，但 BootROM 的静默失败（尤其是安全启动验签失败）可能连错误码都不打。这时候不要盯着 log 找答案，改用排除法：换已知良好的镜像、读回比对、换已知良好的板子——16.7 的顺序就是这么排的。

4 · 开发环境与工具链

车规 SoC 的开发环境比 MCU 重得多：交叉工具链、整包 SDK、多级配置、签名工具。本章不讲「点哪里」，只讲环境的结构与自检方法——环境类问题是第 16 章排查链的第一环。

SDK 目录结构的第一课不是「记住每个目录放什么」，而是「画一张自己的组件地图」：把 SDK 的顶层目录过一遍，每个目录标注三件事——用途、是否随版本升级、自己项目是否改过。这张图有三个直接用途：找东西时不用全盘搜索；升级 SDK 时知道哪些目录会变、自己的改动会不会冲突；新人入群时直接发图。纪律只有一条：没标注「可改」的目录默认只读——尤其是公共组件与第三方代码，改了之后每次 SDK 升级都是合并地狱，而且改动不随官方更新，等于给自己养一个永久分叉。确有必要改公共代码时，改动要集中、加注释、记进「本地修改清单」，这份清单和版本号一起归档（4.5）。目录里和存储应用最相关的是设备树目录、分区配置与烧录脚本——这三处的组织方式随 SDK 而异，以实际结构为准，但「改板级不改公共」的原则通用（12.2）。

4.1 SDK 的获取与目录结构

SDK 以整包形式发布，包含 boot、内核、BSP、设备树、工具与文档。目录名随版本可能调整，以发布说明为准，但功能结构是稳定的。拿到 SDK 第一件事不是编译，是把发布说明和 doc 目录读一遍。

SDK 目录里最值得先摸清的是三个位置：设备树源码在哪（你的 Flash 参数改这里，第 12 章）、构建产物落在哪（烧录时从这里取镜像）、以及文档在哪（属性支持列表以绑定文档为准）。这三个位置找到，后面所有章节的操作就有了地理概念。

交叉编译工具链是个组合：编译器把源码编成目标架构的指令，配套的库提供标准函数与运行时，调试器负责符号与断点——三者版本要成套，混搭的典型症状是「链接莫名失败」或「跑起来行为诡异」。版本匹配原则：优先用 SDK 打包提供或官方验证过的版本，这是兼容性最有保证的组合；社区版本可以作为补充，但要先确认内核与库的版本要求。工程上的两个建议。一是环境固化：把工具链版本、SDK 版本、构建命令写进环境说明，有条件就做成容器镜像或固化到构建机——「我机器上能编」不是能力，「任何机器按说明都能编出同一份二进制」才是。二是构建产物可比对：同一份源码、同一套工具链，两次构建的产物应该一致（可复现构建），这个性质是后续「镜像校验、版本追溯、现场恢复」全部信任链的基础；构建机换了、工具链静默升级了，产物比对就会失败——而这件事往往在排查问题时才被发现，太晚了。

4.2 交叉编译工具链

A 核侧（U-Boot、内核）用 aarch64 交叉编译器，R 核固用另一套工具链，两者不要混。工具链版本以 SDK 要求为准——版本不匹配的编译器能编过，但会在运行期暴露成难以理解的怪错。

工具链管理的工程建议：用 SDK 指定的版本，别用系统包管理器里的「最新版」；构建机尽量专用，别和日常开发混用；升级工具链前先确认 SDK 发布说明支持——编译器小版本的差异，足以制造「同一份代码两种行为」的噩梦。

配置体系的层级决定了「改一处影响一片」的边界：板级配置影响这块板的所有构建，产品级配置影响这个产品形态，用户级配置只影响个人调试。改配置前先判断自己在动哪一层——动错了层级的典型后果是「同事拉下去构建，行为和你不一样」，而这类问题在单机调试时永远复现不了。配置管理的三个实践。其一，配置变更走提交记录：谁、什么时候、为什么改了哪个配置项，可追溯是基本要求；口头说的「帮我打开某个选项」是配置漂移的开始。其二，配置文件本身纳入版本控制，和源码同仓管理——配置也是资产，散在个人机器里的配置等于不存在。其三，构建产物与配置的对应关系要能反查：拿到一个镜像，应该能回答「它是用哪套配置编的」（4.5 的版本标识就是干这个的）。对存储应用工程师，重点盯三类配置：设备树选择、分区表、烧录目标——这三项配错的共同特征是「编译全过、上板全错」，而它们恰好处在配置体系里最容易被想当然点错的位置。

4.3 配置文件体系

配置分四层，改动的层次决定影响面：板级配置文件选目标板；defconfig 决定编入哪些功能（U-Boot 与内核各有一套）；设备树描述硬件长什么样；环境变量决定「这一次怎么起」，存在 Flash 里可改。

• defconfig 回答「编什么」——驱动没编进内核，设备树写得再对也 probe 不到。
• 设备树回答「硬件是什么」——片选、频率、分区全在这（第 10、12 章）。
• 环境变量回答「这次怎么起」——bootargs、启动介质选择，改动最小、生效最快，但别把临时改动留到量产。

配置文件体系的排障价值在于「改动可回溯」：环境变量改了忘了改回、defconfig 被某次实验污染、设备树里留着上一版板的节点——这类问题的统一解法是把配置纳入版本管理，每次改动有记录。现场板子和参考板表现不一致时，先 diff 配置再 diff 代码。

构建系统的正确用法是「理解依赖，尊重流程」。依赖关系上，内核、U-Boot、SPL、设备树、rootfs 各有各的构建入口，最终由打包工具按镜像格式组装——任何一个组件改了，走它的完整构建，不要试图「只重新打包」。增量构建是效率工具也是陷阱：构建系统有缓存，改了配置或换了工具链时，缓存可能命中旧的中间产物，表现是「改了源码没生效」；遇到这种怪现象，先做一次清理再全量构建，能省掉几小时怀疑人生。产物追溯是构建流程的纪律：每次构建记录「源码版本 + 配置版本 + 工具链版本 + 产物哈希」，四元组缺一不可——现场拿到问题镜像时，这四样是反查「它是谁在哪编的」的唯一线索。还有一个常被忽视的动作：构建完成后看一眼产物清单，确认该有的都在（dtb、分区描述、签名后的镜像），缺件的构建比失败的构建危险得多——失败会报错，缺件会静默地给你一个「能烧但不能启动」的包。

4.4 编译、打包与镜像生成

典型流程如下，命令与目标名以 SDK 脚本为准，本文只固定顺序：先 boot 后内核，先镜像后打包，最后才生成烧录包。

# 1. 准备环境（SDK 附带的环境脚本）
$ source <sdk>/env-setup.sh
# 2. 选择板级配置目标（名称以 SDK 目标列表为准）
$ make <board>_defconfig
# 3. 编译 boot：产出 SPL 与 U-Boot
$ make boot
# 4. 编译内核与设备树：产出 Image 与 dtb
$ make kernel && make dtbs
# 5. 构建根文件系统：产出 rootfs 镜像
$ make rootfs
# 6. 打包：组合镜像并写入版本标识
$ make image
# 7. 生成烧录包：交付产线
$ make pack

任一步失败，先看该阶段的构建日志而不是从头重来；构建日志里「缺文件」多半是上一步没产出，「符号未定义」多半是配置没选。打包阶段同时是安全启动项目的签名入口，开启安全启动后这一步必须使用签名工具（见 5.6）。

打包阶段还有一个容易忽略的动作：把校验值（哈希）和镜像一起存档。产线比对、售后恢复、OTA 断点续传都要用它，事后再算一次哈希当然也行，但存档的习惯能省掉「这个镜像到底是不是当时那份」的争论。

版本标识的作用在出问题时才显现：现场一块板行为诡异，第一句问「什么版本」，答不上来，后面所有排查都打折。所以标识的设计要求是「机器可读、人可读、不可伪造」三合一。机器可读：版本号嵌在镜像的固定位置，工具链能自动提取（烧录校验、OTA 升级都依赖它）；人可读：启动 log 里能看到版本行，串口一抓就有（16.6 的 log 关键字表第一项就是它）；不可伪造：和安全启动的签名配合，篡改版本号会破坏验签——没有这一条，版本号只是「建议」。工程上的两个做法：版本号由构建系统自动生成（源码版本 + 构建序号 + 时间），不靠人工填；每个版本一份发布说明，镜像哈希、变更内容、已知问题一一对应。版本号与烧录脚本、设备树、分区表的绑定关系（17.5 的版本对齐）要能互相追溯——「这块板跑的固件、配的设备树、划的分区，三者是不是一套」必须可回答，这是量产现场最高频的困惑。

4.5 固件版本与构建标识

固件版本要在三个地方可查：U-Boot 启动 banner（串口第一屏就能看到）、内核 cmdline 的构建标识、构建信息文件（随镜像发布）。现场板子出问题，拍一张串口照片就能反查固件版本，比翻记录靠谱。

• 量产镜像与版本一一对应，烧录记录里带版本号，售后可追溯。
• 整包升级原则：SDK、U-Boot、内核、设备树绑定文档一起升；只升其中一个，兼容性风险最高。
• 构建要可复现：同一份源码 + 同一版本工具链 → 同一份镜像。做到这一点，才能排除「环境漂移」类问题。

版本标识的落地细节决定它能发挥多大作用：标识里除了版本号，还应包含构建时间、源码提交点与构建机信息。现场反查时，这三项能直接定位到「哪次提交、哪台机器、什么配置」，把归因从小时级压缩到分钟级。

环境自检的触发时机比清单内容更重要：每次环境变更后必跑——新机器、新成员、SDK 升级、工具链更新、构建脚本修改，全都算。共享环境还要加一条：多人共用的构建机或烧录机，谁改了什么要有记录，否则「昨天还能编今天不行」的悬案会反复出现。自检失败的处置分级：阻断类（工具链缺失、版本不匹配、串口不通）直接停，带着问题环境往下走只会浪费更多时间；告警类（某个可选工具缺失、文档版本滞后）记录后继续，但要标注影响范围。自检清单建议脚本化：一条命令跑完，输出红绿清单，通过的把结果归档——归档的意义在于「环境什么时候开始坏的」可追溯，这个时间点往往就是某个诡异问题的引入点。给存储项目的特别项：烧录工具与镜像格式的匹配（5.4）、分区描述文件与设备树的一致性（12.4）、校验脚本的可用性（5.4），这三项不进自检清单，烧录类问题会在最忙的产线阶段爆发。

4.6 环境自检清单

新机器、新克隆的 SDK，先过一遍下面这张表再开始干活，能挡掉绝大多数「环境类灵异事件」。

自检清单建议做成 CI 或脚本：每次提交后自动跑一次干净树构建，失败的提交不允许合入。车规项目的软件变更频次远低于互联网项目，但每次变更都更接近硬件边界——用一条自动化的构建防线，换掉「量产前夜发现环境坏了」的惊心动魄，是性价比极高的一笔投资。

5 · 烧录与量产

烧录是研发与量产之间的桥。研发期关心「怎么把镜像写进去、写坏了怎么救」，量产期关心「防呆、校验与工时」。本章覆盖单机烧录流程、量产站位、校验方法与失败根因。

烧录接口的选择是「速度、可靠性、产线友好」三者的权衡。串口烧录慢但接线简单，适合研发调试与现场恢复；专用烧录器走标准调试 / 烧录协议，速度快、可并行、适合产线站位；网络烧录（以太网）适合已量产板子的在线维护，但对启动链路有要求。选择时容易忽略的是「维护口的预留」：量产封掉所有调试口的方案，等于把售后恢复的手段全砍掉（16.13 的恢复通道直接少一半），正确的做法是预留一个物理维护口（烧录器直连接点或受控的调试口），用权限和流程而不是「物理消失」来管安全。另一个常被问的问题是「一种介质要不要留两种烧录方式」——建议留：主方式跑产线，备方式（哪怕慢）留给现场恢复，两种方式的镜像格式与校验流程要一致，否则「产线烧得好好的、现场恢复烧不进去」的割裂会在第一次批量变砖时让你付出代价。

5.1 烧录接口全景

烧录入口按「谁发起」分两类：SoC 主动进入下载模式后等 PC 工具（USB / UART），或直接把恢复镜像放到介质里让板子自己找（SD 卡）。JTAG 是最后的手段——能绕过硬件的启动配置直接访问 Flash，但安全启动开启后受限。

接口选择的一条经验：研发期主力用 USB 下载（快且稳），UART 下载留给「USB 驱动装不上」的救急场景，SD 卡恢复镜像是售后现场的救命通道——建议每个项目都固化一颗「恢复卡」的制作流程，现场人员不看手册也能操作。

单机烧录流程的每一步都是为某一类失败准备的，跳过任何一步都是在给那种失败开门。备份（先读回原内容）防的是「烧错镜像想还原」；选镜像与选分区防的是「内容对、位置错」；烧录中的进度与日志防的是「中途失败无据可查」；烧后校验与读回比对（5.4）防的是「工具显示成功、介质内容不对」；最后启动验证防的是「单个分区烧对了、组合起来起不来」。最常见的流程破坏不是「跳过步骤」，而是「步骤做了但不记录」——烧了什么、什么版本、结果如何，没有记录的话，一次批量烧错能追溯到单板，却追溯不到「哪一批、哪个配置」。单机烧录的另一个纪律是「一次只烧一块」：批量烧录前先在单板上把流程跑通、把脚本参数确认对，再上批量——用产线批量操作来调试烧录参数，是「一夜烧坏一批板」的标准剧本。流程跑通后把「版本 + 分区 + 校验结果」记进烧录记录表，这张表是售后追溯的起点。

5.2 单机烧录流程

单机烧录按固定六步走，每一步都有明确判据，卡在哪一步就查哪一步：

1. 进入下载模式：按 strapping / 按键要求操作，必须断电重上电（见 3.6）；判据是 PC 工具能识别到芯片。
2. 连接与识别：工具识别芯片型号与 Flash；识别失败先查线与下载模式，不要重插十次。
3. 选择镜像与地址：镜像清单与烧录地址由分区表和 strapping 决定，用 SDK 打包产物，不要手填。
4. 执行烧录：观察工具的阶段进度；中途失败记录失败阶段。
5. 读回校验：烧录后读回比对（见 5.4），通过才算烧录完成。
6. 复位启动：恢复 strapping 到正常模式，断电上电，抓启动 log 确认。

一个常见失误是第 6 步忘了把 strapping 切回正常模式——板子「烧完还是不起」，其实是一直赖在下载模式里。

六步流程里第 3 步最值得强调：地址不要手填。分区表是「烧录布局」的唯一权威来源，手填地址的每一次「成功」都是在给量产埋一颗定时炸弹——分区表一调整，所有按老地址烧的板子全部错位，而且这种错位往往要到启动失败才暴露。

站位设计的核心权衡是「并行度 vs 故障定位粒度」：站位越多产能越高，但一块坏板经过多个站位后，故障被引入的时机就变模糊——是来料就坏、第一站烧坏、还是第三站碰坏？没有精细记录的并行线，最后只能整批返工。工时的测算要按瓶颈站位而不是平均值：烧录耗时（容量与接口决定）、校验耗时（读回比对是全容量读取，常比烧还慢）、以及人工上下板时间，三项里最长的那项就是节拍。实践中校验经常被低估——大容量介质上「烧三分钟、校验五分钟」是常态，用预估节拍排产、实际被校验卡住的案例比比皆是。站位间还要有质量门：每站出口做快速校验（至少读回关键分区比对），坏板不流到下一站，这是「坏板不出线」和「坏板流到底再返工」的成本分界。最后是治具与防呆的配合（5.6）：并行站的治具更容易混用，按板型做物理防反，比靠操作员辨认可靠一个量级。

5.3 量产烧录站位与工时

量产线的烧录不是「一步烧完」，而是拆成三个站位各司其职：烧录位只管写、校验位只管比对、自检位只管功能验证。拆分的好处是瓶颈清晰、不良品流向明确——烧录位失败直接送修，校验位失败说明「写进去了但内容不对」，自检位失败说明「软件起来了但功能不对」，三种不良的维修动作完全不同。

• 工时瓶颈通常在烧录速度（大容量 eMMC）与校验深度之间权衡：全量逐字节比对最稳但最慢，可按项目风险选 CRC + 抽点比对。
• 每块板子烧录时绑定条码与镜像版本，出问题能反查到具体固件。
• 工位数量按节拍算，别让烧录位成为整条线的瓶颈；不良品流单独设计，避免复烧品混入良品。

站位拆分的代价是治具与物流成本上升，所以小批量阶段常合并成单站位。判断标准很简单：当校验失败开始污染良品流、或者烧录位等待时间超过整线节拍的两成时，就该拆站了——用数据决定，不要用感觉。

两级校验的分工要说透：烧录前验哈希，验的是「我要烧的内容对不对」——防止拿错镜像、防止镜像在传递过程中损坏；烧录后读回比对，验的是「介质里的内容对不对」——防止写入过程出错（接触不良、电源跌落、坏块替换、ECC 写入异常）。两级都不可省：只做前一级，写入过程出错无感知；只做后一级，拿错的镜像会被原样写进去再原样读回，「比对一致」但内容全错。读回比对的实现细节：读回的是全容量还是关键分区，按节拍要求权衡，但关键分区（启动链、参数区）必须全覆盖；比对失败时的处置（重烧一次还是标记坏板）要有明确规则——重烧一次再失败按坏板流转，反复重烧同一片会掩盖接触不良的治具问题。校验记录（哪片板、什么版本、哈希多少、结果如何）随序列号归档，这是售后「这块板到底烧过什么」的唯一凭据。产线脚本里校验步骤不允许配置为「可跳过」——任何可跳过的校验，迟早会被节拍压力跳过。

5.4 镜像校验与读回比对

「烧录成功」的定义是读回内容与源镜像一致，不是工具进度条走完。常用两级校验：写完后由工具计算整片 CRC 与打包时记录的比对（快），高风险项目做逐字节读回比对（慢但最可靠）。

NAND 类介质（SPI NAND / SD NAND）还要多一层考虑：出厂坏块表与 ECC。烧录前按坏块表跳过厂检坏块，校验时用器件的 ECC 结果判据，不能简单按「读回字节相等」判断——某些位在读取时会被 ECC 纠正。

校验策略建议按介质分级：NOR 与 eMMC 可以全量 CRC 加抽点读回，NAND 类必须做坏块感知的校验。无论哪种，校验失败的板子不允许流到下工位——「带着疑点往下走」是量产质量事故的最大源头。

十类根因表的价值不在「背下来」，而在「按频率维护」——每个项目跑一段时间后，把自己遇到的烧录失败按十类归档，加权后排出自己项目的真实 Top 3，针对这三项做专项预防（治具改进、参数复核、流程加固），比通读十类有效得多。每类根因都配一个「第一判据」，这是表的使用方法：失败现象出来后，先用第一判据做一次二分，把范围砍到一类，再进该类细查。举例，「接触不良」的第一判据是换治具 / 换线复现——换了就好，直接锁定；「选错分区」的第一判据是回看烧录日志里的分区名与偏移——日志里写的和想烧的对不上，当场结案。还有一个元级别的经验：烧录失败的根因分布会随项目阶段迁移——试产期集中在「配置与参数」，量产期集中在「接触与治具」，售后期集中在「介质老化与变砖恢复」；不同阶段盯不同的 Top 3，才是动态使用这张表的方式。每处理完一类，把「现象 → 判据 → 对策」补进团队案例库，这张表就长在了项目上。

5.5 烧录失败的十类根因

下表按出现频率排列。前四类占现场问题的多数，且全部可以在 30 秒内验证。

十类根因的排查顺序本身就是一张决策路径：先验证「模式和线」（1、2 类，30 秒），再验证「镜像和地址」（3、4 类，看打包记录），最后才怀疑单板硬件（5 ~ 10 类，换件交叉验证）。跳过前两步直接换板子的人，会把「配置错误」误判成「批次不良」，白白报废一批好板。

安全与防呆分三个层次，只做一个层次的防线等于没有防线。工具层：烧录工具本身校验镜像版本与板型标识，不匹配直接拒绝——这是最基础的防呆，实现成本最低。治具层：物理防反、防呆销、按板型区分的治具编码，让「错的板插不进对的治具」——治具层的防呆在并行站位多、板型多的产线上价值最大。流程层：扫码绑定序列号与烧录记录、双人复核关键步骤、异常板隔离流程——流程层管的是「前两层都被绕过之后」的情况，靠的是记录与追溯而不是阻止。权限与审计是安全的另一半：签名密钥的使用要审批、烧录配置的修改要记录、产线终端的权限要最小化（5.6 与 3.5 的安全启动配合）。一个反常识的经验：防呆设计要做「故障演练」——定期在产线上故意用错镜像、错治具测试防线是否有效，防线没被演练过，就等于不存在；演练记录进产线质检档案，这也是车规体系审核时会被问到的项。

5.6 安全与防呆

量产防呆做三重：型号防呆（工具按芯片型号过滤镜像，防止把 A 板镜像烧进 B 板）、版本防呆（镜像版本与条码绑定，混版本立刻报警）、内容防呆（烧录后读回校验，杜绝「写了个空片」）。三重之外，建议在镜像里内置版本标识，板子起来第一屏就能看到（见 4.5）。

安全启动项目的烧录还要多一套密钥管理纪律：签名在受控环境完成、产线只拿签名后的镜像、私钥不落产线电脑、签名工具的使用有审计。任何「为了赶工把未签名镜像带上产线」的操作，都会在装车后变成无法远程修复的砖。

防呆设计的最高境界是「错了也烧不进去」：把镜像白名单（芯片型号 + 板级版本 + 容量档位）内置到烧录工具里，不匹配直接拒绝执行。这比事后校验更可靠——校验只能发现烧错，白名单能阻止烧错。白名单的维护纳入配置管理，每次改板或换料同步更新。