企业官网建设流程全解析

UFS3.1这三个字一出来，搞存储、搞手机BSP、搞嵌入式固件的朋友应该都懂：这是目前移动端性能最顶的通用闪存协议之一。我前阵子刚好啃完JEDEC的UFS 3.1规范，又对照着抓了几轮实际链路波形，今天就把这堆协议内容掰开揉碎捋一遍。这篇文章不按Spec从头翻译，而是以“工程师读协议、用协议、调协议”的视角走一遍UFS3.1的分层架构、新增特性、命令交互和排查方法，希望给正在做驱动、固件、测试的朋友一点实际参考。

先说清楚UFS3.1解决什么问题：过去手机存储看eMMC，但eMMC是8位并行半双工，带宽上不去、指令队列也浅。UFS走串行差分、双lane全双工，还能多命令排队，性能完全不是一代东西。UFS3.1作为3.0的小幅升级，主要加了Write Booster、DeepSleep、Perf Throttling Notification、Host Performance Booster这些机制，把写性能、待机功耗、热管理和随机读这四块短板补了一截。所以做旗舰机存储选型、做SSD控制器、做UFS Host控制器，或者只是好奇手机存储为什么“跑分那么快”，都值得把UFS3.1协议这条线理清楚。

1. 整体架构：UFS3.1协议到底在讲什么

1.1 UFS演进逻辑：从eMMC到UFS3.1

UFS的全称是Universal Flash Storage，JEDEC标准，从UFS 1.0开始就在对标eMMC。eMMC本质还是NAND加一个控制器，复用MMC并行接口，数据线8根，读写不能同时进行。早期够用，但到4K视频、连拍、大型游戏加载这种场景，eMMC的瓶颈非常明显：带宽上不去，队列深度低，多任务下I/O调度滞后。

UFS把存储接口做成了类似SATA/NVMe的串行差分架构。物理层用MIPI M-PHY，链路层用MIPI UniPro，双lane全双工，数据和命令可以双向同时跑。UFS 2.1时代是HS-G3,单lane大概5.8Gbps左右，双lane也就是11.6Gbps上下。UFS3.0换到M-PHY HS-G4，单lane理论速率拉到11.6Gbps，双lane合计23.2Gbps，对比UFS 2.1翻了将近一倍。UFS3.1基本沿用了这套物理层，没有继续飙速率，而是回到“怎么把体验做好”的老问题上。

所以别把UFS3.1当成一次大版本革命，它更像一次“把3.0的潜力真正释放”的完善版。你在手机参数页看到的“UFS 3.1”，很大程度卖点其实是Write Booster带来的顺序写提升，以及DeepSleep带来的待机功耗下降。

1.2 协议栈与层次：为什么分这么多层

UFS协议栈可以看成四层：最上面是UFS应用层（Application Layer），实际上基于SCSI命令集；往下是UFS传输层（UTP），负责把命令封装成UPIU（UFS Protocol Information Unit）；再往下是MIPI UniPro链路协议；最底下一层是MIPI M-PHY物理层。

打个比方：应用层决定“我要写什么”，UTP决定“这句话怎么填进信封”，UniPro决定“信封走哪条路、怎么确认不丢”，M-PHY决定“路上信号电压多高、速率多快”。分层的好处是各层独立演进：M-PHY从G1升到G4，UniPro基本不用大改；UTP要加新命令，也不会动物理层。

这里面最容易混淆的是UniPro和UTP的边界。实际抓链路时你会看到，主机软件把命令组成一个UPIU，交给UniPro的Transport Layer（TL）拆分，再到Data Link Layer加校验和流控，最后到PHY Adapter（PA）把数据变成M-PHY支持的格式发出。所以面对一个UFS trace，我建议先分层看：先看物理层Gear协商到几速，再看UniPro有没有重传或流控等待，最后才去解析UPIU内容。很多人一上来就死盯UPIU字段，反而忽略了低层链路抖动才是性能劣化的根源。

1.3 与eMMC、NVMe的横向对比

做选型时经常被问UFS和NVMe哪个强。简单对比：

• 接口形态：eMMC是并行MMC，UFS和NVMe都是串行差分。
• 全双工：eMMC半双工，UFS双lane全双工，NVMe全双工多队列。
• 队列能力：eMMC只支持一个未完成命令（基本序列化）；UFS支持多命令排队，典型队列深度32；NVMe队列深度可以做到65535。
• 带宽：UFS3.1双lane 23.2Gbps理论带宽，NVMe x4 Gen3大概是32Gbps，x4 Gen4翻到64Gbps。
• 场景侧重：UFS面向嵌入式、手机、平板、车载，强调低功耗和小封装；NVMe面向PC、服务器、企业级，性能上限高，但功耗和控制器成本也高。

在实际硬件里，UFS和NVMe不是替代关系，而是各自覆盖场景。UFS3.1的优势在于它在手机这个功耗极度敏感的环境里做到了“够用的带宽+可控的功耗”，这一点NVMe很难直接搬过来。UFS3.1协议也正是围绕这一点铺开的。

2. UFS3.1相对3.0的新特性拆解（工程视角）

2.1 Write Booster：SLC缓存与主区的协同策略

Write Booster是UFS3.1最被厂商拿来宣传的特性，但协议层面的定义其实很朴素：允许NAND里划出一块区域，比如SLC模式运行的buffer，主机突发写时先写进这个高速缓冲，再由设备内部把数据搬移到TLC/QLC主区。用内置的“脏数据迁移”换主机写命令的低延迟。

协议上设备通过Descriptor向主机暴露Write Booster能力，比如bWriteBoosterBufferType用来区分缓冲类型，dWBBufferSize描述缓冲容量，还有个Write Booster生命周期相关的属性dWBLifeTimeEst。主机侧需要把fWriteBoosterEnable这个Flag置1，Write Booster才算真正进入可用状态。注意，不是所有UFS3.1设备默认就开了这个Flag，很多产品出厂固件里默认是关的，靠系统侧设置打开。

实际工程里最容易被坑的是“Write Booster不生效”。我排查过几次，最后都落在几个地方：一是Flag没置位；二是缓冲被写满了又碰上大量随机写，设备开始频繁搬移脏块，性能反而不稳定；三是厂商固件对dWBBufferSize的初始值设置异常，主机查询时认为容量为0。所以调优时不要只看跑分软件的数字，先用协议工具查询Write Booster相关描述符，确认缓冲类型和容量数值是符合预期的。

2.2 DeepSleep模式：功耗控制的最后一公里

UFS3.1里新增DeepSleep电源状态，比UFS2.x时代就有的Sleep更深一层。DeepSleep下，设备可以关闭NAND主供电VCC，只保留VCCQ和VCCQ2来维持控制器上下文。这样待机电流能压得很低，代价是唤醒时间比普通Sleep长不少，可能到毫秒甚至更长的量级。所以手机系统侧不会动不动就让UFS进DeepSleep，一般都是屏幕灭掉、系统进入“深度挂起”时才触发。

进入和退出电源模式不是主机随便说一句就行。典型流程是主机通过SCSI START STOP UNIT命令携带电源条件参数，让设备从Active切到Sleep或DeepSleep；唤醒时主机重新激活链路或发送特定唤醒命令。这里有个工程要点：链路在低功耗状态下可能已经停掉，主机切模式前要把UniPro的状态机管理好，否则会出现“设备睡着了，主机还握着总线不放”的诡异挂死。

2.3 Performance Throttling Notification：把温度状态交还给系统

移动设备里热量是性能的头号杀手。以前UFS设备过热时只能自己默默降速，主机并不知道发生过什么，用户只感觉“手机越用越卡”。UFS3.1定义了一个机制：设备通过bPerformanceThrottlingReason这个Attribute向主机报告当前是否因为热管理或功耗限制发生了性能抑制。

主机侧读到Throttling信息后，可以动态调整负载策略。比如后台App大量写入时，如果设备已经由于过热降速，系统可以把一部分I/O延后，避免设备在高温下反复擦写造成寿命损耗。这个特性在车载、8K录制这种高负载持续场景特别有意义。做固件的时候，一定要保证这个Attribute被正确更新并清零，否则主机可能永远认为设备在降速，导致性能策略过于保守，白白浪费硬件能力。

2.4 Host Performance Booster：主机侧缓存物理地址映射

随机读性能在手机体验里非常关键，而NAND随机读的痛点之一是要查逻辑地址到物理地址的映射表。传统方案里，映射表要么放在设备内部RAM，要么需要额外读NAND。UFS3.1的Host Performance Booster（HPB）思路是：把部分映射信息发给主机端缓存，主机发起读命令时可以直接带上物理地址提示，设备省掉一次映射表查找，随机读延迟明显下降。

HPB使能需要主机和设备两端配合：设备提供HPB相关能力描述，主机用专用命令获取映射条目并维护一个小缓存。实际落地中，HPB对随机读的提升可观，但会占用主机侧内存和控制器额外逻辑。做产品时需要权衡：内存便宜的旗舰机上，HPB收益明显；内存紧张的中低端机，可能开了反而得不偿失。

3. 命令与协议核心：UPIU、CDB、Query/Task

3.1 UPIU格式与类型

UTP层做的事情就是把命令、数据、状态封装成UPIU。UPIU头部有传输类型（Transaction Type）、LUN、任务标签（Task Tag）等关键信息。Task Tag是排查超时问题时第一个要盯的字段，它代表一条命令在队列里的唯一标识，设备返回Response时也要带同一个Tag。

常见UPIU类型包括：

• NOP OUT（0x00）/ NOP IN（0x20）：链路保活、空操作。
• Command UPIU（0x01）：主机发命令，携带CDB。
• Data Out UPIU（0x02）：主机向设备写数据。
• RTT UPIU（0x03）：设备通知主机“准备好收数据了”。
• Data In UPIU（0x22）：设备向主机返回读数据。
• Response UPIU（0x21）：设备返回命令状态。
• Query Request UPIU（0x06）/ Query Response UPIU（0x26）：设备管理类交互。
• Task Management Request UPIU（0x04）/ Response UPIU（0x24）：任务管理。

看到RTT UPIU不要懵，它是UFS协议流控的一环。设备端缓冲有限，主机不能一股脑把数据塞过去，必须等设备发RTT，然后按设备允许的包大小发送。RTT里有个字段表示本包可接收数据长度，调试时如果发现写性能差，可以看看是不是RTT频繁出现且每包长度很小，这往往说明设备端缓冲配置有问题。

3.2 CDB命令集：SCSI命令怎么搬到UFS上

UFS的UFS Command Set其实就是从SCSI命令集裁剪来的。所以你会发现UFS设备能响应不少SCSI时代的传统命令，比如：

• READ(10)、WRITE(10)：带逻辑块地址和传输长度。
• UNMAP：用于裁剪空间，释放逻辑块地址映射，类似SSD里的TRIM。
• SYNCHRONIZE CACHE(10)：刷写缓存。
• TEST UNIT READY：查询设备是否就绪，上电轮询常用。
• START STOP UNIT：控制设备电源状态或启停介质，睡眠模式经常走它。

解析CDB时最实用的技能是手动算逻辑区块。READ(10)的CDB里，8字节的逻辑块地址分布在特定Byte位段，2字节传输长度表示扇区数。很多驱动问题都是LBA算错、长度字段超范围导致的写坏数据，这种问题看协议trace拉出来一查就能定位。

3.3 Query Request机制：设备管理不走寻常路

命令传输走CDB，但设备自身的“体检和设置”走的是另一套交互，就是Query机制。Query把管理对象分成三类：Descriptor（描述符）、Attribute（属性）、Flag（标志）。

• Descriptor：描述设备整体能力，比如设备描述符、配置描述符、几何参数描述符。读串号、查容量、查Write Booster缓冲信息都在这里。
• Attribute：运行时的状态值或参数，比如当前温度、剩余寿命、bPerformanceThrottlingReason。
• Flag：布尔开关，比如fDeviceInit、fWriteBoosterEnable、fPowerOnWPEn（写保护）。

Query Request里有个“操作类型”字段，常见有Read Descriptor、Write Descriptor、Read Attribute、Write Attribute、Read Flag、Set Flag、Clear Flag、Toggle Flag。做驱动的人应该把Descriptor/Attribute/Flag三者的区别刻在脑子里，不然经常搞混：想读能力去读Descriptor，想看运行状态读Attribute，想开个开关动Flag。三者数据格式和缓存语义都不同，用错了设备会返回错误甚至卡住。

3.4 Task Management Request：异常恢复的出口

命令挂在队列里迟迟不结束怎么办？UFS提供了任务管理机制，类似软件里的异常恢复通道。Task Management Request UPIU可以携带Abort Task、Abort Task Set、Logical Unit Reset等操作。当某条命令超时，Host侧先发Abort Task取消它；如果整个LUN状态混乱，可以进一步做Logical Unit Reset，把队列清干净。

实际调驱动时，命令超时第一反应不要直接复位设备。先发Task Management Request把超时命令Abort掉，再抓链路看设备有没有回Response，确认是设备端卡死还是命令参数写错。直接复位虽然省事，但会丢失现场，后面排查原因基本靠猜。

4. 链路与物理层认知：UniPro与M-PHY的配合

4.1 M-PHY工作模式与速率档位

M-PHY分成PWM模式和HS模式两大类，每一类又分多档Gear。PWM模式省电但速率低，HS模式速率高但功耗大。UFS3.1在HS模式下支持到HS-G4，双lane合计23.2Gbps的理论带宽。链路建立后，可以由UniPro的PA层协商具体使用哪个Gear和哪个Power Mode。

协议分析仪里看M-PHY，主要看几个指标：当前Gear、lane数、PWM还是HS。性能不达标最先确认的就是链路有没有跑到预期档位，比如设备明明支持HS-G4，结果协商成HS-G2或者掉到PWM模式，跑分基本腰斩。这种降档一般跟PCB走线长度、信号完整性、固件配置都有关系。

4.2 UniPro的Link Startup与参数协商

UniPro链路建立分几个阶段：先是物理层的对端检测，然后PA层做配置，再是数据链路层建立，最后进入Active状态。这个过程通常由设备端自动完成，但参数协商结果决定了后续所有传输速率。工程师能看到的往往是UniPro的DME（Device Management Entity）命令，通过DME_SET/DME_GET可以读写PA层、DL层的属性。

常见调试点有：把PA_Gear从G1逐步往上抬，观察链路是否稳定；检查lane数量是否协商到2；确认Power Mode是不是HS。在开发板上做压力测试时，如果高频出现链路重协商或者UniPro层重传，不要猜是软件问题，先去看信号质量和板级阻抗，这层问题往往潜伏很深。

4.3 流控机制：RTT与DFC

UFS链路有高低两级流控：低层UniPro数据链路层有自己的基于信用token的流控机制DFC，高层的UPIU交换里还有RTT这套流控。底层DFC保证UniPro帧不把对端缓冲撑爆；高层RTT保证数据UPIU不会比设备预期来得快。

调试时可以分情况看：如果是设备返回RTT正常但数据迟迟发不出去，问题一般在主机侧的DMA或队列调度；如果RTT本身响应很慢，则要去看设备固件是不是忙于内部搬移或垃圾回收。记住一个经验：写性能差，大量时间看RTT节奏和数据包间隔；读性能差，除了看Data In包间隔，还要看有没有大量UniPro重传。

5. 实操记录：从Trace看UFS3.1协议交互

5.1 抓取链路trace前的准备工作

我实际调试UFS3.1时用的比较多的是协议分析仪加逻辑分析仪的组合。协议分析仪能直接解析UPIU和UniPro层信息，逻辑分析仪则用来量M-PHY时序。市面上能支持UFS3.1的分析工具以Lauterbach、Teledyne LeCroy、Keysight这类为主，价格不便宜；如果没有专业设备，也可以用支持高速差分的逻辑分析仪凑合抓，但解不出UPIU语义，需要自己按协议位域手动解析，效率低。

抓trace前要说清楚触发条件。如果目标是定位写性能问题，触发条件可以设为“Command UPIU出现且LUN等于目标LUN”；如果目标是查链路降速，触发点应该放在“PA参数协商完成之后第一个Data UPIU”。触发条件设不好，抓半天全是不相关的空闲包，白干。

5.2 一条WRITE命令的trace逐段解读

我们看点实际的交互顺序。主机发一条写命令，trace里会依次出现：

1. Command UPIU：传输类型0x01，携带CDB，CDB里是WRITE(10)，LBA=1000，长度=32个扇区。
2. 设备回RTT UPIU：类型0x03，表示设备缓冲已准备好，里面有可接收长度。
3. 主机发Data Out UPIU：类型0x02，携带32个扇区的数据。
4. 设备回Response UPIU：类型0x21，状态Good。

看这条trace时要确认几个点：Task Tag在四个UPIU里保持一致，代表同一个命令；Data Out UPIU的LBA和长度跟CDB一致；Response里的Sense Data为空，Status为0（Good）。任何一环对不上，都是排查入口。我见过最离谱的一次是主机发的Data Out数据长度写错，设备卡在等剩余数据，主机侧却以为命令已经完成，最后靠trace把长度字段抓出来才定位到是驱动DMA配置算错了字节数。

5.3 链路速率协商的trace特征

链路启动阶段观察UniPro的PHY Adapter配置，能直接看到Gear协商痕迹。比如最开始是低速PWM模式完成握手，然后逐步切到HS模式，再往上升到HS-G4。如果设备能力支持G4但链路只停在G2，trace里PA协商的命令值和实际工作档位就会暴露问题。查看时重点盯PA_ActiveTxDataRate之类的属性值，以及最终进入Active状态时配置的Gear和Lane数。

5.4 一个异常案例：读命令超时

有次遇到主机发了一条READ(10)，trace里只有Command UPIU，设备一直没有任何Response。排查时先确认设备有没有先低层应答，也就是UniPro层有没有ACK。如果低层ACK有但高层Response没有，基本判定设备固件在处理命令时卡住，比如在等某个内部资源；如果低层都反复重传，那就是链路不稳，物理层问题优先级更高。那次果不其然，设备固件在处理读命令时正好撞上垃圾回收，加一个内部忙信号量处理，问题就没了。所以别把每种超时都归为“设备坏了”，先分层定位。

6. 常见问题与排查经验

6.1 问题速查表

6.2 写性能突然下降排查：Write Booster是否还生效

设备用久了写性能下降是常态。第一反应不是骂厂商，而是先读dWBLifeTimeEst看看Write Booster缓冲的寿命消耗，再确认fWriteBoosterEnable是不是被固件复位了。如果缓冲容量显示为0，说明设备已经把缓冲区转为正常使用或者固件没初始化好。这种情况下重刷固件往往能恢复，但也说明原固件对Write Booster生命周期的管理存在缺陷，要反馈给固件团队细化。

6.3 唤醒时间长、命令超时的组合排查

设备从DeepSleep唤醒时，主机不能立即发命令，要先等链路重新Active。我遇到过一种组合故障：主机发了唤醒命令后立刻发I/O，结果I/O全部超时。trace显示链路还在重新协商Gear，数据命令已经挤上来了。解决方法是驱动里严格按状态机等待唤醒完成事件，再放开命令队列。这个坑在手机息屏亮屏、车载系统深休眠唤醒场景特别常见。

6.4 如何搭建最小UFS调试环境

我建议入门UFS3.1协议准备三样东西：

• 一个带UFS接口的开发板或量产手机，最好是能解除锁bootloader的，方便改驱动和抓trace。
• 一个支持高速差分采集的逻辑分析仪或协议分析仪，预算不够那就用开发板自带的调试口加软件trace。
• 一份JEDEC正式文档：UFS主规范看JESD220系列（UFS3.1对应更新版），主机控制器接口看JESD223系列。如果嫌PDF厚，可以先从UPIU类型和CDB命令集两章下手，再补UniPro。

实践中还有一个省力窍门：先用协议分析仪自带的示例trace把正常读写、睡眠唤醒、链路训练这些典型场景的“标准波形”看熟，以后遇到问题只需要对比差异。很多疑难杂症，其实都是“和正常的波形有一个细微的字段不一样”。

7. 学习与调试的几点体会

啃UFS3.1协议和调UFS3.1链路是两件事。规范写得高度抽象，真正卡你的往往是物理层信号和固件行为，而不是UPIU里那几个字段。我个人的经验是：先把UPIU类型、CDB操作码、Query机制这三块吃死，这是所有排查的基础；至于M-PHY和UniPro，够用就好，遇到链路降速问题再深挖信号完整性。

最后分享一个小技巧：调UFS3.1时养成“看trace先看时间戳”的习惯。很多性能问题不是不对，而是慢。比如Response UPIU和Command UPIU之间的时间差一下子变大，可能设备在忙GC，也可能是温度策略触发。把时间戳、温度、RTT节奏三者放一起看，往往比单看某个协议字段更快锁定根因。UFS协议本身不会告诉你设备内部正在忙什么，但协议交互的节奏会把一切蛛丝马迹都暴露出来。