只读分享解决方案文档调试&解决方案📅 2026-10-14🔖 Rev 1.0⏳ 还有3日到期
🔧解决方案&应用市场分析 -> 调试&解决方案 -> 存储_量产问题排查 -> 烧录成功但不开机_PPI_NAND_量产排查

烧录成功但不开机_PPI_NAND_量产排查

扫码打开本页
微信扫码

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

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

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

技术事实核查纪律(执行前必读)

PPI NAND 的 AC 时序、ECC 算法强度、控制器寄存器配置以具体平台手册(海思 Hi35xx、瑞芯微 RK33xx、联咏 NT9x 等)和器件 datasheet 为准;本文仅展示排查机制,不代替 datasheet。

  • 并行 NAND 存在两套互不完全兼容的协议体系:ONFI(含 NV-DDR 系列)与 Toggle DDR,后由 JEDEC JESD230 做互操作收敛。器件的识别路径、参数页结构、时序模式编号都要先确认属于哪一套。
  • 本文出现的时序参数名(tR / tREA / tRP / tREH / tRC / tRLOH / tCOH / tRHOH / tWHR / tRR)与量级均为说明机制的示例,具体数值必须查该料号 datasheet 的 AC 特性表。
  • 控制器寄存器名、位域、初始化顺序、ECC 强度档位以平台用户手册与 SDK 驱动源码为准,不同平台(甚至同平台不同芯片)差异极大,本文只给「要查哪一类寄存器」。
  • 命令码(FFh / 90h / ECh / EEh / EFh / 70h 等)是并行 NAND 的常见写法,但并非所有器件与所有平台都一致,动手前逐条核对 datasheet。
6 类
不开机根因归类
握手 · ECC · 时序 · 寄存器 · 布局 · 坏块
2 套
并行 NAND 接口协议体系
ONFI 与 Toggle DDR,握手路径与时序参数不通用
6 档
ONFI 异步时序模式 0~5
mode 0 为上电默认,高速模式须显式切换(以规范为准)
3 方
ECC 可能的生成方
器件片上 · SoC 硬件 · 烧录器软件,只允许一方生效
装板实跑
唯一有效的验收动作
读回校验与离线比对都不能替代

结论:并行 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 类
主控平台 ONFI / Toggle 协议握手失败
BootROM 与器件之间的识别对话没走通:签名读不到、参数页 CRC 不过、几何参数解析错。器件本身完全正常,是「对话」没建立。
高发动作:换料号不重跑识别日志
第 2 类
ECC 引擎不匹配
并行 NAND 的 ECC 生成方可能有三家:器件片上、SoC 硬件 ECC 引擎、烧录器软件 ECC。只要写入侧与读取侧不是同一家,校验字节就会互相破坏。
高发动作:烧录器默认开 ECC
第 3 类
异步时序配置错位
并行异步接口没有时钟线,tR / tREA / tRP / tREH / tRC / tRLOH 全靠主控寄存器里的等待周期数与器件 AC 特性对上。对不上就是位错,且随温度电压漂移。
高发动作:沿用别的料号的时序参数
第 4 类
平台寄存器与控制器初始化顺序
时钟 / 复位 / 引脚复用 / 软复位 / 位宽 / 保守时序 / 识别 / ECC 配置 / 切模式,顺序错了或某一步漏了,症状全都伪装成「芯片不良」。这是 PPI NAND 的特有陷阱。
高发动作:只改驱动不改初始化
第 5 类
文件系统 / UBI 与烧录镜像的布局不一致
镜像里的偏移是布局偏移,烧录器跳过坏块后物理块号整体后移;UBI 的 PEB / LEB 映射又是运行时建立的。三套偏移对不齐就挂载失败。
高发动作:按固定块号找 SPL
第 6 类
坏块策略与工具链
坏块标记位置、烧录器的跳过策略、驱动的 BBT 来源三者必须一致。危害与 SPI NAND 相同,但并行器件的判读规则和烧录器工具链完全另一套。
高发动作:整片擦除后再烧

怎么用这份文档

  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 章该先翻哪一章。

完全黑屏 · 串口一行不出上电电流正常,串口无任何输出控制器没拿到有效器件响应或时钟 / 复位 / 引脚复用根本没起高概率:类目 4 → 类目 1串口报 No NAND / init failedBootROM 或驱动识别不到器件读 ID 返回全 FF 或全 00或 ID 对了但参数页解析失败高概率:类目 1 → 类目 4容量 / 页大小识别成错值打出 0 MiB、容量翻倍或减半参数页解析或内建 ID 表查错页 / 块 / spare 三者其一错位高概率:类目 1卡 logo · kernel 起一半挂SPL / U-Boot 正常,读 kernel 时死或长时间卡在等待根设备数据搬对了,但读的一方解释不了高概率:类目 2 → 类目 5大量 ECC error / uncorrectable串口刷屏式报不可纠错误读出来的页与预期差几位空白页也可能被判成错高概率:类目 2 → 类目 3UBI / mount 失败 · 卷头找不到进到挂载阶段才报错报坏 PEB、卷头错位、空卷分区偏移与镜像对不上高概率:类目 5 → 类目 6六种画像不是六种故障,而是同一件事在不同启动阶段的暴露:写进去的字节是对的,但读它的那一方按另一套规则解释。PPI NAND 的排查起点不是「芯片有没有坏」,而是「主控的控制器被配成了什么样、器件的参数页是怎么被解析的」。
图 1 · PPI NAND 烧录通过但贴板不开机的六种数据画像

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

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

校验通过能证明校验通过不能证明由谁决定
烧录器缓冲区里的数据与源镜像逐字节一致目标 SoC 能读懂这些字节平台驱动 / BootROM
每个被写的页都编程成功(FAIL 位为 0)控制器被配成了正确的位宽与时序控制器寄存器配置
在烧录器当前的时序下读写正常在目标板的时序下也正常(两者不是一回事)平台 AC 时序配置
OOB 里写进去的字节与烧录配置一致OOB 布局与驱动的 ECC 布局一致驱动 ECC 配置
这一颗在烧录器上能跑这一颗装到目标板上能跑装板实跑
这一颗能跑这一批 / 这个料号 / 这个批次都能跑首件确认 + 装板抽检

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」这件事本身就成了一个可错的变量。
贯穿全文的一条纪律

「烧录通过 ≠ 贴板能跑」。只要现象是「校验 100% 通过但系统不起来」,就不要把时间花在怀疑芯片质量上——先查主控侧的四层配置是否对齐。并行 NAND 的现场统计里,器件本体不良的概率远低于配置错位的概率。

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

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

层要对齐的内容配错后的典型症状配错的高发原因
物理层总线位宽(8bit / 16bit)、引脚复用与驱动强度读 ID 全 FF 或全 00,像没焊芯片引脚还在 GPIO 态,或 16bit 器件被当成 8bit 用
协议层ONFI / Toggle 识别路径、参数页解析、时序模式识别不到器件,或容量 / 页大小识别成错值参数页字段解读错,或器件不在内建 ID 表里
时序层tR / tREA / tRP / tREH / tRC / tRLOH 及全套 AC 参数偶发位错、ECC 报错、随温度电压漂移沿用别的料号的时序参数或直接取默认值
ECC 层生成方、校验强度、每步保护字节数、OOB 布局大量不可纠错误,或空白页被判错烧录器默认开 ECC,与 SoC 硬件 ECC 打架
最容易踩的一条直觉错误

不要用 SPI NAND 的排查套路去套 PPI NAND。SPI NAND 的问题大多收敛在「坏块 + ECC + 偏移」三件事上;并行 NAND 在这三件事之外,还有「控制器有没有被正确初始化」和「时序参数有没有对上器件」这两个结构性新增维度。换句话说:SPI NAND 出问题,多半是数据层的事;PPI NAND 出问题,有相当比例是控制器层的事——而控制器层的问题,读回校验永远查不出来。

2. PPI NAND vs SPI NAND 关键差异

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

2.1 接口层面的根本差异

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

PPI NAND · 8bit 并行异步接口IO[7:0] · 8 位双向数据总线命令 / 地址 / 数据三态复用,由 CLE / ALE 区分周期类型CLE命令锁存使能ALE地址锁存使能CE#片选RE#读使能WE#写使能WP#写保护R/B#就绪 / 忙VCC / GND电源与地VDDQ / NCIO 电源(依器件)信号数:8 数据 + 7 控制 ≈ 15 根起(16bit 总线更多)无时钟线:锁存边沿由 RE# / WE# 自己携带,时序需双方 AC 对表SPI NAND · 串行同步接口CS#片选SCLK串行时钟IO0 / MOSI命令 / 地址 / 数据串行发出IO1 / MISO器件回读数据IO2 / WP#写保护IO3 / HOLD#保持VCC电源GND地信号数:6~8 根,8 脚封装即可跑完整个协议有时钟线:时序只由 SCLK 频率与 SPI 模式决定左:并行总线把「周期类型」交给专用控制线,代价是主控必须自己把每一根线的建立 / 保持 / 脉宽都配准。右:串行总线把「周期类型」编进协议字节,主控只管发时钟 —— 这就是 PPI NAND 时序事故远多于 SPI NAND 的结构性原因。
图 2 · PPI NAND 与 SPI NAND 的接口信号对比

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

2.2 关键差异对照表

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

对比维度PPI NAND(并行 NAND)SPI NAND(串行 NAND)
接口形态8 / 16bit 并行总线,配 CLE / ALE / RE# / WE# / CE# / R/B# / WP#4~6 线串行:CS# / SCLK / IO0~IO3
时钟异步模式没有时钟线;同步模式(NV-DDR / Toggle)才引入 CLK 与 DQS始终由 SCLK 提供,读写都跟着它走
引脚数常见 15 根起(16bit 总线更多),封装多为 48 / 63 ball 以上8 脚即可(WSON8 / SOP8 / BGA24 等)
命令 / 地址 / 数据三态复用同一组 IO 引脚,靠 CLE / ALE 区分当前周期类型全部编进串行协议字节,无需专用控制线
时序由谁决定主控寄存器里的等待周期数 × 器件 AC 特性,逐项对表SCLK 频率 + SPI 模式(CPOL / CPHA)+ 线宽
时序模式ONFI 异步 mode 0~5(mode 0 为上电默认);另有 NV-DDR / NV-DDR2 / NV-DDR3 与 Toggle DDR 1.0 / 2.0没有「时序模式」概念,只有频率与 1 / 2 / 4 线宽度
ECC 生成方几乎总由 SoC 内置硬件 ECC 引擎承担,器件片上一般不生成多数器件片上 ECC 上电默认开,器件自算校验字节写入 spare
spare / OOB每页带 spare 区,ECC 位置与长度由平台驱动硬编码每页带 spare 区,ECC 位置与长度由器件与驱动共同约定
坏块标记在 spare 区首字节(部分器件写前两页),判据与地址各厂不同同样在 spare 区,但地址与判据另有一套约定
器件识别路径ONFI Read ID(90h / 地址 20h)→ 参数页(ECh);失败则回落标准 Read ID(90h / 地址 00h)+ 内建表读 JEDEC ID + 参数页 / 特征字,路径与并行完全不同
烧录器支持需要专门的并口 NAND 算法与时序配置,工具链独立通用 SPI 烧录算法即可,多数烧录器内置
平台驱动耦合度极高:寄存器、时序、ECC 布局全部绑死在平台上中:主要绑 OOB 布局与坏块策略
典型应用平台联咏、海思 Hi35xx、瑞芯微 RK33xx 等中低端 AP / SoC(eMMC 未普及时代)新兴与低成本平台、替代大容量 NOR 的场景
三条不能混淆的纪律
  • 不要把 PPI NAND 当作「加大版本的 SPI NAND」。接口、ECC、时序机制全部不同,排查清单也完全不同。
  • 不要沿用别的料号的时序参数。并行 NAND 的 AC 特性是逐料号标定的,换料号必须重取参数,具体数值以该料号 datasheet 的 AC 特性表为准。
  • 不要只看烧录器能不能烧。烧录器能烧只说明它的算法认这颗芯片,不说明目标平台的控制器认这颗芯片——这两件事在并行 NAND 上经常是分离的。

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

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

烧录校验 100% 通过贴板后系统不起来判据 1 · 串口一行都不出上电电流正常,BootROM 未吐出任何字符判据 2 · 串口报 NAND 识别异常No NAND device / 容量识别成 0 或翻倍判据 3 · 进到挂载阶段才报错ECC error / UBI 报错 / mount 失败类目 4寄存器与初始化顺序类目 1协议握手类目 2ECC 引擎类目 3异步时序类目 5镜像与 UBI 布局类目 6坏块策略先按串口输出定画像,再进对应章节;画像定错了,后面会一直在错误的方向上找。判据 1 与判据 2 都可能落到类目 1:区别在于读 ID 有没有回东西 —— 全 FF 多半是物理层 / 寄存器,ID 对但参数错才是协议层。
图 3 · 按串口输出定位类目的排查决策树
决策树的使用边界

这棵树给的是首选方向,不是排他判定。并行 NAND 上多因并发很常见(例如时序配错导致参数页读错,看起来像协议握手失败),按首选方向查不通时,回到第 1 章的六种画像重新归档,并把控制器寄存器的实际值打出来与已知好板逐项比对。

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

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

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

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

① 发 FFh 复位,轮询 R/B# 至就绪超时量级常见为 100~250 ms,具体以平台手册为准② 控制器置 8bit 异步 + 最保守时序(ONFI mode 0)识别阶段必须最慢;16bit 与高速模式都要等识别成功后再切③ 发 90h,地址 20h —— ONFI Read IDONFI 器件应回 4 字节签名 O / N / F / I(4Fh 4Eh 46h 49h)④ 判定:回读的签名是不是 ONFI?不是则走右侧回落路径;是则继续读参数页⑤ 发 ECh 读参数页(ONFI 规范为 256 字节)CRC16 校验前 254 字节;规范允许 3 份副本,取首份有效⑥ 按参数页回填控制器的几何参数页大小 offset 80(4B)/spare 大小 offset 84(2B)每块页数 offset 92(4B)/地址周期数 offset 101(1B)特性字 offset 6(2B,bit0 表示是否支持 16bit 总线)⑦ 发 EFh(SET FEATURES,特性地址 01h)切时序模式切完必须回读 GET FEATURES(EEh)确认,再进入数据阶段⑧ 扫坏块、建 BBT,交棒给驱动 / UBI至此识别阶段才算完成,此后所有读写都依赖上面填进去的参数签名不匹配时的回落路径1. 再次发 FFh 复位并等 R/B# 就绪2. 90h / 地址 00h 读标准 ID(厂商 + 器件)3. 用器件 ID 查 BootROM 内建器件表4. 大容量器件再解析 ID 第 4 字节定几何5. 表里也没有 → 启动终止或走私有后备内建表是平台固化的,换料号可能查不到识别阶段的主控一定是最慢最保守的配置:8bit 位宽 + mode 0 时序;任何「先配快时序再识别」的做法都会在第一步翻车。参数页里的页大小 / spare 大小 / 每块页数 / 地址周期数是整个驱动的地基,填错一个,后面所有读写与 ECC 布局全错。
图 4 · 并行 NAND 的 ONFI 识别与握手流程

3.2 症状 → 根因 → 动作

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

症状最可能的根因立即动作根治动作
串口一行都不出控制器未上电 / 未解复位 / 引脚未复用读时钟与复位寄存器,量 CE# 有无波形补齐初始化顺序(见第 6 章)
报 No NAND device / init failed读 ID 返回全 FF 或全 00,器件根本没响应示波器看 CE# / RE# / WE# 有无跳变修引脚复用、焊接或供电
ID 读得出但提示 unsupported器件不在平台内建 ID 表里,或参数页 CRC 不过打印原始 ID 与参数页前 32 字节补内建表项或修正参数页解析
容量识别成 0 或成倍偏差参数页字段偏移读错,或块 / 页 / spare 三者其一错位把回填值打印出来与 datasheet 对修正参数解析与回填代码
能识别,但读写内容错时序模式未生效,或切到了器件不支持的模式强制回退 mode 0 再验证按 datasheet 重配时序(见第 5 章)
Toggle 器件完全识别不到平台只实现了 ONFI 识别路径确认平台手册是否声明支持 Toggle换用平台支持的料号,或联系平台方
换批次后突然识别不到新工艺 / 新 die 的 ID 或参数页有变化对比新旧批次的原始 ID 与参数页把新批次纳入首件验证清单

3.3 ONFI 参数页关键字段

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

参数页偏移字段长度说明
0~3参数页签名4 BONFI 应为 O / N / F / I(4Fh 4Eh 46h 49h)
4~5修订号2 B用于判定器件遵循的规范版本
6~7特性字(features)2 Bbit0 表示是否支持 16bit 数据总线
80~83每页数据字节数4 B即页大小,回填到控制器
84~85每页 spare 字节数2 B即 OOB 大小,决定 ECC 布局可用空间
92~95每块页数4 B与页大小相乘得到块大小
101地址周期数1 B行地址与列地址合计的周期数
254~255CRC2 B对前 254 字节做 CRC16,用于校验参数页有效性
参数页不是万能的

参数页的有效性依赖 CRC,而 CRC 又依赖读参数页时的时序是对的。如果控制器此刻的时序已经配错,读出来的参数页本身就是错的,CRC 大概率不过——这类故障会被误报成「器件不支持 ONFI」。

判别方法:把时序强制降到 mode 0 后重读参数页,如果这时 CRC 过了,说明问题在时序而不在器件。

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 官方发布为准。
JEDEC 与 ONFI 的公开版本脉络

公开资料给出的时间线大致为:ONFI 1.0(2006-12,异步低速)→ ONFI 2.x 引入源同步接口 → ONFI 3.x 命名 NV-DDR / NV-DDR2 → ONFI 4.0(可支持更高速率);Toggle DDR 1.0(2010-06)→ Toggle DDR 2.0;JEDEC 的 JESD230 系列(2012-10 起)尝试把两套体系收敛为互操作标准。

具体版本号、发布时间与速率档位以官方规范文本为准,现场只需记住一条结论:先确认平台支持哪一套,再选料号。

不要在识别阶段就配高速时序

识别阶段的主控必须是8bit 位宽 + 最保守时序(ONFI mode 0)。有些工程师为了让启动更快,在初始化时直接把控制器配成目标时序模式,结果读 ID 这一步就拿到错数据,后续全部崩塌。

正确顺序:先保守识别,识别成功后再用 SET FEATURES 切模式,并用 GET FEATURES 回读确认。切模式前后都要等 R/B# 就绪。

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

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

4.1 三方 ECC 生成方与 OOB 布局

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

写入侧 · 烧录器(以实际工程配置为准)数据区(示例 2048B)OOB 64B坏块标记 · OOB 字节 0~1 · 由烧录器按器件规范写ECC 校验字节 · OOB 字节 2~33 · 若烧录器开 ECC 则由它生成空闲 / 元数据 · OOB 字节 34~63 · 视文件系统与驱动约定以上字节范围与长度均为示例,以器件 datasheet 与驱动源码为准读取侧 · SoC NANDC 硬件 ECC(以驱动源码为准)数据区(驱动按页大小读)OOB 64B坏块标记 · 驱动按 OOB 布局硬编码的位置读ECC 校验字节 · 由 SoC 硬件 ECC 引擎生成并校验空闲 / 元数据 · UBI / YAFFS2 / JFFS2 各自的 OOB 约定位置与长度由驱动的 OOB 布局结构体定义,与烧录器默认值不是一套东西三种组合的结果组合 A|烧录器生成 ECC + SoC 硬件 ECC 也生成结果:同一片 OOB 被写两遍校验字节,读时校验必然失败 —— 并行 NAND 最高发的坑组合 B|烧录器不生成 ECC + 由 SoC 硬件 ECC 生成结果:正确路径,前提是 OOB 布局(位置与长度)与驱动完全一致组合 C|烧录器生成 ECC + SoC 走 raw / 软件 ECC结果:读到的是别人的校验字节且不纠错,遇到一次 bitflip 就停在这里判别动作:把烧录工程的 ECC 设置(开 / 关、强度、位置)与驱动里的 ECC 配置逐项抄在同一张纸上对照,只要有一项不一致就必挂。ECC 强度(例如每 1KB 纠若干 bit)与校验字节长度由平台手册给出,本文不给死值 —— 以平台手册与器件 datasheet 为准。
图 5 · ECC 生成方与 OOB 布局的三种冲突组合

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

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

写入侧(烧录器)读取侧(SoC 驱动)结果处置
生成 ECC硬件 ECC 生成并校验冲突,同一片 OOB 被写两遍,校验必然失败关掉烧录器侧的 ECC
生成 ECCraw / 不校验不纠错,能读但一次 bitflip 就挂关掉烧录器 ECC,或改驱动走硬件 ECC
不生成 ECC硬件 ECC 生成并校验正确路径,前提是 OOB 布局一致保持,并核对 OOB 布局逐项一致
不生成 ECCraw / 不校验能跑但没有纠错保护,长期不可靠按平台要求开启硬件 ECC

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

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

核对项烧录器侧取值来源驱动侧取值来源不一致的后果
是否生成 ECC烧录工程的 ECC 开关驱动的 ECC 模式配置双重 ECC,或完全没有保护
算法与纠错强度烧录工程配置平台手册 + 驱动配置校验字节长度对不上,布局整体错位
每步保护字节数通常不涉及驱动的 ecc size / strength步进数与 OOB 用量不匹配
ECC 字节在 OOB 的位置烧录工程配置驱动的 OOB 布局结构体覆盖坏块标记或文件系统元数据
保护范围是否包含 spare烧录工程配置驱动实现元数据被改写后校验失败
空白页如何处置烧录工程的空白页策略驱动的空白页判定空白页被判成坏块或数据

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

三个结构性原因:

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

这是本文档列出的第一号高发坑。典型现场是:换了一台烧录器(或换了个烧录工程),新工程的 ECC 选项默认是「开」,而目标平台的驱动走的是 SoC 硬件 ECC。结果每一页的 OOB 都被写了两份校验字节,第二份把第一份的位置覆盖了一半。

现象特征:读回校验 100% 通过(写的确实和源镜像一致),贴板后串口刷屏报 ECC 不可纠错误,或者干脆认不出文件系统。

立即动作:把烧录工程的 ECC 关掉,全片重烧,装板验证。根治动作:把「本平台烧录时必须关闭烧录器 ECC」写进作业指导书,并在首件清单里加一条「核对 ECC 开关」。

ECC 强度不是越大越好

提高 ECC 强度会占用更多 OOB 字节。如果 OOB 空间不够放下「坏块标记 + ECC 校验字节 + 文件系统元数据」,就会互相覆盖。可用 OOB 大小由器件决定,ECC 强度与所需字节数由平台手册给出,两者必须由平台方确认能匹配,不能为了提高纠错能力就随便调高强度档位。具体数值以平台手册与器件 datasheet 为准。

相关报告 · 交叉引用 2 器件全部展开收起 ▾
点开类目即可展开:具体文档 / 章节(点章直接跳转到该章)
PPI NAND(并行NAND)
电路设计指南
软件设计规范
Linux 驱动开发
SPI NAND
电路设计指南
软件设计规范
Linux 驱动开发
样机问题排查
量产问题排查4
全志平台 SPI NAND NOR
章节(点章跳转,共 11 章)
海思平台 SPI NAND 量产常见失败
章节(点章跳转,共 11 章)
烧录成功但不开机 SPI NAND
章节(点章跳转,共 12 章)
瑞芯微平台 SPI NAND eMMC
章节(点章跳转,共 11 章)
系统设计指南3