前阵子做手机存储性能优化，又把UFS3.1协议翻出来啃了一遍。这个协议在嵌入式存储圈子里挺容易让人犯迷糊——你说它是存储接口吧，它又带了一套完整的“网络协议栈”；你说它简单吧，光看JEDEC规范那几百页就能把人劝退。这篇就把UFS3.1协议的学习思路和核心知识点梳理一遍，给想入门存储协议、或者正在调试UFS3.1设备的同学做个参考。
1. 先搞明白UFS3.1到底是个什么“协议”
1.1 它不是单纯的闪存接口，而是一套完整的通信协议栈
UFS（Universal Flash Storage，通用闪存存储）这个名字看着像“闪存标准”，实际上它定义的不只是物理接口和命令集，而是一整套从应用层到物理层的通信协议栈。这也是UFS和eMMC最大的区别：eMMC更像一块“带控制器的闪存芯片”，主控和芯片之间走的是并行总线，命令交互相对简单；而UFS把设备设计成了“存储服务器”，内部有独立的协议处理单元、命令队列、多路虚拟通道，甚至支持类似于网络通信的分层架构。
UFS3.1这个版本延续了UFS3.0的架构，在性能、功耗和可靠性上做了进一步优化。它由JEDEC（固态技术协会）发布，核心规范包括JESD223系列和JESD220系列，其中UFS3.1涉及的关键特性包括WriteBooster（写入加速器）、Host Performance Booster（主机性能加速器，HPB）、DeepSleep（深度睡眠）、分区和命令队列等。
从一个从业者的角度来看，理解UFS3.1协议，本质上是在理解三样东西：一是命令如何被封装和传输，二是数据如何被搬运和确认，三是设备和主机之间如何握手和协商。这三样恰好对应着协议栈的应用层、传输层和链路/物理层，下面逐步展开。
1.2 UFS3.1在存储生态里的坐标
把UFS3.1放到存储接口的版图里看会更有感觉。早期的手机和嵌入式设备多用eMMC，速率低、半双工、无命令队列；后来有了UFS2.0/UFS2.1，开始走串行全双工，性能明显提升；到了UFS3.0把速率推上了Gear4，再到UFS3.1补充了写入加速和主机性能加速，基本就是移动端的主流旗舰配置。
如果拿它和PC端的SSD对比：SATA SSD的顺序读大概500~560MB/s，NVMe SSD的顺序读可以到2000~7000MB/s，而UFS3.1在2条Lane、HS-G4速率下理论顺序读可以去到2100MB/s以上，顺序写也能到1200MB/s左右。也就是说，UFS3.1的性能已经不输入门级SATA SSD，甚至直逼部分NVMe SSD的温热区。这也是为什么手机厂商反复强调“UFS3.1”的原因——它直接关系到大型应用加载速度、4K视频录制流畅度、游戏场景切换速度等用户能感知的体验。
所以这篇博文不只是给存储工程师看的，做手机BSP、底层驱动、性能测试的朋友也能从协议层面找到排查问题的线索；如果你对通用通信协议感兴趣，UFS3.1更是一个绝佳的案例，因为它同时包含了命令协议、链路协议、物理层信号协议和电源管理协议。
2. 拆开UFS3.1协议的三层结构：UPIU、UTP、UICP
2.1 UFS协议栈的分层设计
JEDEC把UFS协议栈画成三层，熟练之后会发现这套分层思路和TCP/IP高度相似：
- 应用层（Application Layer）：处理SCSI命令、UFS专属命令（如Query）、任务管理请求，负责和上层文件系统对接。
- 传输层（UTP：UFS Transport Protocol）：把上层的命令和状态封装成UPIU（UFS Protocol Information Unit）包，负责端到端的传输语义。
- 链路和物理层（UICP：UFS Interconnect Layer）：由MIPI联盟的M-PHY和UniPro组成，负责比特级别的信号传输、链路建立、错误重传和功耗管理。
为什么要分层？因为解耦。上层的命令格式不依赖物理层实现，M-PHY后续升级到更高Gear，上层代码不用大改；同理，物理层的信号抖动问题不会污染到命令语义层。实际调试的时候，链路层跑不通只会表现为“超时”，但不会变成“数据错乱”，这种隔离设计让问题排查的边界特别清晰。
对初学者来说，最容易犯的错是直接扎进M-PHY的电气特性里出不来。我的建议是反过来：从最上层的命令格式看起，知道数据怎么被组织，再往下看UPIU怎么封装，最后才去看物理层怎么把bit流送出去。
2.2 核心数据结构UPIU：命令和数据的“信封”
UPIU是整个UFS协议的精髓，你可以把它理解成一个信封。信封外面写着收件人和信件类型，信封里面装着真正的命令或数据。一个标准的UPIU由头部（Header）和可选的数据区（Payload）组成，头部常见字段包括：
- 传输类型（Transaction Type）：标明这是命令、数据还是响应。
- 逻辑单元号（LUN）：目标存储分区。
- 标志位和任务标签：用于关联请求和响应。
按照类型，UPIU可以分成几大类，整理成下表更直观：
| UPIU类型 | 方向 | 作用 |
|---|---|---|
| NOP_OUT / NOP_IN | 主机到设备 / 设备到主机 | 链路保活、测试通信 |
| Command UPIU | 主机到设备 | 封装SCSI命令或UFS命令 |
| Data In UPIU | 设备到主机 | 读取数据返回 |
| Data Out UPIU | 主机到设备 | 写入数据发送 |
| Response UPIU | 设备到主机 | 返回命令执行状态 |
| Task Management UPIU | 主机到设备 | 中止任务、复位逻辑单元 |
| Query Request UPIU / Query Response UPIU | 双向 | 读取/设置设备属性和标志 |
以一次最简单的READ请求为例，完整的过程是：主机发送Command UPIU（内含SCSI READ命令）→ 设备解析命令 → 设备准备数据 → 设备发送Data In UPIU把数据送回主机 → 最后设备发送Response UPIU告诉主机这次传输成功。这一套东西，有点像一个“快递”过程：下单、备货、派送、签收，每个环节都有独立的消息类型。
实际抓包的时候，看到的就是一串UPIU头的十六进制数据。想要快速读懂，先背熟传输类型的取值表，再关注命令描述符块（CDB）里的操作码，然后看LUN和逻辑块地址，基本就能串起一条命令的完整生命周期。
2.3 命令与任务管理：怎么发起一次读写
UFS设备支持的底层命令集沿用了SCSI命令模型。普通读写走READ(10)/WRITE(10)，格式化、容量查询、参数模式选择等走其他SCSI命令。用惯了NVMe的人可能会觉得SCSI命令有点“老气”，但它的好处是生态成熟，文件系统层和存储层之间的适配成本低。
除了SCSI命令，UFS还有一套专属的Query命令机制，专门用来访问设备属性（Attributes）、标志（Flags）和描述符（Descriptors）。举个例子，想查看UFS设备的厂商信息、固件版本、健康状态，不是直接读内存地址，而是发一个Query Request去读Device Descriptor，设备再通过Query Response返回数据。这种设计很像I2C协议里的寄存器读写，只不过UFS的“寄存器空间”是逻辑化、结构化的。
任务管理（Task Management）也很关键。如果某条命令卡死，主机可以发送Task Management UPIU去中止任务、复位逻辑单元，甚至进行全设备复位。这就相当于操作系统的进程管理器，是保证协议健壮性的兜底手段。调试UFS设备时，如果设备不进睡眠、命令一直挂起，第一步就该检查是否收到过或者发出过任务管理请求。
3. UFS3.1的物理层与速率：M-PHY和UniPro是怎么跑起来的
3.1 M-PHY：底层高速串行链路
M-PHY是MIPI联盟定义的高速串行物理层规范，UFS的物理传输通道就是它。M-PHY支持两种工作模式：PWM模式（低速、极低功耗）和HS模式（高速、高性能）。每种模式下又分为多档Gear，速率逐级翻倍。UFS3.1常用的高速档位如下：
| Gear档位 | 每Lane速率（HS模式） | 2 Lane聚合速率 |
|---|---|---|
| HS-G1 | 约1.25 Gbps | 约2.5 Gbps |
| HS-G2 | 约2.5 Gbps | 约5 Gbps |
| HS-G3 | 约5 Gbps | 约10 Gbps |
| HS-G4 | 约12 Gbps | 约24 Gbps |
注意，以上都是物理层线速率，实际有效带宽打折，因为还有协议开销、流控、重传和时钟补偿，真实顺序读速度大约只有理论带宽的六到七成。所以UFS3.1标称2100MB/s左右的顺序读，背后对应的就是HS-G4、2 Lane的配置。
M-PHY还有一个特点：全双工。发送和接收各有独立通道，读写可以同时进行，不会像eMMC那样读写相互排队。这带来的用户体验提升很直观——你一边下载文件一边看视频，不会因为存储写入忙而频繁卡顿。
3.2 UniPro：数据链路层的“轻量交换机”
UniPro负责M-PHY之上的数据链路层功能，包括帧封装、错误检测、重传机制、流量控制和虚拟通道管理。按我个人的理解，UniPro在UFS协议栈里扮演的角色，很像网络交换机里跑的链路层协议：它把M-PHY上的原始bit流组织成帧，为逻辑单元和主机之间建立“连接”。
链路建立时，设备会和主机做速率协商，从最低Gear开始逐级训练到双方支持的最高速率。选高了可能不稳定，选低了浪费性能，所以协商算法很讲究。UFS3.1还完善了Link Startup Time，缩短上电初始化时的链路建立时间，这对手机冷启动速度影响不小。
另外要提的是电位移除（Power Mode Change）。UFS设备有Active、Sleep、DeepSleep等电源状态，链路也会配合进入不同的速度和功耗档位。省电和性能之间怎么平衡，往往是BSP调优的重点。系统想快速唤醒时，如果链路从DeepSleep恢复慢了，整个手机解屏体验都会受影响。
3.3 为什么说UFS3.1已经很接近入门级SSD的性能
把物理层、链路层和命令队列串起来看，UFS3.1的架构在设计目标上就是奔着“小尺寸SSD”去的。它有命令队列（支持多命令并发）、全双工通道、高带宽物理层，再加上内置的WriteBooster机制 ——利用SLC缓存吸收突发写入，让持续写入速度更平稳。
实际测试中，UFS3.1的顺序读、顺序写分别能达到2100MB/s和1200MB/s左右，随机读IOPS可达数万级。对比eMMC 5.1的顺序读只有300MB/s上下，差异是数量级的。普通用户能感知到的场景包括：
- 大型游戏地图加载：场景资源文件动辄几百MB，存储带宽直接决定加载条跑多快。
- 4K高码率视频录制：写入速度不够就会丢帧。
- 多任务切换时应用重开：随机读性能决定冷启动应用和数据回读速度。
这也是手机厂商在发布会上愿意花一整页PPT讲UFS3.1的原因。存储性能早就成了旗舰机的“隐形参数”，协议层面的领先最终会落到用户摸得到的流畅度上。
4. 实操视角：规范文档怎么读、设备怎么调试
4.1 规范文档获取与阅读路线
UFS3.1的正式规范在JEDEC官网可以获取，主要文档编号是JESD223系列（UFS标准）和JESD220系列（UFS3.1规范本身）。拿到这堆文档之后，别试图从头翻到尾，否则大概率在前一百页就睡着了。我建议按这条路线来走：
- 先看第一章和术语表，搞明白缩写和基本概念，比如LUN、UPIU、Attributes、Flags。
- 找到UPIU格式章节，把几种关键UPIU的头部字段对照着画一张表。
- 找到命令集章节，重点看READ、WRITE、QUERY、TASK MANAGEMENT四类。
- 找到设备管理章节，了解描述符和属性怎么读怎么写。
- 最后再看M-PHY/UniPro相关的物理层和链路层细节。
这个顺序是从“应用视角”切入“传输视角”，最后才到“信号视角”。每读一层，最好配合Linux内核里的UFS驱动代码一起看，源码在drivers/scsi/ufs/目录下。读驱动能帮你把抽象规范落回具体结构体、函数和寄存器操作，比单纯啃文档效率高得多。
4.2 调试设备与常用的工具渠道
调试UFS3.1设备，工具可以从硬件和软件两个层面组织。硬件层面，如果有条件可以用逻辑分析仪接在M-PHY链路上抓信号，能够直观看到时序、训练过程和异常波形。不过M-PHY频率很高，普通逻辑分析仪不一定吃得动，这时候厂商的协议分析仪（比如Synopsys、Cadence、Keysight的存储协议分析方案）会更顺手，代价是设备贵、使用门槛高。
软件层面，更常用也更接地气的方式是看设备的 sysfs 节点和利用UFS驱动程序打印的日志。Linux下UFS设备通常挂载在/sys/bus/platform/devices/下，可以读到设备描述符、健康信息、电源状态。如果驱动支持，还能通过 debugfs 接口触发特定的Query命令，直接读写某个属性和标志。
我自己的调试习惯是：先读设备信息（厂商、容量、固件版本），确认链路速率协商到哪一档；再用工具下发典型的READ/WRITE命令，看UPIU交互是否正常；最后通过修改设备属性测试不同电源状态下的响应时间。三步走完，大多数协议层问题都能定位到具体块。
4.3 我踩过的坑：协议学习中的三个典型误区
第一个误区是把重心放在物理层信号细节上。新人容易一上来就研究M-PHY的眼图、抖动和阻抗匹配，结果看了半个月还在第一页。说实话，除非你是做芯片或板级硬件设计的，否则物理层的东西对大多数人来说是“知道存在即可”。协议栈上层才是影响日常问题排查的关键。
第二个误区是只看命令格式、忽略时序和状态。UPIU长什么样固然重要，但协议真正的精髓在于交互顺序。命令什么时候发、超时多久算失败、设备在什么状态下才能收命令、链路在什么状态下才能传数据，这些才是线上问题排查的核心。我以前就吃过亏，光顾着解析包格式，结果设备因为电源状态管理错乱导致命令挂起，查了半天才反应过来。
第三个误区是不看状态机就上手调试。UFS设备的设备状态、链路状态、电源状态之间是有约束关系的，比如DeepSleep状态下不能直接发正常的读写命令，得先恢复Active状态。如果不理解这套状态机，抓包分析时很容易把“设备不响应”误判成“链路断了”。所以读协议规范时，把状态转换图多看几遍，比背命令格式有用得多。
关于辅助调试，我推荐一个轻量级思路：在PC上用虚拟UFS控制器（qemu的存储模拟模块）或者在开发板上挂一颗UFS芯片做协议学习平台，配合写小的测试脚本发送命令、解析响应。这样既能反复练习，又不会像直接用手机主板调试那样“搞坏了就开不了机”。
5. 从UFS3.1到一个通用的协议学习方法论
5.1 学任何通信协议都可以用的三步法
啃完UFS3.1这几个月，我最大的收获不是记住了多少个命令码，而是形成了一套看协议文档的方法。第一步，分层理解：不纠缠细节，先把协议划分成应用层、传输层、链路层、物理层，明确每层解决什么问题；第二步，抓核心交互流程：找出协议里最典型的读、写、配置、复位四类操作，在纸上画出完整的请求-响应序列；第三步，对照真实实现：找一套开源驱动或一个案例抓包，把纸上的时序打上实际的时间戳和字段值，这一步能让所有抽象概念落地。
这套方法我后来拿来学MIPI、USB PD、甚至是车里的CAN协议都能快速上手。不同协议的具体格式千差万别，但“谁和谁通信、用什么消息、按什么顺序、出错怎么办”这四个问题，是通用框架。
5.2 协议学习的“阅读理解题”思维
很多时候我们搞不定协议，不是因为资料少、智商不够，而是因为姿势不对。协议本质上是一份“双方约定的契约”，读的时候要时刻问自己：这条消息是谁发给谁的？期待对方做什么？如果对方不回复，超时是多久？对方回复了，可能有哪些状态值？把这些捋清楚了，文档里的表格、枚举和结构体都会变得好懂。
我见过很多工程师说“协议文档太枯燥”，其实枯燥是因为没有目标。带着一个真实问题去读，比如“为什么我的UFS3.1写入速度只有标称的一半”“为什么DeepSleep之后唤醒要等两秒”，你会发现规范围着问题转，读起来会快很多，记忆也更牢。
5.3 一点个人体会
最后说点私人经验。做底层协议这块，真正拉开差距的往往不是智商，而是“愿意沉下心把文档啃完”的耐心，以及“亲手跑一次设备”的动手能力。看十篇二手解析文章，不如自己读几页原始规范；读一遍规范，不如自己写个脚本发一条命令试试。
我第一次抓UFS3.1的UPIU包时，看着满屏十六进制一头雾水，后来把头部字段逐一对照文档画成表格，半小时后就完全清晰了。从那以后，我开始习惯每学一个新协议就做一页“协议一图流”，把命令格式、交互时序、状态机压在一页纸里。UFS3.1那几百页规范，现在在我桌上就是这几张A4纸，平时调板子、排查问题的时候翻一眼，比查PDF快得多。这个习惯，算是这几年做存储底层工作最值钱的沉淀了。
