UFS3.1协议详解：传输层UPIU报文格式与调试实战

UFS3.1协议中文学习讲解（8~9）里说的“8~9”，指的是UFS协议栈里真正“跑业务”的两块内容：传输协议（UTP）和协议信息单元（UPIU）。简单说，不管上层发的是读命令还是写命令，是查询设备信息还是后台垃圾回收，最终都要按这章的规则打成固定格式的报文，再交给MIPI物理层发出去。做UFS驱动的人、调UFS控制器固件的人、抓UFS Trace排查问题的人，基本每天都要跟它打交道。

我大概从2019年开始接触UFS3.0/3.1的协议验证，前后踩过不少坑。这篇就把第8~9章讲清楚：先讲传输层是干嘛的，再把九种UPIU报文依次拆开，最后结合UFSHCI主控寄存器和实际调试经验，说说一次命令怎么从软件发到设备、以及出了问题怎么排查。内容偏协议底层，但我会用快递寄件这种生活化的例子做类比，尽量让刚入门的朋友也能顺畅读下来。

1. 8~9章到底是什么：传输层与报文格式

1.1 协议栈里的位置

先看整个UFS协议栈的简化结构：

• 最上层：命令集。UFS复用SCSI命令，读、写、容量查询、安全擦除等，都通过SCSI CDB来表达。
• 中间层：UFS传输协议（UTP）。它负责把SCSI命令、数据、状态、管理请求都封装成固定格式的报文，并管理命令的执行、传输和完成。
• 链路层：MIPI UniPro。负责把报文分帧、保证可靠传输、处理流控和链路错误。
• 物理层：MIPI M-PHY。负责差分信号传输、Gear速率、PWM/HS模式。

我经常把UTP比喻成“快递公司的分拣传送带”：SCSI CDB是你要寄的一张单子，UPIU是按快递公司规定包好的包裹，UniPro则是物流干线，M-PHY就是那辆跑在路上的大卡车。

第8~9章就是围绕中间这一层展开的。用规范的结构来看，它主要包含两块：一是传输协议总则，描述传输事务、标签、端口等基本规则；二是UPIU的具体定义，把每一种报文类型、每个字段含义、每个标志位怎么置1都规定清楚。

1.2 为什么这两章是调试重点

很多刚接触UFS的人会先去看命令集，因为读写命令好理解。但真到调驱动、定位问题的时候，你面对的往往是：发了一个命令，超时了；设备回了响应，状态码不对；数据长度对不上；任务管理卡住，设备不响应中止请求。这些问题的判断依据，全部在第8~9章里。

举一个真实工程场景：主机下发一条读命令，数据方向标记为读，设备端回了一个响应UPIU，状态却是“检查条件”。这时候你得去查响应UPIU里的SENSE KEY和ASC/ASCQ。如果不懂UPIU结构，光看寄存器根本不知道发生了什么。反过来，如果熟悉UPIU，一条逻辑分析仪抓下来的报文几秒钟就能定位问题方向。

另一个常见场景就是任务管理。设备卡死、命令超时后，主机需要发“逻辑单元重置”或“中止任务”。这个请求本身也是一个UPIU，叫任务管理请求UPIU。它的格式、功能码、目标寻址方式，都是第9章的内容。

1.3 适合什么人重点读

如果你是下面这几类人，第8~9章值得反复看：

• 写UFS主机控制器驱动的嵌入式工程师，需要掌握UTRD结构和门铃寄存器交互。
• 做UFS设备端固件或协议验证的工程师，需要知道设备侧怎么解析命令UPIU、怎么回响应UPIU。
• 使用协议分析仪或逻辑分析仪抓UFS报文的人，读不懂报文格式就无法分析问题。
• 想系统学习UFS协议、后面再跟UniPro和M-PHY的初学者。

我可以直说：UFS3.1新增的WriteBooster、HPB、ZRL这些功能，学到最后都会落到第8~9章涉及的命令和查询UPIU上。所以把这一块基础打牢，后面看任何UFS3.1特性都不会卡壳。

2. UTP传输层的设计思路：把复杂业务塞进标准化报文

2.1 事务、端口和标签

UTP层最大的贡献是定义了一套“传输事务”的机制。一次命令交互，从主机发出命令UPIU开始，到收到响应UPIU结束，叫做一个事务。事务可以有数据阶段，也可以没有。

这里面有几个核心术语：

• 事务（Transaction）：主机和设备之间一次完整的请求/响应过程。
• 端口（Port）：UFS设备内部可以并行处理多个命令，端口是逻辑上的并发执行通道。
• 任务标签（Task Tag）：每个命令UPIU里都有一个8位任务标签。主机内部维护这个标签，设备处理完命令后，响应UPIU里要带上同一个标签，这样主机才知道是谁的命令完成了。
• 连接ID（CID）：UTP层在UniPro链路上建立连接时使用的标识，用于管理层面上多路复用。

打个比方：你在不同电商平台同时买了三件东西，包裹上有订单号，快递员敲门时你不会管你是谁，先看订单号对不对。命令UPIU就相当于那个订单号，响应UPIU相当于签收单，上面的标签必须和订单号一致，才敢确认是哪个订单的快递。

设备内每个LUN的队列深度、每个并发事务能占用的资源，虽然不是第8章的核心定义点，但会直接影响你读后续的UFSHCI规范和属性配置。比如说设备支持多少个队列槽位，跟门铃寄存器的bit位是绑定的。

2.2 UPIU：唯一的“包裹”格式

UTP层定义了多种UPIU类型，它们的共同特点是有统一的头部格式，头部的前几个字节决定了这个包裹要干什么。设备端从UniPro层拿到一段数据后，第一件事就是读头部的“事务类型”字段，判断接下来要按照哪种报文结构去解析。

这种设计思想和TCP/IP协议很像：先有固定长度的头部，头部里有类型和长度信息，再根据类型去解析包体的内容。你在看UFS Trace时，第一步也是先看事务类型是0x01还是0x06，再决定要不要进一步解析后面的CDB或任务管理功能码。

UPIU这层，是主机控制器和设备唯一共同认可的“语言”。MIPI M-PHY只管把比特流从一个点送到另一个点，UniPro只管这段数据是不是完整到达，但数据本身是什么含义，只有UPIU层知道。所以很多UFS协议分析工具，本质上就是一个“UPIU翻译器”。

2.3 从“寄快递”理解九种UPIU

我把九种常见的UPIU用快递场景类比一下，这一节会比较直观：

• 命令UPIU（0x01）：包裹面单。上面写清楚收件人、物品名称、数量。
• 就绪传输UPIU（0x03）：快递员通知你“可以来寄货了”。
• 数据IN UPIU（0x04）：给你派送的包，里面是你要的数据。
• 数据OUT UPIU（0x05）：你寄出去的包，里面是你要写的数据。
• 响应UPIU（0x02）：签收回执。告诉你这个包裹已经处理完毕。
• 任务管理请求UPIU（0x06）：人工客服的工单。比如“你的包裹丢了，取消”“强制退回”。
• 任务管理响应UPIU（0x07）：客服处理完工单后的反馈。
• 查询请求UPIU（0x08）与查询响应UPIU（0x09）：相当于是专门的“系统后台操作”，不针对某个快递包裹，而是查档案、改配置、触发后台任务。

本质上，UFS的UPIU就是围绕“发命令、传数据、回状态、做管理、查属性”这五件事设计的。理解了这五个维度，整个第8~9章就串起来了。

3. 九种UPIU逐类拆解：字段、标志位与用途

3.1 头部结构：所有报文共享的“身份证”

所有UPIU都以12字节头部开始（不同版本可能有细微差异）。核心字段如下：

• 事务类型（Transaction Type）：占头部第一字节的低四位。0x01命令、0x02响应、0x03就绪传输、0x04数据IN、0x05数据OUT、0x06任务管理请求、0x07任务管理响应、0x08查询请求、0x09查询响应。
• 标志字段：一个字节，按位表意。对命令UPIU来说，里面关键的位包括命令标志、数据方向、读/写方向等。设备端靠这些位判断这个命令有没有数据阶段、数据是进还是出。
• LUN与启动器ID：一个字节中既有逻辑单元号的高位/低位，也有启动器ID。UFS是点对点连接，启动器ID在大多数场景下就是主机侧0或1，但多主机架构时会有作用。
• 任务标签：一个8位标签，命令和响应必须一致。

头部之外，不同类型的UPIU有不同的附加字段。比如命令UPIU后面要带CDB，响应UPIU后面要带状态码和感知数据，数据UPIU后面要带数据块，这些都需要按类型往下解。

在实际解析时，我的习惯是先把事务类型字段提取出来，再根据类型跳转到对应的解析逻辑。这个思路也适合写上位机解析脚本，或者用逻辑分析仪的协议插件做二次开发。

3.2 命令UPIU：业务入口

命令UPIU从功能上讲，就是“把一条SCSI命令原封不动塞进UFS报文”。它内部有一个16字节的CDB区域。UFS3.1里的READ(10)、WRITE(10)、READ(16)、WRITE(16)等命令，都是通过CDB里的操作码来区分。

命令UPIU还包含预期数据传输长度（EDTL）字段，设备可以根据这个字段提前知道接下来要收/发多少数据。这个字段对校验很重要：如果数据UPIU里的实际数据和命令UPIU声明的数据量不一致，设备端就会报错退出，响应UPIU里会带上相应的状态。

还要注意，命令UPIU的某些标志位决定是否有数据阶段。比如读命令，标志位置“数据IN”，数据阶段跟在命令之后；写命令，标志位置“数据OUT”，设备先回一个就绪传输UPIU，再开始接收数据。

这块有个容易理解错的地方：写命令并不是主机直接一股脑把数据发过去，而是要先等设备发“就绪传输UPIU”来确认可以接收。设备处于忙状态或内部缓冲区不够时，不会发就绪，主机就必须等待。

3.3 响应UPIU：业务回执

响应UPIU是设备处理完命令后回给主机的报文。核心字段：

• 状态字段：最常见的值是“成功”（00h）。如果出现“检查条件”（02h），说明命令执行失败，需要进一步看感知数据。
• 感知数据区域：包含SENSE KEY、附加感知码（ASC）、附加感知码限定词（ASCQ）。很多驱动调试，最终都是落在这三个值上。
• 残余数据长度：设备计算出实际传输的数据量和预期值的差。这个字段对排查“数据量不对”的问题非常关键。
• 任务标签：和命令UPIU保持一致的8位标签。

我在项目里见过不少“发生率极低”的偶发超时问题，最后抓包发现是响应UPIU里返回了残余数据长度非0。上层驱动如果没有处理这个字段，就会出现“命令完成但buffer内容少了一截”的暧昧状态。

3.4 数据IN/OUT UPIU：真正的搬运工

数据UPIU负责传实际数据内容。数据IN是设备到主机方向，数据OUT是主机到设备方向。结构中包含：

• 数据长度：本次UPIU携带的数据字节数。
• 数据块：紧跟头部的一整块连续数据。
• EOF标志、数据范围等辅助信息。

调试时要注意：一次大数据传输可能被拆成多个数据UPIU分多次传递。设备侧或主机侧在接收端需要按数据偏移拼接。有些分析工具会把偏移和长度显示得很清楚，但自己看原始报文时要留意“分段序号”和“总长度”的关系，防止把同一块地址的数据当成重复数据。

UFS3.1里关于数据UPIU还有一个细节：部分命令支持将数据和命令UPIU合并，减少交互次数。这也是优化小数据块传输的关键思路。读懂数据UPIU格式后，再看这些合并特性会容易很多。

3.5 就绪传输UPIU：写数据的“绿灯信号”

就绪传输UPIU很特殊，它本身不携带业务数据，只是一个通知。设备准备好接收数据OUT了，才发这个报文。它的存在使得写命令变成“双向握手”：

1. 主机发出写命令UPIU。
2. 设备处理到可以收数据的阶段，回就绪传输UPIU。
3. 主机看到就绪传输UPIU后，开始发数据OUT UPIU。

如果你用协议分析仪抓写卡过程，看不到就绪传输UPIU就看不到后续数据，大概率是设备内部忙或缓冲区不足。我看到有些初学者把“主机发完写命令”误以为“数据已经发出去了”，排查了半天，其实设备根本没回就绪。

3.6 任务管理UPIU：异常处理的“最后手段”

命令超时、卡死后，主机需要主动干预。任务管理请求UPIU支持几个核心操作：

• 中止任务：终结指定标签的命令。
• 中止任务集：终结某个逻辑单元上所有正在执行的任务。
• 逻辑单元重置：重置某个LUN。
• 目标重置：恢复整个设备。

任务管理响应UPIU会返回一个任务管理状态码，告诉主机“中止成功、失败或任务集为空”等结果。排障时，我遇到过设备既不回响应UPIU也不回任务管理响应UPIU的情况，最后确认是硬件仲裁层面的问题，单纯靠任务管理已经无法恢复，只能做链路复位或设备复位。

任务管理这块的重要性，平时正常跑测试时体现不出来，一旦做异常注入测试，比如掉电、复位、延迟响应，就开始集中暴露问题。协议验证阶段一定要把任务管理流程反复打点。

3.7 查询UPIU：设备管理的“后门接口”

查询请求/响应UPIU负责设备属性、标志、描述符的读写，以及后台操作的触发。它和命令UPIU的最大区别在于：命令UPIU运行的是SCSI业务命令，查询UPIU运行的是UFS自己的管理指令。

常见的用途：

• 读取设备描述符、几何描述符，获取容量、块大小、WriteBooster配置。
• 读写属性，比如bMaxDataInSize、dLUNCount、WriteBooster状态。
• 触发后台操作，比如刷新缓存、启动后台预读。
• 使能/禁用某种设备特性。

协议栈中很多“隐藏操作”都是通过查询UPIU完成的，比如UFS3.1的HPB（主机性能增强）初始化时，主机需要查询或设置L2P映射表相关的属性；ZRL（零随机写入）的启用也是通过属性设置。

如果你在调试中看到“查询响应”一直不到，别急着怀疑链路，先检查查询请求里你要读的描述符ID是否合法、读取长度是否超出设备能力。有些设备对非对齐的查询请求直接不支持。

4. 主控视角的传输流程：从UTRD到门铃再到根因排查

4.1 UFSHCI里的传输路径

软件要发一个UPIU，不是直接把报文写到物理寄存器里的。大多数UFS主机控制器遵循UFSHCI标准，采用“描述符+门铃”的异步机制。

大致过程：主机在系统内存中构造一个UTP传输请求描述符（UTRD），里面指明命令UPIU放哪里、响应UPIU收到哪里、数据缓冲区是哪个地址、数据长度多少。写好之后，主控把UTRD队列的内存首地址写进UTRLBA寄存器，再通过UTRLDBR门铃寄存器“踢一脚”。

主控看到门铃被触发后，会从内存里读取UTRD，按照里面配置的地址和信息去发UPIU、收UPIU、搬数据。完成之后再通过中断通知软件。

这种方式可以做到一次硬件操作里携带一批传输请求，多个命令并行。地址描述符的队列深度，通常就是主控的队列深度。这也是为什么UFS设备标称队列深度和主控支持的并发数都要分别看。

4.2 传输请求描述符的结构

UTRD可以理解成一张“任务卡片”，它记录了：

• 命令UPIU在内存中的物理地址。
• 响应UPIU要写到的内存物理地址。
• 数据传输区域的物理地址、长度。
• 可选的任务管理UPIU地址。

实际编程时，很多驱动会把这个结构体和DMA描述符做在一个连续的内存池里，避免Cache一致性带来的麻烦。

我建议初级工程师按这个顺序去读UFSHCI规范：首先读寄存器清单，明确门铃和中断挂着哪些状态位；然后读UTRD结构体定义，搞清每个字段和UPIU内存地址的对应关系；最后才是读UPIU本身。很多驱动bug就出在这三者之间的地址换算上。

4.3 门铃机制与完成检测

门铃寄存器（DB）非常直观：bit位对应UTRD队列里的槽位。软件把某个槽位对应的bit写1，表示“这个槽位有活”。主控处理完成后，会把这个bit清零，并把对应的完成状态写入另一个状态寄存器。

中断状态寄存器里通常还会区分“传输完成”和“任务管理完成”，方便软件分别处理正常业务和异常恢复。调试时看到命令超时，第一件事就是读门铃寄存器和中断状态寄存器，确认这个命令到底有没有被主控发出去。

很多偶发问题都来自“软件已经清除了槽位、但硬件实际还在传输”的竞态。靠逻辑分析仪不一定能复现，需要你在代码里打印门铃寄存器的瞬时快照。

4.4 一次标准读命令的完整流转

我以一次读LBA 0x1000、长度8个扇区的操作为例：

1. 主机填充命令UPIU：事务类型0x01，标志位表示数据IN，LUN为0，任务标签0x12，CDB填READ(10)，逻辑块地址和传输长度写进CDB。
2. 主机填充UTRD：命令UPIU地址、响应UPIU缓冲区地址、数据缓冲区地址、数据传输长度设为4096字节。
3. 软件向门铃寄存器对应bit写1。
4. 主控读取UTRD，将命令UPIU通过UniPro发送给设备。
5. 设备解析命令，读取内部NAND数据，通过数据IN UPIU把4096字节送回内存。
6. 设备发送响应UPIU，状态为成功，任务标签0x12。
7. 主控DMA写回数据、置完成状态、触发中断。
8. 软件查中断、清状态、检查响应UPIU，完成一轮业务。

这里面任何一步卡住，症状可能都是“命令超时”。所以排障时一定要分步定位：命令有没有发出去？设备有没有收到？设备有没有回数据？数据是否完整？响应有没有回来？每步有对应工具，比如逻辑分析仪抓MIPI报文、主控寄存器打点、内存数据比对。

4.5 写命令为什么多一个握手

写命令流程比读命令长，因为中间多了一步就绪传输UPIU：

1. 主机发写命令UPIU。
2. 设备回就绪传输UPIU，表示缓冲区OK。
3. 主机发数据OUT UPIU。
4. 设备写完后回响应UPIU。

设备要不要先缓存整个写命令的数据，取决于设备内部实现，但协议层面必须基于就绪机制。主机端驱动如果省略了对就绪传输的等待，直接发数据OUT，轻则数据丢失，重则协议死锁。

这也是我最想提醒初学者的一点：不要把写命令理解成发命令UPIU后一路写到数据传完。中间设备随时可能因为内部GC（垃圾回收）或缓冲不足而延迟就绪，甚至要求重传。

5. UFS3.1协议新特性如何落到传输层

5.1 WriteBooster的协议体现

WriteBooster是UFS3.1卖点之一，实质是利用SLC Cache的Buffer来提升随机写性能。它对应设备描述符、属性里的一组配置，这些全靠查询UPIU读写。

主机使能WriteBooster时，要通过查询请求UPIU写属性。设备端是否进入“WriteBooster模式”，也是通过属性状态暴露的。如果不熟悉查询UPIU，连WriteBooster开关都找不到。

更关键的是，WriteBooster开启后，写命令的数据路径可能要经过额外的判断。有些实现里，命令UPIU本身不变，但设备内部针对写数据做SLC/QLC的调度。协议层看，仍然是命令UPIU、就绪UPIU、数据OUT UPIU、响应UPIU的四步流程。

5.2 HPB与命令语义

HPB（Host Performance Booster）让主机参与L2P映射缓存，减少设备FTL查找开销。协议层上，HPB同样是用查询UPIU读写相关的描述符和属性，主机先获取映射表段，后续读命令里会带上额外的映射信息。

我在实际验证中看到，很多HPB问题并不是逻辑错误，而是映射表版本过期：主机缓存了旧的L2P表，设备端数据已经迁移，读出来就是错数据。排查这类问题，反而要把目光放回到响应UPIU的状态码和超时机制上。

5.3 ZRL和确定性读

ZRL（零随机写入）针对随机写入场景。它也是通过属性设置开启，开启后主机得到更稳定的写延迟。协议层的报文结构没有根本变化，但设备内部的写策略完全不同。

这里想表达的是：UFS3.1大部分新特性的实现，都是“查询UPIU读写属性”和“命令UPIU语义微调”，传输层框架没变。所以只要第8~9章学扎实，面对新特性时，你需要的不是重新学一套协议，而是读那些新增属性字段。

附带说明一下：搜索时很多人把UFS协议里的“MIPI协议”理解成MIPI D-PHY/C-PHY，其实UFS底层用的是MIPI M-PHY和UniPro，不是手机显示/摄像头常说的C-PHY/D-PHY。UFS不用C-PHY，这点要分清，不然查资料时会绕进别的技术领域。

6. 调试实录与避坑手册

6.1 怎么观察UPIU报文

最直接的方法是逻辑分析仪配上MIPI M-PHY解码插件，可以在UniPro层看到帧，再解析出UPIU。如果测试环境没有逻辑分析仪，也可以在主机驱动里做“软抓包”：在UFS传输请求发出的前后，把命令UPIU内容、响应UPIU内容、任务标签、数据长度打印出来。

软抓包对偶发问题尤其有效。我常用一个小技巧：在响应UPIU的交互点加一个条件断点，限定某个LUN或某个标签，这样能精准抓到故障现场，避免打印信息海量刷屏。

如果连UFSHCI寄存器打点都不方便，就退而求其次，在操作系统块层打点，记录命令开始时间、完成时间、错误码。这种方法拿不到UPIU内容，但能定位是发卡还是收卡。

6.2 常见问题速查表

上面任何一行，展开讲都能写一篇单独的排障文章，但先记住一个原则：不要一上来就怀疑物理层。大部分问题出在UPIU内容不对、UTRD地址错、门铃没踢成功或响应校验遗漏上。

6.3 几个容易踩的坑

第一个坑是任务标签复用。软件在并发场景下，同一个标签被分配给两个未完成命令，设备回响应时，主机根本无法区分是哪条命令。规范和主控通常有标签分配策略，但驱动实现不严谨就很容易翻车。

第二个坑是LUN和启动器ID的位域处理。很多报文字段不是字节对齐的，直接按字节拷贝时容易把LUN和ID弄混。我看到过多次读命令发到错误的LUN上，原因就是把某个字节的位移搞错。

第三个坑是Cache一致性。UTRD和UPIU内容处于DMA区域，如果软件侧写完后没有做正确的Cache维护，主控读到的可能是旧内容。这类问题非常隐蔽，往往在偶发场景下出现，抓包又抓不到。

第四个坑是设备进入休眠或低功耗模式后，唤醒时序对不上，命令发出去了但设备还没准备好。此时UPIU大概率已经构造正确，问题在UniPro的链路唤醒和M-PHY的Gear切换上。遇到这种情况，要把分析和排查的重心从第8~9章转向UniPro和M-PHY的速率协商。

6.4 从传输层快速定位问题的经验

我的一个习惯是，调UFS问题时先回答三个问题：

一，这个UPIU发出去没有？怎么看门铃寄存器和链路状态。

二，设备回没回？返回的是什么事务类型？如果什么都没回，链路大概率有问题。

三，回的内容和预期匹配吗？标签、LUN、状态、数据长度，逐个字段核对。

这套思路能覆盖绝大多数日常问题。真正令人头疼的往往是“响应正常、但数据内容错”的情况。这时候就去核对DMA地址和缓存一致性，别在协议报文的语义上过度纠结。

7. 学习建议与个人体会

现在往回看，我学UFS第8~9章的路线大致是：先搞懂UPIU九种类型，然后去读UFSHCI规范里的UTRD和门铃寄存器，再配合逻辑分析仪抓实际报文逐字节对照。跑通几次读写流程、再人为制造几次超时和复位，这部分就算基本掌握了。

给你一个小建议：不要死记字段偏移，而是理解每种UPIU的“业务目的”。你只要记住命令UPIU是包裹面单、响应UPIU是签收回执、数据UPIU是货、任务管理UPIU是客服工单、查询UPIU是后台系统操作，整个报文结构就很好推了。

另外，有条件的话，把市面上的协议分析仪或带MIPI解码的逻辑分析仪用起来。一次真实抓包胜过十遍文档。我第一次抓到的UFS Trace里，UPIU内容和我根据文档手算的完全一致时，那种踏实感比看多少篇总结都有用。

设备端固件工程师和主机侧驱动工程师，看这两章时关注点会不一样：前者更关心设备如何正确解析和响应，后者更关心UFSHCI如何搬运和遣返报文。但无论站在哪一侧，最终都要在同一套UPIU语义上对齐。第8~9章就是这套共同语言的语法书。

传输层往下，是UniPro的链路管理和流控；再往下，是M-PHY的Gear切换和供电模式。学完第8~9章之后，我建议马上去看UniPro的帧格式、重传机制和链路启动流程。因为命令超时时，你判断是设备没回还是链路没送到，必须要懂UniPro才会分析。

这部分的知识不用一次吃透，可以先记住“传输层靠UPIU表达业务，链路层靠UniPro保证可靠，物理层靠M-PHY负责收发电信号”。带着这个框架去读源码、去抓报文、去调问题，你很快就能建立起UFS整体调试的感觉。