全志平台 · SPI NAND / SPI NOR 量产排查

编制日期 2026-10-14 ｜ 版本号 Rev 1.0

XTX 芯天下 · FAE 现场技术文档 ｜ Allwinner 平台外挂 SPI NAND / SPI NOR 量产排查 （BROM → boot0 → U-Boot → kernel）｜ 2026-09 版

结论：全志平台 SPI NAND / SPI NOR 量产失败， 99% 发生在启动链路的前两级（BROM 介质识别、boot0/SPL 加载）——而不是烧录器本身。 判别顺序是：先确认 BROM 有没有选对介质、有没有误进 FEL；再看 boot0 镜像头与签名过没过； 最后才是 SPL 的驱动表与分区表。烧录器绿勾只证明「镜像写进去了」，不证明「BROM 认它、boot0 能加载它」。

报告总结

解决的是全志（Allwinner）系列 SoC 外挂 SPI NAND / SPI NOR 时，量产阶段烧录绿勾却启动失败、 或上电即卡在极早期这一类问题的定位与根治。覆盖 F1C100s / F1C200s / T113 / T113-S3 / R328 / R329 / V851 / V833 / A40i / T507 / H616 等平台，启动链 BROM → boot0(spl) → u-boot → kernel （Linux / Tina / Melis / OpenWrt），烧录工具 PhoenixSuit / LiveSuit / sunxi-fel / 全志量产工具。 全文按「现象 → 机制 → 类目 → 立即动作 → 根治动作」组织，第 9 章是可直接翻查的速查表，第 10 章是防复发清单。

怎么用这份文档

1. 先抓完整串口 LOG：从上电第一行到最后一行全量保存，确定卡在 BROM / boot0 / U-Boot / kernel 哪一级。
2. 按 8 类根因归档：把现象归到第 3~8 章对应类目，不要一上来就换芯片或重烧。
3. 用 4 级断点法收敛：BROM 介质选择 → boot0 头/签名 → SPL 驱动表 → 分区/env，逐级确认。
4. 建立「已知好板」基线：把能启动那块板的 LOG、boot pins 电阻、sys_config.fex、分区表、SDK 版本各存一份。
5. 一次只改一个变量：boot 电阻、pinmux、签名工具、驱动表、分区表每次只动一处，改完重新上电抓 LOG。
6. 用装板实跑闭环：任何改动以「上电跑通完整启动 + 关键功能 + 一次断电重启」为最终判定。

1. 问题本质：全志启动链路与 SPI 控制器

「全志板子起不来」这句话在现场被用得太泛。它可能是 BROM 压根没选对外挂介质， 可能是 boot0 镜像头校验没过被直接丢弃，可能是 SPL 里没有新料号的驱动表， 也可能是 U-Boot 起来了却读不到正确的 env 或分区。本章先把现象还原成机制： 讲清全志的启动链路每一级在干什么、SPI 控制器是怎么把命令送到 XTX 器件的， 然后把本文的排查对象与「烧录器找不到型号」严格切开。

1.1 全志启动链路全景

全志 SoC 上电后，执行顺序是固定的四段：BROM（掩膜 ROM）→ boot0 / SPL → U-Boot → kernel。 每一段都依赖前一段成功地把下一阶段从外挂介质里读出来并校验通过。 任一段失败，系统都会停住或回退（典型是回 FEL 或反复重启）。

1.2 各平台与介质支持概览

全志不同 SoC 的 BROM 对 SPI NAND / SPI NOR 的支持程度、启动介质选择方式都不一样。 下表是常见平台与介质倾向，具体以该平台 SDK 的 sys_config.fex / 设备树与 BROM 支持列表为准。

1.3 SPI 控制器是怎么把命令送到 XTX 器件的

全志的 SPI 控制器是启动链路里「BROM → 器件」这段的物理通道。 CCU 时钟控制单元先给 SPI 模块提供总线时钟，再经 SPIx_CCR 时钟分频寄存器 得到最终 SCLK；SPIx_TCR 控制主从、模式、片选；数据经 TX/RX FIFO 收发。 引脚必须经过 pinmux 切到 SPI 功能（CS / SCLK / IO0..IO3）才能对外通信。

关键认知：BROM 与 boot0 用的是同一组物理 SPI 引脚。 这意味着如果 pinmux 在第一级就配错，后一级连重新配置的机会都没有—— 这正是「类目 1」最隐蔽的地方。另外，BROM 阶段可用的时钟分频档位有限， 低速下器件才容易识别，所以新料号若对时钟敏感，往往卡在最早期。

1.4 常用工具与命令（常见值）

下面是全志量产排查常用的工具与命令，命令与参数均为常见写法，以实际版本为准。

2. 方案总览：失败类别分流

全志平台 SPI NAND / SPI NOR 量产失败看似千奇百怪，但归根结底都能按 「串口 LOG 卡在启动链哪一级」归到 8 个类目、收敛到 4 个排查关卡。 本章先给一张分流图，再给一张介质/平台对比表，后面 6 章的所有动作都是在这张图里选一条往下钻。

2.1 失败类别分流图

拿到一块起不来的板，第一件事是接串口、上电、把从第一行到最后一行全量保存， 然后按下面这张图确定卡在哪一级。绝大多数现场争论（「是芯片坏了还是板子坏了」） 在看到 LOG 第一句之后就消失了。

2.2 介质 / 平台对比：SPI NOR 与 SPI NAND 的启动差异

同一块全志板，挂 SPI NOR 和挂 SPI NAND 的启动路径差异很大： NOR 通常直接从固定偏移读 U-Boot；NAND 要处理坏块跳过与ECC， boot0 必须带坏块表。换介质时最容易漏的就是这一点（见第 5 章类目 4）。

2.3 四关断点法

与第 1 章的机制对应，量产排查把四关串起来：每一关只回答一个是非题。

3. 类目 1·2：BROM 介质识别失败 / FEL 误触发

这两类都发生在启动链最早期（BROM 阶段），是信息最少、工具最少、却最高发的类。 它们的共同表现是「串口几乎一行不出」，区别是：类目 1 是 BROM 选错了介质（boot pins / pinmux 错）， 类目 2 是 BROM 主动放弃、转进 FEL。先分清这两类，后面才不会在错误的方向上耗时间。

3.1 类目1：BROM 无法识别外挂介质

BROM 是掩膜在 SoC 里的第一段代码，它上电后先采样 boot pins， 根据电平决定去哪个介质找启动代码，再通过 SPI 控制器把 boot0 读进来。 这条链路上有两处最常断：

• boot pins 配错：上下拉电阻焊错、被其它电路拉偏，导致 BROM 选成 SPI NOR 去读 SPI NAND（或反之）。
• SPI 引脚复用错：pinctrl / sys_config 里这几个引脚没切到 SPI 功能， BROM 阶段就发不出波形（因为 BROM 用的也是这组物理引脚，没机会在后面修正）。

3.2 类目2：FEL 模式被误触发

FEL 是全志的 USB 下载模式。正常量产不应该进 FEL——它只在两种情况下出现： 用户按住了 FEL 键（特定 GPIO 被拉低），或者 BROM 找不到有效启动介质 / boot0 校验失败而主动回退。 现场常把「进 FEL」误判成「芯片坏了」，反复换料，其实板子一直在等你插 USB。

3.3 立即动作与根治动作

4. 类目 3·8：boot0 签名失败 / eGON 与 SPL 头校验失败

这两类都发生在 BROM 加载 boot0 的那一步，表现高度相似：烧录器绿勾（镜像写进去了）， 但 BROM 就是不加载，串口停在极早期。区别是：类目 3 是「签名工具与 u-boot 不匹配」让签名校验过不了； 类目 8 是「eGON 头部或 SPL 头部本身算错」让头校验过不了。两者都属于「镜像文件问题」，不是器件问题。

4.1 类目3：boot0 镜像签名失败或校验错

量产固件通常带签名：BROM 在加载 boot0 前会用内置公钥做签名校验（常见 RSA / ECDSA，以 SDK 为准）。 签名工具、u-boot 版本、公钥必须三者配套。现场最常见的错法是： 升级了 u-boot，却沿用了旧签名工具，或换了一套不匹配的密钥，于是 BROM 校验直接失败。

4.2 类目8：eGON 头部与 SPL 头部校验失败

全志镜像有固定的头部结构：外层是 eGON.BT0 头（含 magic、长度、平台标识等）， 内层是 SPL 头（含 CRC、长度等）。BROM 先校验 eGON 头，再校验 SPL 头， 任何一处算错（长度填错、CRC 算错、平台标识不对）都会被判为非法镜像被丢弃。

4.3 立即动作与根治动作