eMMC 内部架构与分区模型

从 Host 控制器到 NAND 阵列的完整拆解 —— 分区模型、命令队列、缓存与可靠性机制的一份系统性参考 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0

结论： eMMC 不是「一块会走总线的大容量 Flash」，而是一颗自带存储子系统的器件—— 它把「LBA 到物理位置的映射、ECC 纠正、坏块替换、磨损均衡、写缓存与合并」全部封在硅片里， 所以主控侧看到的只是一次普通的块读写，而实际的写入次数、物理位置、耗时与掉电行为， 全都被器件内部的策略改写了一遍。所有架构层的现场问题，几乎都能追到这七件事中的一件。 本文所有数值均为量级性描述，具体参数一律以正式 datasheet / JESD84 为准。

读者路径

• 分区切错了、镜像放错区：直接看第 3 章（六类硬件区域与能力对照）与附录 B（区域能力速查）。
• 写入丢了、乱序了：看第 6 章（缓存与非对齐写入）与第 4 章（RPMB 的原子性语义），这两章覆盖了绝大多数「数据丢了」的真实成因。
• 性能不如预期：看第 5 章（CMD 队列的收益条件）与 5.8 节（无 CMDQ 时的替代路径），先分清是「没并发」还是「写放大」。
• 启动失败、启动源搞不清：看第 9 章（Boot 分区与内部 ROM）与 9.6 节（分层定位）。
• 要评估寿命与健康度：看第 7 章（ECC、坏块、磨损均衡与寿命预算分摊）。
• 做选型与能力评估：看第 10 章（版本演进与能力矩阵）+ 11.2 节（能力协商字段清单）+ 附录 C（排查手册）。

1. 为什么需要理解 eMMC 的内部架构

这一章不介绍具体机制，只先把一件事说清楚：eMMC 的「外部接口」与「内部实现」之间存在巨大的抽象落差，而这个落差正是绝大多数架构层困惑的来源。

1.1 外行看到的一颗「SD 卡」，里面到底有什么

在软件视角里，eMMC 就是块设备上的一个设备节点：打开它，读一个扇区，写一个扇区，出错就返回错误码。这个视角是有意简化的，它成立的前提是「你不需要知道数据实际落在哪」。一旦出了问题——写入丢失、性能不达标、寿命掉得比预期快——这个前提就塌了，你必须能看到器件里面去。

器件内部实际发生的事情，与「读一个扇区」这六个字之间隔着至少六层转换：

• 接口层把命令和数据在引脚上串行化，Host 与器件之间跑的是一套有严格时序的协议；
• 命令解析器把命令字翻译成内部事务，并判断当前状态下这条命令是否合法；
• 队列调度器决定这条事务排在缓存前面还是 NAND 前面，排在读队列还是写队列；
• 缓存层可能直接命中并返回，也可能先收下再择机合并后写入；
• FTL 映射层把逻辑块号翻译成物理页号，这是磨损均衡与坏块替换的落地点；
• NAND 阵列真正完成页的编程或读取，期间可能触发内部 ECC 纠错、坏块重映射、页迁移。

这六层里任何一层都可以「悄悄改变」外部观察到的行为：缓存让写入延迟变得不确定，FTL 让同一个 LBA 前后落到不同物理块，ECC 让数据在被读出之前就已经被改写过一次。

1.2 三层视角：焊盘与引脚 / 数字接口与协议 / 内部的 Flash 阵列

理解 eMMC 最有效的办法，是把它拆成三个抽象层级。这三个层级的关注点完全不同：最外层是物理的，中间层是协议的，最里层是介质的。绝大多数架构层误解，都发生在跨层推理——拿最外层的直觉去推断最里层的行为。

1.3 架构知识在哪些具体问题上值钱

下面这张表是本文的价值清单：每一行都是一个真实会被问到的问题，以及它对应的架构层与本文位置。

1.4 全局架构总览图

把上面三个层级画进一张图，就是本文的总纲。后面每一章都只是在这张图的某一块上放大。

1.5 本文的主线：数据在器件内部怎么流动

全文围绕一个问题展开：一条命令从 Host 发出，到数据被交还，中间的每一层都做了什么决定。为了把这条链条讲完整，本文按下面这个顺序推进：

• 第 2 章先把器件内部剖开，看三大功能块与控制器的八类子模块，再走一遍一次读写的完整旅程。
• 第 3、4 章讲分区模型：六类硬件区域的边界、容量与能力差异，以及 RPMB 如何用认证语义实现防回滚。
• 第 5、6 章讲性能的两大引擎：命令队列负责「让等待重叠」，缓存与非对齐写入负责「让写入变少」。
• 第 7、8 章讲可靠性与功耗：ECC、坏块、磨损均衡如何在硅片里落地，以及器件如何进入低功耗状态。
• 第 9 章到第 12 章把前面所有机制收到工程侧：启动流程怎么用 Boot 分区、版本演进带来了哪些新能力、系统侧该怎么配、以及一份可直接照做的检查清单。

2. 硬件架构：Host、控制器与 NAND 阵列

这一章把器件从外面切开。先给出三大功能块的划分，再逐个拆解内部控制器的子模块，然后跟着一条命令走完从 Host 到 NAND 再回到 Host 的完整旅程。

2.1 eMMC 器件的三大功能块

eMMC 之所以能被当成一颗「存储芯片」而不是「一颗 Flash」，根本原因在于它内部有一整套把 NAND Flash 变得像块设备的东西。这套东西可以清晰地拆成三大功能块。

2.2 内部控制器由哪些子模块构成

内部控制器不是一个黑盒，它由八类子模块拼成。理解这八块的职责边界，比记住任何一条命令流程都有用——因为工程上遇到的现象，几乎总能落到其中一块。

2.3 NAND 阵列与数据通路：从 LBA 到页、块、物理位置

NAND 阵列的组织是分层的，从大到小依次是 die（裸片）→ block（块）→ page（页）。这三个层次各自对应一个操作粒度，且操作粒度与数据粒度并不一致——这是写放大与所有非对齐写入问题的物理根源。

• page：读操作的最小单位。读一个 page 会把整页的数据一次性搬到片上缓存，Host 侧只能取其中一段。
• block：擦除的最小单位。擦除一个 block 会把其中所有 page 全部恢复为初始态。
• die：独立的数据分区。同一时刻可以对不同 die 并行发起操作，这也是吞吐的主要来源。

关键的不对称在于：读以 page 为单位、写在 page 为单位、擦除以 block 为单位，而 Host 的访问单位是逻辑块。当一个逻辑块不能整除地映射到一个 page，或者需要改写的部分不足一个 page，主控就必须把动作放大到整页甚至整块。

2.4 内部架构剖面图

把第 2.1 与 2.2 节的内容叠成一张剖面图，就是器件内部的真实形态。注意右侧的职责标注——这是排查问题时最常回查的一张图。

2.5 数据一次读写的完整旅程

现在把前面的概念串成一条完整链路。下面是一次读操作和一次写操作的完整路径，每一步都标注了它属于哪一层，这样以后看到现象就能立刻定位。

2.6 器件内部的数据流总览

把一次读写拆成「谁在什么时候把活干完」，就能看清哪些阶段可以被重叠、哪些阶段必须串行。这张图也是第 5 章与第 6 章的铺垫。

2.7 厂商实现差异

标准定义的是外部可观察的行为，不定义内部怎么做。因此同容量、同版本的两颗 eMMC，在缓存大小、调度策略、ECC 强度、映射粒度上都可以差很多。这解释了为什么「换料就出问题」经常发生。

3. 分区模型：六类硬件区域

eMMC 的分区不是操作系统画的，而是器件出厂时就在硅片里切好的。这一章把六类硬件区域的边界、容量来源与能力差异讲清楚，并说明它们与 GPT 的分工关系。

3.1 为什么要有分区：掉电安全与多用途共享

如果 eMMC 只是一个大容量可写块设备，那么所有内容——启动镜像、密钥、日志、用户数据——就会混在同一片地址空间里，任何一次误写或掉电都可能同时毁掉它们。硬件分区模型的本质是用物理隔离换取语义隔离：让某些区域天生具备不同的能力，让另一些区域从物理上就不可能被普通写入碰到。

三条设计动机：掉电安全（启动镜像必须在掉电后仍完整可执行，需要一块写入策略更保守的区域）、认证性（密钥不能被任何人读到，需要一块伪造会被拒绝的区域）、多用途共享（同一颗器件要同时服务启动、认证、用户数据、备用，地址空间上必须分开）。

需要特别澄清的一点：硬件分区与操作系统的分区表是两套机制。硬件分区在器件出厂时就固定了；操作系统分区表（如 GPT）是写在某个区域里的数据结构，必须依附于硬件分区才能生效。这个分层关系是理解第 3.8 节的前提。

3.2 Boot1 / Boot2：上电即执行区

Boot1 与 Boot2 是器件内部预留的启动区，容量在出厂时固定。它们存在的理由很直接：系统上电后，主控还没有跑起来，此时唯一可用的存储就是这两块区域。主控的启动 ROM 只需要按固定规则从这里取数据，就能把第一段代码搬到 SRAM 或内部运行区执行。

Boot 分区有三个常被忽略但很重要的架构属性：

• 容量固定且很小：这是它作为「上电即用」区域的前提，也是最常见的现场错误来源（详见第 3.9 节）。
• 访问方式受限：Host 侧不是通过普通 LBA 访问它，而是按规范规定的分区号与固定偏移访问。
• 切换是双份的：Boot1 与 Boot2 成对存在，用于「一份在写、另一份保持有效」的更新模式；启动源指向哪一份由配置决定，不是 Host 临时决定。

3.3 RPMB：一写入一读取的认证区

RPMB（Replay Protected Memory Block，防重放保护存储区）是本文里最需要被正确理解的一块。它的核心不是「一块特殊存储」，而是一套带密钥认证的原子读写语义：写入必须携带正确的认证标签，读取返回的数据同样带标签，因此任何一方都能验证数据没有被仿造或重放。

三句话说清它的定位：

• 认证性：帧内携带由密钥派生的认证标签，主机与器件各自持有一份密钥，只有知道密钥的一方才能产生合法帧。
• 原子性：一次写入要么完整生效、要么完全不生效，不会出现「数据写了一半」的中间态。
• 防重放：每个成功写入都会递增一个写计数器；写入请求必须携带与器件当前值相等的写计数器，不等（无论大小）即拒绝，从而防重放。

3.4 User 区：容量主体与 GP 分区

User 区是容量主体，标称容量基本都指它。它在架构上有一个关键特点：被切成若干通用分区（GP 分区），每个 GP 分区在主机侧表现为一个独立的逻辑块设备。GP 分区本身不带任何特殊能力，它的存在只是为了在一块物理器件上划出多个互相独立的空间。

需要注意的是，GP 分区与操作系统分区表是两回事：GP 分区是硬件层的切分（由器件配置决定，主机通过分区号选择），而 GPT / MBR 是软件层的切分（写在某个区域里，操作系统读它来挂载文件系统）。同一个 GP 分区内部可以再放一整张 GPT。

3.5 硬件分区地址映射与容量关系

下面这张图与接下来的对照表是本章最重要的一张图。关于容量只有一条必须记住的规则：Boot 与 RPMB 的容量来自器件出厂配置，不从 User 区里扣；而标称容量指的是 User 区的容量。把两者混在一起算，是分区规划阶段最常见也最难在早期发现的错误。

3.6 Backup 区与保留区

Backup 区不是给用户放数据的地方，它是器件给自己的：坏块表、映射信息、磨损均衡的统计状态等内部元数据存放于此，Host 侧不能把它当普通 LBA 访问。保留区则是厂商内部预留，既不可访问也不计入标称容量。

Backup 区的存在解释了一个常见现象：eMMC 的标称容量并不等于地址空间末端。地址空间的最高若干块往往落在保留区，越界访问得到的是错误而不是数据。如果系统侧按「容量 × 块大小」直接算地址上界，尾部可能撞进保留区。

3.7 三种区域的能力对照表

把 Boot 区、RPMB、User 区（含 GP 分区）放在一起对照，五个维度上的差异一目了然。这张表建议直接抄进设计文档作为分区选型的判据。

3.8 硬件分区与 GPT 的分工

硬件分区与软件分区表是上下两层，各管一件事。搞混这一层的常见后果是「分区表写对了但系统起不来」，或者反过来。

• 硬件分区：由器件出厂配置决定，划出 Boot、RPMB、GP 分区等区域。Host 侧通过分区号选择，写入这个动作发生在烧录阶段。
• GPT：是一张写在某个区域里的分区表数据结构，描述这块区域内部怎么再分。它是一个普通文件，位于 GP 分区或 User 区的开头，操作系统读取它来建立分区映射。

关键结论：Boot 分区里不放 GPT。原因很直接——GPT 的作用是描述「一个可被操作系统读取的块设备内部怎么分」，而 Boot 分区不是操作系统块设备，它是主控 ROM 直接读取的裸镜像区；把 GPT 写进去只会让 ROM 无法解析。

3.9 分区选择的常见错误

下面五条是分区规划阶段的高频错误，每一条都会在后期以很难排查的形式暴露出来。提前对照检查一遍，比事后追查便宜得多。

4. RPMB 的认证模型与防回滚

这一章把 RPMB 拆到机制层面。核心命题只有一句：RPMB 的价值不在存储，在于它用器件内部的一次性密钥和单调递增的计数器，把「数据完整性」与「不可回滚」两件事从软件层的自觉变成了硬件层的强制。

4.1 RPMB 要解决的问题：回滚与仿冒

先说清它防的是什么。没有 RPMB 时，主机的安全状态存在普通区域里，会面临两类攻击：

• 回滚（replay）：攻击者或误操作把状态数据恢复成一个更早的合法版本。例如把「已授权次数」改回未使用的状态，或把固件版本号改回旧版本，从而绕过「必须升级才能使用」的限制。
• 仿冒（forgery）：直接构造一份看起来合法的状态数据并写入。在没有认证的区域里，这在技术上就是把几个字节写进去而已。

RPMB 用两个机制分别对付这两类问题：帧级认证标签对付仿冒，单调递增的写计数器对付回滚。缺了任何一个，模型就不完整——只有认证没有计数，就是防住了仿冒但防不住回滚；只有计数没有认证，攻击者可以自己构造一个计数更大的合法帧。

4.2 密钥的派生与存储位置

RPMB 的认证标签能防仿冒，前提是只有可信一方知道密钥。密钥的派生与存放本身就是一个架构问题，而不是一个密码学细节。

• 存储位置：密钥存放在器件内部的一次性可编程区域。这块区域在出厂后可以被写入一次，之后不可更改——这是模型的信任根。如果密钥存在外部 Flash 里，攻击者读到 Flash 就能生成合法帧，整个认证模型立刻失去意义。
• 派生方向：一般由主控在生产阶段生成一次性密钥，写入器件的一次性区；运行期器件与主控各自持有同一份密钥，任何一侧泄露都会让认证失效。
• 一次性可编程的含义：不可更改意味着无法轮换密钥，也无法擦除重来。因此密钥的烧写本身必须被当作一次性不可逆操作来管理，写错就没有补救路径。

工程上最容易被忽略的一点：密钥的烧写要在产线流程里明确留痕。一旦批量烧写后没有记录哪颗器件用了哪把密钥，售后换料时就无法复现，RCP 认证相关的功能会集体失效。

4.3 认证写入与认证读取的流程差异

认证写与认证读都带认证标签，但字段构成与副作用不同。下表列出关键差异，这些差异直接决定了驱动层的实现必须区别对待读写两条路径。

4.4 计数与回滚保护：单调递增语义

写计数器是 RPMB 模型的支柱。它的语义非常朴素但非常严格：任何一次成功的认证写入，都必须让计数单调增加；写入请求必须携带与器件当前值相等的写计数器，不等（无论大小）即拒绝，从而防重放。

这条规则带来三个直接后果：

• 状态不可回退：攻击者无法把「已用 99 次」改回「已用 0 次」，因为他构造不出计数更大且通过认证的合法帧。
• 顺序即保护：计数值本身隐含了顺序信息，主机不需要额外的序号字段就能判断状态是否被倒退。
• 掉电后不会自愈：如果掉电发生在写入过程中，要么整帧生效且计数前进，要么完全不生效且计数不变——不会出现「数据写了一半、计数却已前进」的错位。

反过来也要理解它的成本：计数器空间是有限的，计数每次写入都前进，因此 RPMB 的总写入次数有上限。把高频事件持续写进 RPMB 是设计错误——它既会撞上计数空间，也会带来不可接受的开销。RPMB 应该只存「低频但高价值」的状态。

4.5 RPMB 帧结构与响应码流程

下面这张图把认证写入的帧字段与六个步骤画在一起，同时给出三类典型错误响应的成因与对策。它是实现与排查 RPMB 时最常回查的一张图。

4.6 常见失败模式与排查路径

RPMB 的失败往往表现为一句含糊的错误码。排查的关键是先判断失败发生在哪一层：是认证没过、计数不对、还是空间与帧长问题。这三类失败的处理方式完全不同，混在一起试会浪费时间。