UFS 协议栈与 UniPro/M-PHY

分层传输、Lane 与 Gear 的性能机制，以及相对 eMMC 的架构差异 —— 一份面向系统与硬件协同的协议栈参考 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0

结论： UFS 相对 eMMC 的本质升级不是「更快」，而是把存储协议、通用互联与物理层拆成三层可独立演进的规范—— 带宽由 Lane 数 × Gear 档位 两个物理量直接决定，而并发能力由 任务 Tag 与多队列模型 决定； 这两组变量都在协议栈里有明确归属，因此性能与并发问题可以逐层定位，而不是像 eMMC 那样只能整体调时序。 所有数值均为量级描述，实际设计一律以正式 JEDEC / UniPro 规范与器件 datasheet 为准。

读者路径

• 只想弄清 UFS 到底是什么：第 1 章（三件套身份与生态全景）+ 附录 A（术语表），十分钟可读完。
• 要做 Host Controller 侧的软件设计：第 3 章（UTP 与队列）+ 第 4 章（命令语义）+ 第 7 章（并发与 QoS），这是本文的核心。
• 要排查链路起不来 / 速率上不去：第 5 章（UniPro 分层与 AER）+ 第 6 章（M-PHY 与 Gear）+ 第 10 章（初始化全流程）。
• 从 eMMC 迁到 UFS：第 2 章（架构对照）+ 第 4.5 节（迁移陷阱）+ 第 11 章（架构性差异）+ 第 11.6 节（检查项清单）。
• 做容量规划与分区设计：第 8 章（LUN 与 LU 组织）+ 第 2.4 节的两级结构。
• 现场出问题需要一个排查顺序：直接跳第 12.3 节 + 第 14 张图（分层定位排查树）+ 附录 C（分层排查手册）。

与同系列文档的分工

• UFS 电路设计指南：负责电源域划分、电压与电流、时钟与复位、差分布线与阻抗、器件选型与替代、PCB 与信号完整性。本文的第 6 章只讨论物理层的协议机制，不讨论布线和阻抗。
• UFS 软件设计规范：负责主机控制器的寄存器组配置顺序、中断处理、DMA 与描述符管理、驱动移植与调试。本文的第 3、4、10 章讨论的是这些流程背后的协议理由，不给出寄存器级步骤。
• 本文：负责分层模型、每层的职责边界、Lane 与 Gear 的带宽机制、架构差异，以及分层定位方法。

1. UFS 是什么，以及为什么值得单独拆开讲

这一章不深入任何一层，只先把 UFS 的身份讲清楚：它不是一颗器件，也不是一条总线，而是三份规范共同定义的一整套系统。身份讲不清，后面所有的性能与并发讨论都会失去落点。

1.1 从 eMMC 到 UFS：变化的不是速率而是架构

eMMC 与 UFS 都能挂在同一块 SoC 上、都能跑同一个块设备接口，从上层看几乎一样。真正的差别埋在下面：eMMC 把协议、时序与数据通路压在一条并行总线上，UFS 把它们拆成了三份可以各自升级的规范。

这个差别带来的直接结果是：eMMC 时代的性能调优手段是「加宽总线、调时序」，UFS 时代的性能调优手段是「加 Lane、升 Gear、并发排队」。前者受制于引脚数量与布线，后者的上限由架构直接给出。

1.2 UFS 的身份：存储标准、互联标准、命令集三件套

「UFS」这个词在实际语境里同时指三样东西，它们由不同的规范组织维护、版本独立演进。工程上出问题时，第一件事就是判断它属于哪一件，因为三者的责任方与排查路径完全不同。

1.3 谁在用、用在哪

UFS 已经离开「手机专属」这个标签。它今天落在四类场景里，而这四类场景对协议栈的诉求并不相同——这正是理解 UFS 值得单独拆开讲的原因。

1.4 UFS 生态全景图

把上面三件套与四类场景叠在一起，就是 UFS 的完整生态：中间是互联层，上面接主控侧的软件栈，下面接设备的存储管理，左右两侧是命令集与标准的版本。

1.5 本文的主线：一个请求从主机到 LUN 再回来的全程

全文都围绕同一条主线展开：一个读请求从主机应用出发，经过协议栈的每一层，到达某个 LUN 的 NAND，再把响应原路送回。这条主线在第 2.5 节展开为完整路径，在第 12.3 节反向使用——从故障症状倒推它卡在哪一层。

把这条主线先记住，后面每一章都是在放大其中某一环。第 3、4 章放大第 ②③ 环，第 5、6 章放大第 ④⑤ 环，第 7、8 章放大第 ⑥⑦ 环，第 9、10 章则讲每一环失败时怎么归因。

2. 系统架构：主机控制器、设备与 LUN

这一章把 UFS 系统拆成两个主体、一条链路和两级逻辑单元。重点不是罗列模块，而是说清每个模块为什么必须存在——因为每个存在理由都对应一类线上问题。

2.1 UFS 系统的两大主体：Host Controller 与 UFS Device

一个 UFS 系统只有两个主体：主机侧的 Host Controller 与设备侧的 UFS Device。两者之间是一条点对点的串行链路，没有总线仲裁，也没有第三方设备挂在中间。

• Host Controller 才是「主控」：它持有队列、调度、QoS 与主机侧缓存，是性能的主要决定方。SoC 里集成的是它，而不是某个存储控制器外挂器件。
• UFS Device 是「被访问方」：它内部有自己的命令执行器、LUN 管理、FTL 与 NAND 阵列，主机无法直接看到物理布局。
• 链路是独占的：这是 UFS 与 eMMC 最大的拓扑差异。独占意味着没有仲裁开销，但也意味着主控与设备必须成对设计：主控的 Gear 档位必须落在设备支持的档位之内。

2.2 Host Controller 的组成

Host Controller 从上到下分四块，每一块的职责边界都很清晰。划清这四块的意义在于：性能问题必须先定位到是哪一块的职责——排队问题看队列管理，链路问题看物理层，两者混淆是排查效率最低的原因。

2.3 Device 内部的组成

设备侧同样可以拆成四块。它的存在理由比主机侧更「物理」：NAND 天生不能随机写、不能原地覆盖、单元会慢慢失效，所以设备侧必须有人负责把这些物理特性屏蔽掉。

这里有一个必须建立的判断：第 9.2 节讲的设备端 ECC 校验与磨损均衡，实际都在设备侧完成。主机只看得到「逻辑块读出来了没有」，看不到 NAND 上的物理错误与磨损分布。这也是为什么某些看起来像主机驱动问题的现象，根因在设备侧。

2.4 LUN 与 LU：逻辑单元的两级结构

UFS 把「逻辑单元」分成两级：LUN 是主机可见的并行单元，LU 是 LUN 内部的执行单元。两级结构的意义在于，并行性由 LUN 提供，主机不必关心；执行粒度由 LU 提供，设备可以自由优化。

2.5 一个请求的完整路径

下面把第 1.5 节的八个环节展开成一张完整的路径表。每一环都标明它消耗的时间属于哪一类：协议开销、排队等待、链路传输还是介质访问。这四类时间的比例关系，决定了优化应该往哪个方向使劲。

2.6 eMMC 与 UFS 的架构对照

下图把两者按四个维度并排对照。阅读时建议逐行看「差异的性质」一列：如果某一项写的是「语义级」，那么迁移时只需要改代码逻辑；如果写的是「架构级」，那么迁移意味着要重新设计并发与调度策略。

2.7 架构差异带来的工程后果

架构差异不是抽象概念，它直接决定四类工程后果。这四类后果分别对应四个团队：硬件团队、驱动团队、系统团队与测试团队，职责边界清楚，协作时才不会互相等待。

3. UFS 传输层 UTP：请求的封装与排队

UFS 传输层简称 UTP，它是主机侧真正处理 I/O 请求的地方。这一章要讲清一件事：一个上层的读或写请求，是怎么变成链路上的字节、又是怎么把响应准确送回原请求的。

3.1 UTP 的任务单元模型：一条 UPIU 对应一个请求

UTP 的基本抽象是任务（Task）：一个任务就是一个请求，它由若干个 UPIU 组成——命令 UPIU 必有一份，数据段按读写方向可选，响应 UPIU 必有一份。这三条合起来构成一次完整的交互。

「一条 UPIU 对应一个请求」这个说法需要精确化：一个请求对应一组 UPIU，而不是恰好一条。之所以仍然按「一条对应一个」来理解，是因为 UPIU 内部自带 Tag 字段，Tag 把这组 UPIU 绑定成一个不可分割的整体。

3.2 UPIU 的种类与流向

UPIU 的流向规则可以用一句话概括：命令向下、数据按方向、响应向上。所有复杂度都来自「数据方向」这一条——同一种数据 UPIU，在读请求里由设备发出，在写请求里由主机发出。

3.3 请求的排队与调度：Tag 的作用

Tag 是一个由主机分配、由设备原样回填的编号。它的生命周期只有四步：分配、绑定、随响应返回、归还池中。这四步任何一步出错，表现都是「数据串了」或者「请求丢失」。

3.4 多个请求并发时的乱序返回

UFS 允许不同Tag 的请求以任意顺序完成。这一条是并发能力的直接来源，也是与 eMMC 最大的行为差异之一。它带来的收益有两面。

• 收益一：消除队头阻塞。一个慢请求不会挡住排在它后面的快请求。在混合负载下（读多写少、随机小块与顺序大块混杂），尾延迟改善非常明显。
• 收益二：设备侧可以乱序调度。设备可以把请求按自己的 NAND 通道与缓存状态重排，最大化内部并行度，主机无需知道这件事。
• 代价一：主机必须正确配对。没有顺序约束意味着配对责任完全落在 Tag 上，任何一处Tag 处理错误都会造成数据串位。
• 代价二：错误处理更复杂。设备上报错误时可能只说「某个 Tag 失败了」，主机必须自己判断这个 Tag 对应哪个请求、是否需要重试。

3.5 队列模型：CQ 与 SQ 的角色

UTP 用两条队列把「提交」与「回收」分开管理。这种设计看似多了一层，实际上是并发能力的必要条件：提交方向由软件掌握节奏，完成方向由硬件异步推送。

这里有一个必须建立的配对关系：Tag 消耗速度由 SQ 决定，Tag 归还速度由 CQ 决定。两者一旦失衡——提交快于完成，或完成快于消费——都会出问题。所以调优队列时不能只看单侧深度，必须成对考虑 SQ 深度、CQ 深度与 Tag 数量三者的关系。

3.6 任务状态机

一个任务从诞生到释放会经历五个状态。状态机本身不复杂，但状态之间的合法与非法转移是最容易出bug 的地方，因此值得明确列出。

3.7 流控与信用机制

流控解决的是一个很朴素的问题：对端不一定收得过来。发送速率由本地驱动决定，而接收能力由对端的缓冲深度与当前负载决定，两者不一致时如果不管，缓冲就会溢出丢数据。

• 分级信用：UniPro 的流控是分级而不是单一的，缓冲区满时可以先挂起某一级流量，让其它流量继续。这比「一卡就全停」的方式平滑得多。
• 缓冲与流控发生在 L1.5 抽象层：这正是 L1.5 这一层存在的理由——它不搬运数据，只负责告知对方还能发多少。
• 流控等待是最隐蔽的性能杀手：它不表现为错误，只表现为吞吐下降，且日志里什么都看不到。可靠的判据是流控等待时长占比。

4. UFS 命令集：SCSI 血统与语义差异

UFS 采用的是 SCSI 血统的命令集，而不是 eMMC 那种命令号加参数寄存器的风格。这一章讲清三件事：为什么这样选、命令的结构长什么样、从 eMMC 迁过来会在哪些语义上出错。

4.1 为什么 UFS 用的是 SCSI 命令集而不是 CMD 家族

CMD 家族的设计前提是「设备就是一张卡」：命令号唯一决定行为，参数通过寄存器给出，操作符与参数一一对应。这套模型在 eMMC 时代很好用，因为它极其直白。

但 UFS 面对的场景变了：主机侧要维护队列、要支持乱序、要处理多条数据流。此时「一条命令对应一个参数寄存器组」的模型显得太窄——它没有地方放描述块指针，也没有地方放队列上下文。SCSI 血统的命令结构天然带描述块概念，因此更适合。

4.2 命令、描述块、数据段的统一结构

一条 UFS 命令在协议上由三段组成。三段的职责必须分清，因为混淆三段是写驱动时最常见的结构性错误。

• 命令段回答「做什么」：命令码、传输方向、长度、属性标志（如是否绕过缓存、是否强制落盘）。
• 描述块段回答「数据在哪」：一段连续内存的起始位置与总长度。主机在发起命令前必须先把数据缓冲区准备好并保持稳定，直到命令完成。
• 数据段段是「数据本身」：按写单元大小切成多个 UPIU 依次传送。

4.3 常见命令族：读、写、缓存、同步、查询

UFS 的命令按用途可以分成五族。理解这五族的划分方式，比记住具体命令名更有用——因为每族的语义约束完全不同。

4.4 与 eMMC CMD 家族的语义映射表

下表给出两套命令体系的语义对应关系。它不是等价替换表，而是「意图相同、实现不同」的对照表：最右一列写的是迁移时真正需要注意的地方。

4.5 语义映射带来的迁移陷阱

把上表的陷阱按「写代码时会不会想错」重新组织一遍，得到六条具体的迁移检查项。它们都属于语义级差异，改代码逻辑即可，不需要重新设计架构。

4.6 关键命令的时序要求与完成顺序约束

UFS 的命令之间存在若干顺序约束。这些约束不写清楚，代码在上并发下会出现极难复现的错误，因此值得单独列出来。