做了这么多年嵌入式我见过不少从SPI、IIC、UART甚至CAN协议入门的朋友第一次翻开UFS协议规范时的表情——上千页英文文档分了四五层协议命令还要套一层SCSI的外壳确实吓人。2022年我因为项目需要调UFS 3.1底层驱动硬着头皮啃完了JEDEC的UFS 3.1规范、UFSHCI接口文档以及MIPI联盟的M-PHY和UniPro相关材料中间踩了不少坑也终于把整个协议栈从各个层认识我到我也认识各个层梳理通了。这篇文章算是我沉淀下来的中文学习笔记整理按1~4四个部分展开UFS 3.1到底解决什么问题、协议栈怎么分层、核心命令怎么流转、初始化调试有哪些坑。适合刚接触存储协议、想在手机或嵌入式平台做底层开发或者单纯好奇手机闪存读写原理的朋友。1. 为什么UFS 3.1值得单独拉出来学从eMMC到UFS的演进逻辑1.1 eMMC与UFS是两套完全不同的交通规则很多人的认知还停留在eMMC比UFS慢这个结论上但真正做底层的人必须清楚它们不是同一类东西的简单升级而是彻底换了一套通信模型。eMMC本质上是并行总线8根数据线、1根时钟线、1根命令线命令和数据走不同的物理通道但同一时刻数据线只能朝一个方向传输属于半双工。协议栈很薄控制器把命令、地址、数据按固定时序放在线上就行。这种设计实现简单、成本低但天花板也很明显——并行线的信号同步在高频下很难做所以eMMC 5.1的实际顺序读速度跑到400MB/s上下基本就到头了。UFS则完全不同。物理层是M-PHY采用串行差分信号一条lane就是一对差分线UFS 3.1设备通常有2条lane可以同时收发数据全双工。协议栈是分层的从底到顶依次是M-PHY、UniPro、UTPUFS Transport Protocol最上面承载SCSI命令集。用大白话说eMMC像是老式电话交换机接线员手动把一条线接到另一条线UFS更像一套完整的邮政网络有分拣中心、有运输干线、有签收确认每封信还要贴标准面单。这就解释了为什么同样叫闪存存储协议eMMC和UFS的调试难度完全不在一个量级。你拿着示波器看eMMC的时序能判断问题但UFS出问题时你往往要先搞清楚是物理层信号差、链路层重传多还是协议层命令超时。特性eMMC 5.1UFS 2.1UFS 3.0 / 3.1物理层8-bit并行总线M-PHY HS-G3M-PHY HS-G4总线模式半双工双lane全双工双lane全双工理论带宽约400MB/s双lane约11.6Gbps双lane约23.2Gbps命令集私有命令SCSI命令SCSI命令命令队列最多32最多32最多32数据保护简单CRC链路层重传CRC链路层重传CRC1.2 UFS 3.1的版本亮点不只有快UFS 3.0把带宽翻倍UFS 3.1在这个基础上又补了几个关键特性其中有两个在实际产品里感知特别明显。第一个是WriteBooster中文领域常叫写加速器。原理不复杂设备内部拿出一部分SLC模式的NAND块专门做写缓冲主机写数据时先以SLC速度快速写入这块缓冲区等设备空闲了再把数据搬移到TLC/QLC大容量区域。因为SLC写入比TLC快得多尤其对随机小写入性能提升非常明显。但注意缓冲区不是无限的如果持续写入把Buffer写满速度就会掉回TLC直写的水平。厂商跑分很好看实际连续大文件拷贝时掉速根源往往就在这里。第二个是DeepSleep深度睡眠。UFS设备工作状态很耗电以前Sleep模式下功耗还是偏高DeepSleep直接把设备内部大部分电路关掉功耗能压到非常低的水平。代价是唤醒时间变长主机需要重新建立链路才能发命令。手机息屏待机、平板挂后台这种场景DeepSleep省电效果很可观但如果在唤醒机制设计不完善时强行进入反而会导致系统卡顿或命令超时。另外还有Host Performance BoosterHPB。它的思路是让主机侧内存缓存设备内部L2P映射表的一部分这样随机读时设备不需要每次查大表减少读放大和延迟。HPB启动时先给主机发映射数据之后主机维护本地缓存设备发生映射更新时再同步。这个特性对容量越大的设备收益越明显但会占用主机内存实际手机产品上是否开启、开多大都是要权衡的。Performance Throttling NotificationPTN则是散热相关的机制设备检测到温度过高或功耗异常时会主动给主机发通知主机可以据此调整负载策略。这个特性在手机上尤其重要长时间跑分或者快充时存储芯片发热导致性能下降有PTN之后系统能感知到原因而不仅仅是跑分变低了。1.3 与SPI/IIC/CAN这些老朋友有什么不同如果你是从MCU开发转过来的之前调过SPI、IIC、UART、CAN我很理解第一次看UFS协议时的错愕。SPI是一条主时钟加几条数据线主从之间收发数据逻辑简单到一眼能看穿IIC更简单两根线靠地址寻址一主多从有ACK机制CAN是差分总线有报文ID、仲裁、错误帧但本质还是大家挂在一条总线上抢着发消息。UFS完全不是这种玩法。它没有总线概念是严格的主从点对点连接Host和Device之间通过两条lane相连。它的可靠性不靠物理层保证而是靠UniPro层处理重传、流控、拆包打包。它的命令不叫寄存器读写而是完整的SCSI命令一条命令有明确的命令描述块、传输长度、数据缓冲区甚至支持乱序执行和多个命令并行。更直白的对比是SPI/IIC/CAN就像小区门口的保安看见熟人直接放行UFS像国际机场海关每个旅客都要过安检、登记、查签证、托运行李虽然流程复杂但能承载的旅客量和安全性远超小区门口。所以学UFS之前要先调整心态不要指望看完某个命令的时序图就能跑起来你需要建立的是分层定位问题的思维方式。这也是我后面三个部分要重点展开的内容。2. UFS 3.1协议栈整体拆解UTP、UniPro、M-PHY三层各管什么2.1 一个写文件请求从应用层到NAND的完整旅程先建立一个全局视图我们用手机里把一张照片写入存储这个场景来走一遍。应用层调用文件系统文件系统把逻辑地址转换成块设备层的LBA逻辑块地址然后通过Linux块设备层下发一个写请求。这个请求到达UFS Host Controller也就是SoC里的UFS控制器后控制器把它封装成一个UFS协议信息单元即UPIU这是UTP层的核心概念。UPIU里包含了这条命令的类型、目标逻辑单元号、起始LBA、传输长度、数据缓冲区地址等信息。UPIU不会直接上物理线。它先被交给UniPro层处理UniPro层会把UPIU当成上层负载进行拆分打包加上自己的头部信息做路由和序号管理同时实现流控和重传机制。再往下M-PHY层把这些数据包变成高速串行差分信号通过两条lane发送给设备。设备端收到信号后按相反的顺序解包M-PHY还原比特流UniPro层检查完整性、做重组最后把UPIU递给UFS Device的UTP层解析识别出这是一条SCSI WRITE命令。设备内部的Flash Translation LayerFTL负责把LBA映射到具体物理页最终把数据写入NAND。写完后设备再按原路返回一个Response UPIU告诉主机写完了。整个过程听起来很长实际上因为协议栈每层都是硬件流水化处理真正耗时主要在NAND擦写本身。协议栈的开销相对于NAND操作时间来说占比很小SSD和UFS的优化重点从来都不是协议层而是怎么减少NAND操作次数。2.2 UTP层UPIU的格式与类型UTP层是UFS协议栈里最靠近主机的部分它的工作就是定义主机和设备的对话单元——UPIU。所有主机发给设备的命令、设备返回的响应、数据搬运全靠UPIU承载。按功能划分UFS里最常见的UPIU有4类Command UPIU主机向设备发送命令里面装载SCSI命令描述块CDB是请求的发起者Data In UPIU设备向主机返回数据比如读命令读出的NAND内容Data Out UPIU主机向设备发送数据比如写命令要写入NAND的内容Response UPIU设备回复命令执行结果包含状态码、Sense Key等信息。以Command UPIU为例它的头部包含传输类型Transaction Type、任务标签Task Tag、逻辑单元号LUN、期望数据传输长度、数据方向等字段。任务标签非常重要因为UFS支持最多32个命令同时在设备内部执行主机下发每条命令时分配一个Tag后续唤醒、汇报完成状态都靠这个Tag区分。你甚至可以理解为快递单号——很多包裹同时在运输每个包裹都有独立单号签收时才不会搞混。关于UPIU有个细节值得注意一个UPIU不一定只装一次数据。对于大数据块读写协议允许把数据拆成多个Data UPIU传输而Command UPIU只是先告诉设备准备收一批数据。设备端通过header里的传输类型和期望长度字段判断当前UPIU属于哪个命令、是不是最后一个数据包。这个机制和TCP的拆包重组很像理解起来并不难。2.3 UniPro与M-PHY链路层和物理层的工作逻辑UniPro层在协议栈里很容易被忽略但它恰恰是UFS可靠性的基石。它负责三件大事把上层UPIU做分段和重组、做链路层的流控和确认重传、维护链路状态包括速率协商和休眠唤醒。你可以把UniPro想象成快递公司的干线物流网络。UPIU是装满货的集装箱UniPro负责给集装箱编组、决定走哪条线路、沿途每一站点都要签收确认丢了货要重新发。正因为有这么一层确认重传机制UFS才敢在物理层全速跑而不怕偶发干扰——偶尔一个bit翻转链路层会自动重传上层毫无感知。UniPro层有个叫DMEDevice Management Entity的东西专门负责链路配置管理。比如初始化时双方要协商好速率档位、lane数量这些参数都是通过DME机制配置的。链路建立起来后如果要进低功耗状态也是DME下发指令。M-PHY是物理层定义了电气特性、信号编码、差分传输参数。M-PHY有两种工作模式PWM模式和HS高速模式。PWM模式速率低但功耗小主要用于链路初始化和低速唤醒场景HS模式才是真正传数据的模式HS-G3每条lane约5.8GbpsHS-G4每条lane约11.6Gbps。UFS 3.1设备用两条lane理论总带宽在23.2Gbps左右。这里有一个M-PHY的经典设计逻辑设备上电后链路不会直接冲到HS-G4最高速率而是先用PWM模式建立一个基础通路确认双方都活着、能通信再逐渐往高速档位切换。这个过程叫Link Startup很像两个人先靠对讲机喊话确认身份再切换到光纤专线传数据。调试中遇到的速率上不去问题绝大多数就出在这个逐级换挡过程里。3. 命令机制SCSI命令集与UFS Query的管理通道3.1 为什么UFS选择SCSI命令而不是自己发明一套UFS协议栈的最上层是UCSUFS Command Set说白了就是SCSI命令集。很多人不理解明明是自己设备为什么不搞一套精简命令非要套上古SCSI原因很简单SCSI命令集已经被验证了三四十年覆盖了块存储设备的几乎所有需求——读、写、容量查询、缓存管理、TRIM、电源管理、写保护每一条命令的语义都很明确。UFS直接复用SCSI命令意味着上层操作系统、文件系统、驱动生态都能平滑迁移不需要重新发明轮子。尤其在Linux内核里块设备层本来就是用SCSI命令和底层交互的UFS驱动可以顺理成章地融入SCSI框架。UFS里常用的SCSI命令有这些命令功能对应场景INQUIRY查询设备基本信息识别UFS设备型号、厂商READ CAPACITY读取设备总容量初始化和分区工具READ(10) / READ(16)读取数据正常读操作WRITE(10) / WRITE(16)写入数据正常写操作UNMAP解除逻辑块映射TRIM、删除文件后回收空间SYNCHRONIZE CACHE强制脏数据落盘fsync、系统关机前落盘TEST UNIT READY查询设备是否就绪启动阶段轮询我在实际调试中观察到一个有意思的现象很多人遇到UFS读写失败第一反应是查PHY、查信号但有一类问题是SCSI层返回了Check ConditionSense Key是Write Error。这时候问题可能在NAND坏块管理、设备内部FTL甚至缓存同步策略上。协议栈的好处就在这里每一层都有明确的错误反馈渠道你得学会从上往下逐层看状态。3.2 Query命令描述符、属性、旗标的三级管理机制除了SCSI命令UFS协议还定义了一套独立的管理通道——Query Request / Query Response UPIU。这套机制用来读设备信息、配置设备参数相当于设备的控制面板。Query机制里最重要的三个对象是描述符Descriptor、属性Attribute和旗标Flag。描述符是结构化的数据块相当于设备的简历和体检报告。比如Device Descriptor记录设备厂商、协议版本、支持的lane数Geometry Descriptor记录设备的物理结构信息包括有多少个逻辑单元、WriteBooster缓冲容量多大、每个LUN的块大小Unit Descriptor描述每个逻辑单元的能力和配置包括是否支持写保护、当前写保护状态等。初始化时主机需要读这些描述符来决定怎么配置设备。属性是单值的状态项相当于设备当前的仪表盘读数。常见的有设备当前电源模式Active、Sleep还是DeepSleep、Boot LUN是否使能、WriteBooster缓冲剩余空间等。属性分两种一种只读状态一种可写配置。主机设置某些配置时就是往对应属性里写值。旗标是最简单的布尔量相当于设备的开关状态。比如永久写保护使能标志、上电时写保护标志还有Power On WP等。旗标的值要么是0要么是1语义单一明确适合表达二值化状态。这三类信息都通过Query命令访问对应的操作码有READ DESCRIPTOR、WRITE DESCRIPTOR、READ ATTRIBUTE、WRITE ATTRIBUTE、READ FLAG、SET FLAG、CLEAR FLAG等。实际操作中我建议把这三个对象分开记忆描述符描述设备是谁、有什么能力属性描述设备当前怎么样旗标描述某个开关是否打开。搞清楚这个分类后面看UFS驱动代码时会轻松很多。3.3 命令生命周期读一次数据要过几道关把前面所有机制串起来我们完整走一遍主机读LBA 1000开始的4KB数据这条命令。第一步操作系统块设备层发来读请求UFS Host Controller的驱动把这个请求构造成SCSI READ(10)命令写入控制器的命令队列寄存器。控制器生成一个Command UPIU分配一个空闲的任务标签然后通过UniPro/M-PHY发送给设备。第二步设备收到Command UPIU后解析出SCSI命令把它交给内部的命令处理器。设备内部的FTL根据LBA找到对应的物理页地址开始读NAND。这个过程可能是几个页并行读也可能触发映射表查询耗时取决于NAND介质和FTL优化程度。第三步设备把读出来的4KB数据打包成Data In UPIU返回给主机。如果数据量大于单个UPIU承载能力会被拆成多个Data In UPIU连续发送。第四步数据传完后设备发送Response UPIU携带状态码表示命令执行成功。主机收到Response后释放命令队列深度唤醒等待该命令的进程。如果没有出错应用层就能拿到完整数据了。整个过程里主机和设备的每一次交互都对应一种UPIU类型链路层还会对每个UPIU做确认和潜在重传。我在调试时习惯把一次完整的读操作想象成一次网购下单Command、发货Data In、签收Response中间任何一个环节断了问题都不在生产端而在链路协调上。另外UFS支持命令队列最多32条命令同时挂在设备端执行。也就是说上面的生命周期在设备端是并发的多条读命令可能同时在不同的NAND plane上执行最后按任务标签分别返回。这也是UFS并发性能远好于eMMC的原因但代价是调试时面对的命令交织情况更复杂。4. 初始化流程、调试方法与实战避坑4.1 从设备上电到Ready初始化步骤清单拿到一颗UFS 3.1器件第一次接上主控老老实实走一遍初始化流程比什么都管用。完整的初始化可以分成几个阶段我按实际操作顺序列一下上电RESET信号拉低再释放保证设备完成内部复位M-PHY进行Link Startup双向握手。先以PWM模式低速建立链路然后逐级往更高速度档切换UniPro层通过DME完成链路层配置协商好版本、重传参数、流控窗口大小主机发送第一个UTP命令通常是Test Unit Ready或者直接发Inquiry确认设备已经能响应命令读取Device Descriptor拿到厂商ID、协议版本号、支持的最大速率读取Geometry Descriptor和Unit Descriptor获知设备容量、逻辑单元数量、每单元大小配置电源参数确认设备进入Active模式并可正常收发数据如有需要读Boot LUN或对指定LUN执行写保护配置下发标准SCSI命令集合比如READ CAPACITY、INQUIRY给操作系统用初始化完成。如果是Linux环境ufshcd驱动大体上也是按这个顺序做的只不过驱动代码把很多配置封装到了函数里。我建议初学时就照着这个顺序读spec每个步骤对应到spec哪一章脑子里会清楚很多。伪代码大概是这样power_on_and_release_reset() mphy_link_startup() // PWM G1 - 协商到HS-G4 unipro_dme_configure() // 配置重传、流控、版本 send_utp_command(INQUIRY) // 探测设备响应 device_desc read_device_descriptor() geometry_desc read_geometry_descriptor() for each unit in geometry_desc.units: read_unit_descriptor(unit.lun) configure_power_mode(ACTIVE) notify_block_layer(device_ready)4.2 踩坑复盘UFS速率协商失败时的排查思路我调试UFS 3.1时遇到最多的问题就是设备识别不稳定或者速率只能跑在低速档。这种现象最开始很让人头疼因为链路层报错并不直接告诉你是哪根线的问题。复盘一次典型的排查过程按这个顺序能少走弯路。第一个场景上电后设备完全响应但链路一直停在PWM模式协商到HS模式失败。我先用示波器抓REF_CLK和M-PHY数据线的差分信号。看波形后发现REF_CLK幅度偏小查硬件文档才意识到该平台的参考时钟触发条件比较严格PCB走线过长导致信号衰减。这时候问题在硬件软件怎么调都不行。第二个场景低速正常高速档位偶尔成功偶尔失败出现时而飞起、时而龟速。用寄存器看M-PHY的PCS错误计数发现Error Counter在HS-G4切换时剧增。这不是信号质量问题而是UniPro协议层配置的流控窗口和设备端能力不匹配。把DME里协商的接收能力参数改成设备端报告的数值后问题消失。软件层一个配置项影响链路稳定性不看spec根本想不到。第三个场景系统休眠唤醒后设备命令超时。排查确认设备进了DeepSleep唤醒路径上主机没有先把链路重新Link Startup导致第一批命令发到了还没醒过来的设备。解决办法是在唤醒流程里先做链路重训练再发命令。这属于电源状态机设计问题时序图里看着简单真实现调起来最费时间。我把这些问题的排查方式总结成一个表现象优先确认可能根因处理方向链路完全起不来电源、复位、REF_CLK波形硬件信号问题示波器量波形调整走线或驱动强度低速正常高速不稳定M-PHY错误计数、UniPro重传统计信号质量或流控配置不匹配检查PCB阻抗核对DME协商参数唤醒后命令超时设备电源模式、唤醒时序链路未重训练补Link Startup流程调整休眠策略读写命令报Check ConditionUTP错误寄存器、Sense Key设备内部FTL或坏块问题用厂商调试工具读NAND状态调试UFS我的体会是一定不要只看一个层次的表象。物理层问题会表现为协议层超时协议层配置问题会表现为链路频繁重建链路异常又会表现为上层命令排队堵塞。逐层排查、逐层确认是唯一可靠的方式。4.3 WriteBooster与DeepSleep必须知道的几个细节WriteBooster是这个时代手机存储性能的关键但很多人理解有偏差。首先它并不是默认开启的功能。设备端必须有WriteBooster Buffer LUN主机要通过属性查询确认支持状态还需要正确配置写入策略。其次WriteBooster的收益集中在随机写入和突发写入顺序大文件写入如果缓冲区很快填满性能会大幅回落。实测表现就是跑分软件连续写几个G前面数据非常好看后面突然掉到TLC直写水平。厂商宣传的写入速度翻倍严格说是峰值写入速度翻倍。如果你在做存储性能测试要留意WriteBooster的buffer耗尽行为和搬移策略。设备在空闲时会自动把Buffer里的有效数据搬移到TLC区域腾出空间给后续写入。这个搬移过程会占用设备内部带宽如果此时你发起下一轮测试可能观测到延迟抖动。做自动化测试的时候最好在每轮写入后留足够空闲时间让设备完成搬移再测下一轮不然数据很难复现。DeepSleep的坑主要在唤醒路径。设备进入DeepSleep后主机和它之间的链路实际上已经断开所有队列里的命令都会超时。所以正确的休眠流程应该是主机先确保所有命令完成、数据落盘然后通知设备进入DeepSleep最后再让平台进入低功耗状态。唤醒时主机要先重新建立链路做Link Startup等设备确认退出DeepSleep才能恢复IO。顺序反了轻则唤醒慢重则数据损坏。移动平台上的睡眠调试用逻辑分析仪抓唤醒时序是最直观的。4.4 学UFS 3.1推荐看哪些文档、用什么工具最后聊一下学习工具。UFS 3.1协议本身由JEDEC发布核心规范是JESD220E主机控制器接口规范是JESD223EMIPI联盟定义了M-PHY和UniPro。这几份文档加起来确实吓人但不需要从头读到尾。我的建议是先从JESD223E开始搞懂Host Controller一侧接口的作用再读JESD220E里的UTP章节和Query命令部分最后回来看M-PHY和UniPro的链路机制。顺序很重要先宏观再微观不然很容易陷在某个字段细节里出不来。工具方面有条件的话最好准备以下三样逻辑分析仪或示波器看M-PHY的差分信号、Link Startup时序支持UFS协议解码的协议分析仪不少厂商仿真器带这个功能能直接看到UPIU内容、重传统计和命令失败原因UFS设备厂商的调试工具读取设备内部FTL状态、NAND错误计数、WriteBooster搬迁进度这些信息在标准协议层完全暴露不出来。如果你在Linux环境调试ufshcd驱动本身是个很好的教材。它的OPS结构体、UPIU收发路径、错误处理函数注释都写得比较清楚配合内核的tracepoint可以观测每条命令的生命周期。手边没有实际硬件的话用QEMU跑Linux内核观察UFS驱动的模拟初始化流程也能建立基本概念比裸看spec要快得多。我在实际项目里还有一个习惯把每一类UPIU的收发点在内核代码里打trace标记然后把业务流程和spec对照着看。很多协议细节比如到底是Command UPIU先到还是Link Startup先完成只看文档容易迷糊在真实trace里一眼就能看出来。建议你也试试这个方法。最后说回学习心态。UFS 3.1的难度不在某个具体命令而在多层协作这件事本身。我的经验是第一次接触时别追求背下所有字段先跑通一次最简单的读操作把每一层发生什么串成一条线再回头查细节。这样比从头死磕规范效率高很多。后面有时间我再整理UFS 4.0和MIPI底层链路的笔记到时候继续分享。