烧录成功但不开机 · PPI NAND（并行 NAND）量产排查手册

编制日期 2026-09-21 ｜ 版本号 Rev 1.0

XTX 芯天下 · FAE 现场技术文档 ｜ 面向 8/16bit 并行异步 NAND（ONFI / Toggle）｜ 2026-09 版

一句话结论：并行 NAND 的烧录 Verify PASS 只证明 「写进去的字节与源镜像一致」，不证明「主控的 NAND 控制器读得懂这些字节」。 PPI NAND 与 SPI NAND 的关键差别在于：SPI 侧只需对上协议与 ECC，而 PPI 侧还要额外把 并行总线的 AC 时序、控制器寄存器配置、初始化顺序、ECC 引擎归属四件事全部与平台驱动对齐—— 这四件里任意一件错位，校验都会 100% 通过，系统 0% 起不来。

这份文档解决什么

解决的是并行 NAND（PPI NAND / Raw NAND / 8bit-16bit 异步 NAND）在烧录器上校验 100% 通过、 贴板后却不启动这一类问题的定位与根治方法，适用于联咏、海思、瑞芯微等中低端 AP / SoC 仍在使用并行 NAND 作为启动或存储介质的量产场景。全文按「现象 → 机制 → 类目 → 立即动作 → 根治动作」组织， 第 9 章是可直接翻查的速查表，第 11 章是可带进车间的核查清单。

怎么用这份文档

1. 先按串口输出定画像：把「不开机」归到第 1 章的六种画像之一，确定是哪一段起不来，不要一上来就换芯片。
2. 拿第 2 章的对照表认清对象：先确认自己面对的是并行 NAND，别把 SPI NAND 的经验直接套过来。
3. 抓一份「已知好板」基线：把能正常启动那块板的启动日志、控制器寄存器值、时序参数、ECC 配置各存一份。
4. 一次只改一个变量：ECC 开关、时序模式、坏块策略、偏移配置每次只动一处，改完全片重烧再上电。
5. 用装板实跑闭环：任何配置变更，最终判定以「装板跑通完整启动 + 关键功能 + 一次断电重启」为准。

1. 问题本质：PPI NAND 的特殊性

并行 NAND 烧录校验 100% 通过、贴板却不开机，绝大多数不是芯片坏了， 而是「主控的 NAND 控制器被配置成的样子」与「这颗器件的实际参数」不一致。 本章先把现象还原成机制，再把 PPI NAND 与 SPI NAND 的本质差别讲清楚——后面五章的所有排查动作都建立在这个差别上。

1.1 六种数据画像

现场接到「烧好了但不开机」，第一件事是接串口、上电、把输出贴出来，然后按下面六类归档。 六类对应的是同一机制在不同启动阶段的暴露，不是六种独立故障； 归档的价值在于它直接决定了从第 3 章到第 8 章该先翻哪一章。

1.2 校验通过，到底证明了什么

这是全文最关键的一张表。烧录器的校验（Verify）本质是把写进去的内容读回来与源镜像逐字节比对， 它检验的是「数据搬运」这一件事；而系统能否跑起来，取决于主控侧的「数据解释」规则。 并行 NAND 比串行 NAND 多出来的时序层与寄存器层，恰恰是校验完全不参与的两层。

1.3 PPI NAND 到底特殊在哪

把 PPI NAND 理解成「加大版本的 SPI NAND」是本文档要纠正的第一直觉。两者在三个层面根本不同：

• 物理层不同：PPI 用 8 或 16 根数据线加 7 根以上控制线，命令 / 地址 / 数据三态复用同一组引脚， 靠 CLE / ALE 两根专用线区分当前是哪种周期；没有时钟线，数据的锁存边沿由 RE# / WE# 自己携带。
• 时序层不同：SPI 的时序由 SCLK 频率与 SPI 模式决定，主控给个时钟就行； PPI 的建立 / 保持 / 脉宽 / 周期全部依赖主控寄存器里的等待周期数，与器件 AC 特性逐项对表。
• ECC 层不同：并行 NAND 平台上 ECC 几乎总是由 SoC 内置的硬件 ECC 引擎（BCH / RS）承担， 而不是器件片上完成；于是「烧录器要不要算 ECC」这件事本身就成了一个可错的变量。

1.4 一句话机制：三方规则 + 四层配置

SPI NAND 场景只需要「烧录器侧 / 镜像侧 / 驱动侧」三方规则对齐； 并行 NAND 还要在这三方之外，额外把主控侧的四层配置全部对齐：

2. PPI NAND vs SPI NAND 关键差异

这一章是全文的分水岭。把并行 NAND 当成「加大版本的 SPI NAND」是绝大多数误判的源头—— 两者在物理层、时序层、ECC 层三件事上根本不同，导致可用的排查手段、要查的参数、要对齐的配置完全不是一套。 认清差别后，第 3 章到第 8 章的排查才有意义。

2.1 接口层面的根本差异

先看两张图各自的信号集合。左侧并行接口用专用控制线告诉器件「我现在发的是命令还是地址」； 右侧串行接口则把这些类型编进协议字节，硬件上只需要一根时钟。

差别带来的直接后果：并行接口把时序责任从协议推给了硬件配置。 串行接口只要 SCLK 不发疯，数据就一定锁得对；并行接口即使命令全对，只要建立时间差几纳秒， 读出来的就是一个字节里错一位——而这一位足以让 ECC 从「可纠」变成「不可纠」。

2.2 关键差异对照表

下面这张表是本文档被翻查频率最高的一页。现场拿到一颗并行 NAND 时， 先把「我这颗属于左列还是右列」确认清楚，再去查具体参数。

2.3 排查决策树：按串口输出定位类目

接上串口、上电、把输出贴出来，然后顺着下面这棵树走。 树的价值在于把「不开机」这个模糊描述，压缩成六类里的一类， 从而决定先翻哪一章。

3. 第 1 类：主控平台 ONFI / Toggle 协议握手失败

上电后主控与器件之间先要有一段「互相认识」的对话：复位、读签名、读参数页、回填几何参数、切换时序模式。 这段对话走不通，器件本身再好也没用。本章把这段对话拆成八步，给出每一步失败时的症状与处置。

3.1 握手流程：八步里任何一步没走通

BootROM 与第一级加载程序（SPL / TPL）通常自带一段精简的 NAND 识别代码， 它必须在不依赖任何外部配置的前提下把器件认出来，因此流程高度固定。下图是这条链路的完整形态。

3.2 症状 → 根因 → 动作

握手失败的表现差异很大，但判定动作是同一套：把原始 ID、参数页前若干字节、 控制器回填后的页 / 块 / spare 值全部打印出来，与 datasheet 逐字段核对。

3.3 ONFI 参数页关键字段

参数页是整个驱动的地基。下面这些偏移是 ONFI 参数页里的常见定义， 具体偏移与长度以所用规范的正式文档与器件 datasheet 为准； Toggle 器件与 JESD230 参数页结构不同，不能直接套用。

3.4 Toggle 器件与 ONFI 器件的差异

并行 NAND 长期存在两套协议体系，选型与替换时务必先确认目标平台支持哪一套：

• ONFI：由 Hynix、Intel、Micron、Phison、Sony、ST 等发起，2006 年发布 1.0， 是目前事实上的主流标准。异步接口定义 6 档时序模式（mode 0~5）， 同步接口为 NV-DDR / NV-DDR2 / NV-DDR3。
• Toggle DDR：由 Samsung 与 Toshiba 推出，2010 年发布 Toggle DDR 1.0， 后续演进到 Toggle DDR 2.0。采用 DQS 选通的源同步方式，与 ONFI 的同步模式不通用。
• JESD230：JEDEC 与 ONFI 工作组联合制定的互操作标准， 用于收敛上述两套体系（公开资料给出的对应关系：JESD230 对应 ONFI 3.1 与 Toggle DDR 2.0， JESD230C 对应 ONFI 4.0）。具体版本对应关系以 JEDEC 与 ONFI 官方发布为准。

4. 第 2 类：ECC 引擎不匹配

这是并行 NAND 与 SPI NAND 差别最大、也是最高发的一类。 并行 NAND 平台上，ECC 几乎总是由 SoC 内置的硬件 ECC 引擎承担，器件片上一般不生成校验字节； 而烧录器是一个「第三方写入者」，它是否也生成 ECC，就成了决定成败的变量。

4.1 三方 ECC 生成方与 OOB 布局

写入侧（烧录器）与读取侧（SoC 驱动）各自在 OOB 里写什么、按什么布局解， 这两件事必须完全一致。下图把两侧的布局摊开对照。

4.2 组合矩阵：谁生成、谁校验

把「写入侧是否生成 ECC」与「读取侧如何校验」两两组合，只有一条路径是对的。 现场先按这张表对号入座。

4.3 配置核对项：逐项抄下来对

下面这张表建议直接打印带进车间。每行都要把两侧的实际取值抄下来对比， 只要有一项不一致，校验就会通过而系统起不来。

4.4 为什么并行 NAND 上这类问题特别多

三个结构性原因：

• 器件片上一般不生成 ECC：并行 NAND 把 ECC 责任完全交给主机， 于是「谁负责 ECC」从器件规范问题变成了平台配置问题——配置问题就会配错。
• 硬件 ECC 引擎的参数藏在寄存器里：强度、每步保护字节数、OOB 布局 都是驱动硬编码或设备树配置的，读回校验看不到它们。
• 烧录器是「外来者」：它不在平台驱动的控制链里， 不知道目标 SoC 会用哪套布局，只能靠工程师手工把配置对齐。