UFS3.1协议中文学习讲解(10~10.7.5)

事先声明本文不用于任何商业行为，仅用于本人学习与记录。所有截图版权均属于《JESD220E-UFS3.1》

欢迎点赞、收藏、转发分享给朋友，禁止未经书面授权的复制、搬运、二次剪辑。

如有引用请注明出处。

标准规范仍然以《JESD220E-UFS3.1》为准

写在最前：往后个人见解部分均用实线框出来。

从本章开始，对我来说是UFS重点章节，UTP层的介绍，本章主要介绍UPIU的格式，也是我们debug查手册的重中之重，如果论见解，甚至某些UPIU命令都可以单独拎出来讲，但是本章仍然是学习协议为主，个人简介为辅助。

另外，由于本章非常长，所以必须分段了，会降低一些观看的体验感。由于存储设备最重要的功能是写读，所以本章介绍到写读流程用到的UPIU，其他的UPIU放在下一章讲解。从现在开始，本文会随着理解的深入不断更新。

10 UFS Transport Protocol (UTP) Layer UFS 传输协议层

10.1 Overview概述

SCSI 架构模型 [SAM] 被用作 UTP 的通用架构模型，而 SAM 任务管理功能用于任务管理。任务（Task）通常是一个 SCSI 命令或服务请求。整个模型使用客户端 – 服务器模型，或更常见地称为请求 – 响应架构。使用 SCSI 命令并非必要。

SAM 架构中的客户端称为发起设备（Initiator devices），服务器称为目标设备（Target devices）。发起设备和目标设备映射到 UFS 物理网络设备。发起设备可以请求处理命令或任务管理功能，通过向目标设备发送请求来实现。目标设备是处理所请求服务的 UFS 设备。一个 UFS 设备将包含一个或多个逻辑单元（Logical Unit）。逻辑单元是设备内一个独立的处理实体。

客户端请求被定向到设备内的单个逻辑单元。逻辑单元将接收并处理客户端命令或请求。每个逻辑单元在目标设备内都有一个地址，称为逻辑单元号（Logical Unit Number，LUN）。

发起设备与目标设备之间的通信被划分为一系列消息。这些消息被格式化为本标准定义的 UFS 协议信息单元（UFS Protocol Information Unit，UPIU）。有多种不同的 UPIU 类型。所有 UPIU 结构在数据结构的开头（最低地址）包含一个公共头区域（common header area）。结构的剩余字段根据 UPIU 的类型而有所不同。

任务（Task）是执行一个或多个请求服务的命令或操作序列。逻辑单元包含一个将支持同时处理一个或多个任务的任务队列（Task Queue）。任务队列由逻辑单元管理。任务标签（Task Tag）是发起设备在构建任务时生成的唯一标签，目标设备和发起设备使用该标签来区分（distinguish）多个任务。所有与包含任务标签的事务相关联的事务和数据结构都包含该任务标签。

命令结构由命令描述符块（Command Descriptor Block，CDB）组成，其中包含命令操作码（command opcode）和相关参数、标志和属性。CDB 内容和结构的描述在相关的 [SAM]、[SBC] 和 [SPC] INCITS T10 标准中定义。

一个命令由命令阶段（Command Phase）、可选的数据阶段（Data Phase）和状态阶段（Status Phase）组成。这些事务以 UPIU 结构的形式表示。命令阶段将命令信息和支持参数从发起设备传递到目标设备。如果需要数据阶段，数据流的方向相对于发起设备而定。数据写入（Data WRITE）从发起设备流向目标设备。数据读取（Data READ）从目标设备流向发起设备。命令完成后，目标设备将在状态阶段向发起设备传递一个响应。该响应将包含指示命令完成或失败的状态。如果指示错误，响应将包含额外的详细 UFS 错误信息。

10.2 UTP and UniPro Specific Overview UTP 与 UniPro 特定概述

UTP 将命令、数据和响应作为标准消息包（T_SDU）通过 UniPro 网络传输。

UFS 事务被分组到称为 UFS 协议信息单元（UFS Protocol Information Units，UPIU）的数据结构中。

UFS 定义了用于以下用途的 UPIU：

• SCSI 命令
• 响应
• 数据输入（data in）和数据输出（data out）
• 任务管理
• 工具函数（utility functions）
• 厂商函数（vendor functions）
• 事务同步和控制

该列表可扩展，以适应未来的新增功能。

为了枚举和配置，UFS 支持一套由描述符（Descriptors）、属性（Attributes）和标志（Flags）组成的系统，用于定义和控制设备的具体参数，包括操作特性、接口、逻辑单元数量、操作速度、电源配置等。该系统是一个相关元素的层次树（hierarchical tree），可以扩展。

10.2.1 Phases阶段

SCSI 命令协议要求 UPIU 包遵循执行命令所需的阶段转换。简而言之，命令执行需要：

也就是说CMD发完有response，如果有数据传输，那么要带DATA IN/DATA OUT。这边不用强记，如果你不使用，背下来也不现实，并且不同种类的命令的ACK还不一样。协议中都定义有标准格式。

10.2.2 Data Pacing数据调步

设备可能有有限的内存资源用于缓冲，或有限的处理吞吐量。

在需要大量 Data Out 事务的命令期间，目标设备可以通过在准备好接收下一个 DATA OUT UPIU 时发送一个 READY TO TRANSFER UPIU（就绪传输 UPIU，即RTT）来调步（pace）数据阶段。此外，READY TO TRANSFER UPIU 包含一个嵌入的传输上下文（embedded transfer context），用于发起 DMA 传输。

在 Data In 阶段期间，不需要 READY TO TRANSFER UPIU，因为主机能够指定 Data In 传输的大小，从而能够提前为传入数据分配适当的内存资源。设备发出的 DATA IN UPIU 包也包含一个嵌入的 DMA 上下文，可用于基于每个包发起 DMA 传输。

10.2.3 UniPro

根据 UniPro 协议的要求，UFS 发起设备和目标设备将把其事务划分为包含 UPIU 的 UniPro 消息。UniPro 消息可以处理理论上无限大小的 T_SDU 消息。UFS 将对最大 T_SDU 消息大小施加一个实际限制。该限制为 65600 字节，其中包括 UPIU 头、可选扩展头区域和数据段。最小消息大小由基本头格式决定，为 32 字节。未来该值有可能增加，以允许更大的数据段区域。

64KB，这是 UFS 单次 UniPro 消息能承载的最大数据量。超过这个大小的数据需要分成多个 UPIU 包传输。这个在后面也会介绍

10.3 UFS Transport Protocol Transactions Overview UFS 传输协议事务概述

UFS 事务由在 UniPro 总线上、发起设备与目标设备之间传输的称为 UFS 协议信息单元（UPIU） 的数据包序列组成。事务以请求 – 响应（Request-Response）操作的形式开始。发起设备通过向目标设备和逻辑单元发送请求来启动事务序列。然后目标设备将以一系列最终以响应事务结束的事务进行响应。

所有 UFS UPIU 都由一个基本头段（basic header segment）、事务特定字段（transaction specific fields）、可能的一个或多个扩展头段（extended header segments）以及零个或多个数据段（data segments）组成。

一个基本头段的固定长度为 12 字节。最小 UPIU 大小为 32 字节，其中包含一个基本头段和事务特定字段。

最大 UPIU 大小定义为 65600 字节。

UPIU 格式足够灵活，可以轻松扩展以支持未来的事务和更大的数据段，并允许将此协议应用于 UniPro 以外的网络协议。

10.4 Service Delivery Subsystem服务交付子系统

服务交付子系统是一个 I/O 系统，用于在通过物理或逻辑总线连接的发起设备与目标设备之间传输服务请求和响应。UFS UTP 试图定义一个独立于服务交付子系统的协议。这将允许 UTP 轻松移植到不同的服务交付子系统。

目前，UFS 使用 MIPI UniPro 总线和 MIPI M-PHY® 作为服务交付子系统。为方便起见并帮助更好地理解，本标准的协议部分直接引用了 UniPro 和 M-PHY®。无论这些引用如何，UTP 协议独立于服务交付子系统，并且应该能够移植到其他 I/O 系统。

UPIU 结构将作为 MIPI UniPro 服务数据单元（T_SDU） 交给 MIPI UniPro。目前，UniPro T_SDU 不需要在 UPIU 结构周围包裹额外的头或尾。这意味着 T_SDU 大小将恰好等于 UPIU 大小。最小 T_SDU 大小将为 32 字节。最大 T_SDU 大小将为 65600 字节。

10.5 UPIU Transactions UPIU 事务

每个 UPIU 数据结构都包含一个事务码（Transaction Code）。该码定义了 UPIU 数据结构的内容和隐含功能或用途。表 10.1 列出了当前定义的事务码。

上面就是所有的UPIU Transaction Codes了

UFS 设备在任何时刻只能处理 NOP OUT 或 QUERY REQUEST 中的一个。

10.6 General UFS Protocol Information Unit Format UFS 协议信息单元通用格式

表 10.3 表示 UPIU 的通用结构。所有 UPIU 都将包含固定大小和位置的基本头（basic header），以及支持事务类型所需的附加字段（additional fields）。

这一节非常重要，这是通用命令格式，后面你的每一个UPIU都绕不开这个，不同的UPIU使用的字段不相同，也就是说并不是每一个字段都要用到的，不同UPIU用不到的字段会写成reserve形式。我在第一次看UFS协议的时候，就经常回来看每个地段的定义，这一节写的最清楚。

10.6.1 Overview概述

UPIU 总大小将根据 UPIU 事务类型而变化，但所有 UPIU 大小都将是 32 位的整数倍，这意味着它们将在 4 字节边界上寻址。如果数据和头段的聚合没有在 32 位边界上结束，则将添加额外的填充，将 UPIU 向上舍入到下一个 32 位（4 字节）边界。

UPIU 大小可以根据事务类型字段和扩展标志而固定或可变。某些事务类型对于相同的代码将始终具有不同的长度，而其他事务类型将始终是固定大小。此外，任何 UPIU 都可以在必要时扩展以包含额外的头和数据段。大小生成允许扩展，标志和大小字段定义了结构内的结构，以指示处理实体扩展区域在结构内的位置及其大小（包括填充），在某些情况下还包括扩展数据的类型。

10.6.2 Basic Header Format基本头格式

这是每个 UPIU 结构中包含的基本头格式。 该数据包将在发起设备和目标设备之间发送，或将成为更大的特定功能 UPIU 的一部分。此头中包含足够的信息，允许发起设备或目标设备跟踪它们所在的位置和来源、函数请求，以及是否需要额外的数据和参数。

当前定义的最小 UPIU 大小为 32 字节。这 32 字节区域将包含基本头加上附加字段。这意味着通过服务交付子系统发送的最小数据量将为 32 字节。

基本头格式定义如下：

a) Transaction Type（事务类型）

事务类型指示数据结构中包含的请求类型或响应类型。事务类型包含 HD 位、DD 位和事务码（Transaction Code），见表 10.5。

b) HD（头描述符位）

HD 位设置为 '1' 时，指定在头区域末尾包含一个端到端 CRC（end-to-end CRC）。 CRC 字段包含头区域的所有字段。CRC 放置在头之后的 32 位字位置。

本版本标准不支持端到端 CRC，因此 HD 位应为 '0'。

c) DD（数据描述符位）

DD 位设置为 '1' 时，指定数据段（Data Segment）的端到端 CRC（end-to-end CRC）包含在 UPIU 中。 32 位 CRC 是对数据段内的所有字段计算的。32 位 CRC 字放置在数据段的末尾，这将是 UPIU 的最后一个字位置。

本版本标准不支持端到端 CRC，因此 DD 位应为 '0'

HD 位 vs DD 位对比：

两个位都是 CRC 使能位，区别只是校验对象不同：

• HD = Header Descriptor → 校验头
• DD = Data Descriptor → 校验数据段

为什么 UFS 不支持端到端 CRC？

UFS 链路层（UniPro 数据链路层）已经有自己的 CRC 校验和重传机制，能保证数据传输的完整性。再叠加 UPIU 层的端到端 CRC 就重复了，所以 UFS 明确不支持，HD 和 DD 都必须为 0，省掉额外的 CRC 计算开销。

d) Transaction Code（事务码）

事务码指示 UPIU 数据字段中所表示的操作，以及 UPIU 内已定义字段的数量和位置（见表 10.1）。

e) Flags（标志）

标志字段的内容随事务类型操作码（Transaction Type opcode）而变化 ⁽¹⁾。

标志字段是 1 字节，具体含义取决于事务类型—— 不同类型的 UPIU（COMMAND、DATA IN、RESPONSE 等）用这 8 个标志位表达不同的含义。比如 COMMAND UPIU 的标志可能表示 "是否有数据阶段"，DATA UPIU 的标志可能表示 "是否是最后一包数据" 等。

f) Response（响应）

如果需要目标设备返回响应，此字段指示所请求的功能是成功还是失败。在从发起设备到目标设备的 UPIU 事务中，此字段保留（reserved）。

g) Status（状态）

如果事务是针对 Command Set Type = 00h（SCSI 命令）的 RESPONSE UPIU，则此字段包含 SCSI 状态（如 [SAM] 中所定义）。 否则，它包含操作码特定的状态，或保留。

Response 字段 vs Status 字段的区别：

• Response 是 UFS 传输层（UTP）自己的状态 ——"我（设备）有没有成功处理这个 UPIU"
• Status 是 SCSI 层的状态 ——"SCSI 命令执行得怎么样"（比如读成功、写失败、需要感知数据等）

h) Reserved（保留）

所有标记为保留的字段都应包含零值。

i) LUN（逻辑单元号）

此字段包含请求所针对的逻辑单元号（Logical Unit Number）。目标设备将至少包含一个编号为 0 的逻辑单元。此字段由目标设备和发起设备为与单个任务相关的所有 UPIU 事务生成和维护。

j) Task Tag（任务标签）

任务标签由发起设备在创建任务请求时生成。此字段将由目标设备和发起设备为与单个任务相关的所有 UPIU 事务维护。发起设备将包含一个寄存器或变量，表示任务标签值。发起设备将通过递增内部变量来生成唯一的任务标签，从而在创建新任务请求时生成唯一值。当任务请求由发起设备发出或生成一系列 UPIU 事务时，所有 UPIU 将在 Task Tag 字段中包含相同的值。

特别是，对于表 10.9 中每一行分组的 UPIU，应保持相同的 Task Tag 值。

k) Initiator ID（发起设备 ID）

发起设备 ID 字段为 4 位宽，编码在字节 4 的位 [7:4]。此字段指示创建任务请求的发起设备的身份。

如果只有一个发起设备，发起设备 ID 应设置为零。

UFS 设备应支持所有十六个发起设备 ID 值。发起设备 ID 应由主机在创建请求时编码。此字段由目标设备和发起设备为与同一任务相关的所有 UPIU 事务维护。

来自同一发起设备的所有请求应具有相同的 ID 值。有关发起设备 ID 的详细信息可在 UFS HCI 标准规范中找到。

l) Command Set Type（命令集类型）

命令集类型字段为 4 位宽，编码在字节 4 的位 [3:0]。此字段指示命令类型，并且与 RESPONSE UPIU 相关联。此字段是为 COMMAND UPIU 和 RESPONSE UPIU 定义的。在所有其他 UPIU 中，此字段保留。 此字段应用于指示 CDB 字段中使用的命令类型。当前支持的命令类型列于表 10.10。

注意看，只有COMMAND UPIU 和 RESPONSE UPIU 会用到这个Command Set Type，这句话一定要记住，后面要理解！不要把UPIU 和SCSI 命令搞混！

m) Query Function, Task Manag. Function（查询功能、任务管理功能）

此字段在 QUERY REQUEST 和 QUERY RESPONSE UPIU 中用于定义查询功能，在 TASK MANAGEMENT REQUEST UPIU 中用于定义任务管理功能。

n) Device Information（设备信息）

此字段在所有 RESPONSE UPIU 中提供特定 UFS 功能所需的设备级信息。

o) Total Extra Header Segment Length（总扩展头段长度）

此字段表示 UPIU 中包含的所有扩展头段（Extra Header Segments）的32 位字（DWORDS）数量。如果需要额外的头段，则使用此字段。每个扩展头段的长度应为 4 字节的倍数。此字段中的值是所有 EHS 除以四的总字节数。

+3后/4是一个标准的取整，向下取整

所有 EHS 字段组合的最大大小为 1024 字节。此字段中的值为零表示 UPIU 内不包含任何扩展头段。本标准不使用扩展头段，因此此字段的值应设置为零。

后面会说到，本版本标准不使用 EHS。永远为00h

p) Data Segment Length（数据段长度）

数据段长度字段包含 UPIU 数据段内的有效字节数。当数据段内的字节数不是 4 的倍数时，最后一个 32 位字段将用零填充，以终止于下一个最近的 32 位边界。组成数据段的 32 位单元（DWORDS）数量计算如下：

由于数据段长度字段大小为两个字节，数据段最多可包含 65535 个有效字节。此字段中的值为零表示 UPIU 内没有数据段。

这里很微妙 ，首先记住他代表本次UPIU量，上面说过每包数据最多能传64K，所以如果我要传例如96K数据，那我的该值就是最大也只能填64K(分两包发送即可)，举例DATA IN/OUT UPIU的Data Segment Length就代表着这一包带了多少有效数据字节。暂时有这个概念就行，可以继续往后看。

q) Transaction Specific Fields（事务特定字段）

某些事务码所需的附加字段位于此区域内。对于 UTP，此区域从 UPIU 内的字节地址 12 开始，终止于字节地址 31 的 32 位边界。由于所有 UPIU 都包含 12 字节的基本头，因此此区域剩余 20 字节。

这 20 字节是 UPIU 中最灵活的部分，也是不同事务类型差异最大的地方。基本头（12 字节）对所有 UPIU 都是固定且相同的，而事务特定字段则根据事务码的不同承载不同的含义。例如：

• COMMAND UPIU：此区域存放 CDB（命令描述符块），即具体的 SCSI 命令内容，如读、写、查询等操作码及参数。
• DATA IN / DATA OUT UPIU：此区域存放数据传输相关的上下文信息，如数据偏移量（Data Offset）等，用于指示当前数据包在整个传输中的位置。
• RESPONSE UPIU：此区域存放响应相关的附加信息，如感知数据（Sense Data）的长度和内容等。
• QUERY REQUEST / RESPONSE UPIU：此区域存放查询功能（Query Function）及对应的描述符、属性或标志的操作参数。

理解这一点非常关键：同一个字节偏移，在不同类型的 UPIU 中可能代表完全不同的含义。因此，在解析 UPIU 时，必须先根据基本头中的事务码确定 UPIU 类型，再去解读事务特定字段的内容，否则很容易产生误判。

另外需要注意的是，事务特定字段的实际使用长度取决于具体事务类型。有些事务类型可能只用到其中一部分字节，其余字节保留（reserved）并置零。这也是为什么最小 UPIU 大小为 32 字节——12 字节基本头 + 20 字节事务特定字段，正好构成一个完整的 32 字节最小包。

r) Extra Header Segments（扩展头段）

如果 Total EHS Length 字段包含非零值，则存在扩展头段。对于 UTP，此区域将从 UPIU 内的字节地址 32 开始。UPIU 可以包含零个或多个 EHS。每个扩展头段的长度应为 4 字节的倍数。本版本标准不使用 EHS。

s) Data Segment（数据段）

数据段字段从 UPIU 内 EHS 区域之后的下一个 32 位（DWORD）边界开始。对于 UTP，如果没有使用 EHS 区域，则意味着数据段将从字节地址 32 开始（如果启用了 E2ECRC，则为字节地址 36）。数据段将是 32 位的倍数，从而使 UPIU 包大小为 4 字节的倍数。数据段长度字段可以包含不是 4 的倍数的值，但数据段区域将用零填充以填充到下一个最近的 32 位（DWORD）边界。数据段长度字段指示数据段内的有效字节数。

10.7 UFS Protocol Information Units UFS 协议信息单元

本节提供每个 UFS 协议信息单元（UPIU）的详细信息。

10.7.1 COMMAND UPIU 命令 UPIU

COMMAND UPIU 包含基本 UPIU 头，加上指定命令所需的附加信息。发起设备将生成此 UPIU 并发送给目标设备，以请求目标设备执行 SCSI 命令服务。

这里要记住所有的SCSI命令经过UTP层都会打包进CMD UPIU中。

另外从下图中可以看到从第12字节开始，Expected Data Transfer Length以及CDB[0]~CDB[15]一共20字节构成了CMD UPIU的 Transaction Specific Fields（事务特定字段），也就是不用UPIU的事务特定字段不同。

10.7.1.1 Basic Header

COMMAND UPIU 的前 12 字节包含如 10.6.2 节 "基本头格式" 所述的基本头。具体细节如下：

a) Transaction Type（事务类型）

类型码 xx00 0001b 表示这是一个 COMMAND UPIU。

b) Flags（标志）

表 10.12 描述了 COMMAND UPIU 中使用的标志。

标志位在不同的UPIU中含义不同，可以理解为不同UPIU的特定flag，这个在使用的时候查协议就好了。

任务属性（Flags.ATTR）：

• Simple：最常见，设备按自己的调度策略处理
• Ordered：保证这个命令在它之前的所有命令之后执行（用于需要顺序保证的场景）
• Head of Queue：这个命令插到队列最前面，比所有已排队的 Simple 命令先执行（紧急任务）
• 多个 Head of Queue 命令之间的相对顺序由设备实现决定

命令优先级（Flags.CP）：

• 只有 1 位（SCSI SAM 标准里是多位，UFS 简化成 1 位）
• 只对 Simple 任务属性的命令有意义
• CP=1：高优先级，设备应优先调度
• CP=0：无优先级（普通）
• 任务管理器可以用这个位来决定 Simple 命令的处理顺序

c) Data Segment Length（数据段长度）

数据段长度字段应包含零，因为此 UPIU 中没有数据段。

这边理解了吧，CMD UPIU是不带数据包的！他不是DATA IN/OUT UPIU，由于它不带数据包，所以他的Data Segment Length为0，而Expected Data Transfer Length是他用来表示我即将要写下去的或者接受的数据的总长度。

d) Expected Data Transfer Length（预期数据传输长度）

预期数据传输长度字段包含一个值，表示完成 CDB 中指示的 SCSI 命令请求所需传输的字节数（例如，TRANSFER LENGTH、ALLOCATION LENGTH、PARAMETER LIST LENGTH 等）。数据可以从发起设备传输到目标设备，也可以从目标设备传输到发起设备。仅当 Flags.W 或 Flags.R 位之一设置为 '1' 时，此字段才有效。

对于从发起设备到目标设备的数据传输（写），.W 标志应设置为 '1'，.R 标志应设置为 '0'。预期数据传输长度字段中的值表示发起设备预期发送到目标设备的字节数。

对于从目标设备到发起设备的数据传输（读），.R 标志应设置为 '1'，.W 标志应设置为 '0'。预期数据传输长度字段中的值表示发起设备预期从目标设备接收的字节数。

当 COMMAND UPIU 编码 SCSI WRITE 或 SCSI READ 命令时（具体为 WRITE (6)、READ (6)、WRITE (10)、READ (10)、WRITE (16) 或 READ (16)），此字段的值应为逻辑块大小（bLogicalBlockSize）与 CDB 中 TRANSFER LENGTH 字段的乘积。

此模型要求发起设备分配足够的缓冲空间，以接收需要数据输入操作的命令所请求的全部数据大小。该大小（以字节为单位）应为预期数据传输长度字段中的值。此要求对于在不使用额外握手 UPIU 的情况下实现数据输入阶段的全部吞吐量非常重要。

发起设备可以请求大于目标设备接收缓冲区大小的数据输出大小。在这种情况下，目标设备将根据需要通过发送 READY TO TRANSFER UPIU 来调步 DATA OUT UPIU。发起设备在收到 READY TO TRANSFER UPIU 之前不会发送 DATA OUT UPIU。

RTT UPIU暂时不用管，我个人认为这里说早了，在后面的传输实例中你能非常清楚了解CMD UPIU,DATA IN/OUT UPIU,RESPONSE UPIU,RTT UPIU之间是怎么配合的。

10.7.2 RESPONSE UPIU 响应 UPIU

RESPONSE UPIU 包含基本 UPIU 头，加上指示命令执行成功或失败所产生的命令和设备级状态的附加信息。目标设备将在完成所请求的任务后生成此 UPIU 并发送给发起设备。

在终止需要 Data-Out 数据传输的命令之前，以及在发送 RESPONSE UPIU 之前，目标设备应等待，直到它收到与任何未完成的 READY TO TRANSFER UPIU 相关的所有 DATA OUT UPIU。此外，目标设备应停止为需要 Data-Out 数据传输且将被终止的命令发送 READY TO TRANSFER UPIU。

当设备要终止一个写命令（Data-Out）时，必须：

这里也不着急，了解即可，协议后面有数据传输的示意图，非常方便理解。

RESPONSE UPIU 的作用：

• 设备完成命令后，发 RESPONSE UPIU 告诉主机 "命令执行完了"
• 里面包含 SCSI 状态（如 GOOD、CHECK CONDITION 等）和设备级信息
• 这是一个命令事务的最后一个 UPIU（命令阶段 → 数据阶段 → 状态阶段）

10.7.2.1 Basic Header基本头

RESPONSE UPIU 的前 12 字节包含 10.6.2 节 "基本头格式" 中描述的基本头。具体细节如下：

a) Transaction Type（事务类型）

类型码值为 xx10 0001b 表示 RESPONSE UPIU。

b) Flags（标志）

表 10.14 描述了 RESPONSE UPIU 中使用的标志。

Flag还是要重点介绍的

c) Initiator ID (IID)（发起设备 ID）

发起设备 ID 字段（字节 4 的位 [7:4]）指示创建任务请求的发起设备的身份。详见 10.6.2 节基本头格式中的发起设备 ID 描述。

d) Command Set Type（命令集类型）

命令集类型字段将指定一个枚举值，指示用于定义 CDB 字段中命令字节的特定命令集。详见 10.6.2 节基本头格式。

e) Response（响应）

响应字段将包含 UFS 响应，指示组成任务执行的一系列 COMMAND、DATA 和 RESPONSE UPIU 的整体成功或失败（UFS 定义的）。详见 10.6.2 节基本头格式。

f) Status（状态）

状态字段包含发起设备发出的特定命令的命令集特定状态。状态字段是命令集特定的。命令集类型字段将指示状态与哪个命令集相关联。特定命令集可能定义也可能不定义如感知数据（Sense Data）中所示的详细扩展状态。如果命令需要扩展状态，则该信息将存储在感知数据字段中。

1) SCSI 命令集状态（SCSI Command Set Status）

当命令集类型字段指示 SCSI 命令集时，状态字段将包含标准 SPC 定义的 SCSI 状态值。可能的状态值列于表 10.15。有关状态条件的详细定义，参见 [SPC] 或 [SAM]。

• GOOD 状态表示 SCSI 命令成功完成，因此不返回感知数据。
• CHECK CONDITION 状态要求数据段包含失败命令的感知数据。

其他状态值可能返回也可能不返回感知数据。在这种情况下，数据段长度字段中的非零值表示此 UPIU 在数据段区域中包含感知数据。

'M' 表示此字段的强制实现，且值固定。'O' 表示此字段的支持是可选的；如果不支持，则应在字段中插入零值，否则将按描述指示该值。n/a 表示对 UFS"不适用"。

g) Device Information（设备信息）

设备信息字段提供设备级别的信息，不一定与执行命令的逻辑单元相关。

通常，这些信息是关于演化速度比常规命令慢得多的事件，并且主机响应延迟不关键。使用此字段可以避免在某些 UFS 属性上执行持续轮询（continuous polling）。

设备信息字段的 Bit 0 已定义，Bit 1 保留给 HPB（Host Performance Booster，主机性能增强器）扩展标准。所有其他位保留并应设置为零。

异常事件源包括：后台操作、动态容量、系统数据池等。详见 13.4.11 节 "异常事件机制（Exception Events Mechanism）"。

h) Data Segment Length（数据段长度）

数据段长度字段将包含数据段中的有效字节数。

在 RESPONSE UPIU 中，数据段将包含感知数据（Sense Data）字节，以及感知数据长度字段。

当此字段包含零时，表示 UPIU 中没有数据段区域，因此不返回感知数据。

本版本标准中，当命令集类型字段指示 SCSI 命令集时，感知数据字节数为 18，因此此字段将包含值 20（18 字节感知数据 + 2 字节感知数据长度 = 20 字节）。

如前所述，数据段字段大小位于 32 位（DWORD）边界上。数据段长度字段指示数据段区域中的 "有效" 字节数，因此其值可能不是 4 的整数倍。

• 感知数据（Sense Data）是 SCSI 标准里的错误详情数据结构
• 当命令执行失败（Status=CHECK CONDITION）时，设备在 RESPONSE UPIU 里带上感知数据，告诉主机具体错在哪
• 命令成功时，Data Segment Length=0，不带感知数据
• UFS 固定用 18 字节感知数据 + 2 字节长度 = 20 字节

i) Residual Transfer Count（剩余传输计数）

此字段仅在 Flags.U 或 Flags.O 字段之一设置为 '1' 时有效，否则此字段将包含零。

当 Flags.O 字段设置为 '1' 时，此字段指示由于预期数据传输长度字段包含的值小于目标设备预期传输的值，而未从 / 向发起设备传输的字节数。换句话说，目标设备有更多字节要接收 / 发送以完成请求，但发起设备预期的数量不超过预期数据传输长度中指示的数量。例如，发起设备可能故意请求少于它知道目标设备可传输的字节数，因为它只需要前 N 个字节。

当 Flags.U 字段设置为 '1' 时，此字段指示由于预期数据传输长度字段包含的值高于可用数据字节数，而未从 / 向发起设备传输的字节数。换句话说，目标设备要接收 / 发送的字节数少于发起设备请求传输的字节数。例如，发起设备可能在不知道目标设备实际有多少字节的情况下，故意请求比目标设备可传输的更多的字节，并要求获取最大值或超过可能值的数量。

溢出（Overflow）的典型场景： 主机发 INQUIRY 命令，故意只请求 36 字节，但设备实际有 96 字节的 INQUIRY 数据。设备传了 36 字节后，在 RESPONSE 里设置 Flags.O=1，Residual Transfer Count=60（96-36=60），告诉主机 "还有 60 字节没传，你要不要再发命令取剩下的"。

这是 SCSI 的标准行为 —— 主机可以故意少请求，设备告诉它实际有多少。

j) Sense Data Fields（感知数据字段）

感知数据字段将包含有关错误条件的附加信息。

对于 SCSI 命令，它们将提供固定格式感知数据所定义的前 18 个感知数据字节的副本，这对应于 70h 的响应码（Response Code）值。详见以下小节。

成功执行的命令通常不需要返回感知数据，因此在这种情况下，数据段可以为空，数据段长度可能为零值。

如果感知数据字段的长度加 2 不是 32 位的倍数，则感知数据字段将用零填充，以将数据放置在下一个最近的 32 位边界上。

k) SCSI Sense Data Fields（SCSI 感知数据字段）

当使用 70h 响应码值的格式时，感知数据字段将包含标准的 18 字节 SPC 定义的感知数据。详见 [SPC]。

感知数据由三级错误码组成，每一级的细节都在增加。其目的是为应用客户端提供一种在各种细节级别上确定错误或异常条件原因的方法。

• 感知键（Sense Key）确定错误或异常条件的一般类别，以及导致当前命令无法成功完成的原因。
• 附加感知码（Additional Sense Code，ASC）提供更精细的错误细节。
• 附加感知码限定符（Additional Sense Code Qualifier，ASCQ）进一步细化错误信息。

需要实现感知键值来指示错误或异常条件。如果实现不需要更精细的错误细节，则不需要实现本文档中未描述的 ASC 或 ASCQ 值，可以在这些字段中放置零值。

所有以错误或异常条件终止的 SCSI 命令将在 RESPONSE UPIU 中自动返回感知数据，从而使主机无需发出后续的 REQUEST SENSE 命令来检索附加的感知错误信息。

Sense Key (4位)  ← 第1级：错误大类

Additional Sense Code (ASC, 1字节)  ← 第2级：具体错误

Additional Sense Code Qualifier (ASCQ, 1字节) ← 第3级：错误细分

简单类比：

• Sense Key = "食物坏了"（大类）
• ASC = "肉类变质"（具体类型）
• ASCQ = "牛肉变质，因冷藏温度不够"（具体原因）

UFS 为什么自动返回感知数据？

传统 SCSI 中，命令失败后主机需要额外发一个 REQUEST SENSE 命令去取错误详情。UFS 把感知数据直接放在 RESPONSE UPIU 里一起返回，省掉了一次额外的命令交互，提高了效率。

l) Sense Data Length（感知数据长度）

感知数据长度字段指示其后跟随的有效感知数据字节数。如果已添加填充字节以达到 32 位边界，则感知数据长度加 2 可能小于数据段区域中包含的字节数。

成功执行的命令通常不需要返回感知数据，因此在这种情况下，数据段区域可以为空，数据段长度可以为零值。

以错误或异常条件终止的命令可能返回也可能不返回感知数据。如果感知数据长度指示值为零，则该错误或异常条件不返回感知数据。数据段长度中的零值也指示未返回感知数据。否则，感知数据长度将包含一个值，指示感知数据信息的附加字节数。

m) SCSI Sense Data Length（SCSI 感知数据长度）

当使用 SCSI 命令集时，感知数据长度字段应指示值 18。

n) Sense Data Format（感知数据格式）

表 10.17 描述了感知数据结构，该结构提供有关先前执行的 SCSI 命令的详细错误信息。返回 18 字节，并且附加感知长度（Additional Sense Length）字段设置为值 10。

'M' 表示此字段的强制实现，并且指定的值是固定的。'O' 表示此字段的支持是可选的；如果不支持，则应在该字段中插入零值，否则该值将按描述指示。

感知键（SENSE KEY）用于操作期间的正常错误处理。

附加感知码（ASC）和附加感知码限定符（ASCQ）主要用于详细诊断和日志记录（事后分析）信息。 如果设备服务器没有与错误或异常条件相关的进一步信息，这些字段应设置为零。通常，除少数几个外，它们不是强制的，并且可以设置为零，这意味着不提供附加信息。有关附加感知码和附加感知码限定符的列表，请参见 [SPC]。

o) Sense Key（感知键）

感知键值提供了一种对错误和异常条件进行分类的方法。感知键指示特定类型的错误。附加感知码（ASC）和附加感知码限定符（ASCQ）可用于进一步详细描述感知键所指示的条件。感知键特定于由特定命令执行的操作。

这个对于协议来说是非常重要的获取信息的方式，我们也可以通过这个看到设备的部分状态从而做出判断，但是我认为如果你的UFS做的正常，通常是No Sense，因为固件bug通常不会体现在协议上，所以这是debug非常小的一个方面。

10.7.3 DATA OUT UPIU数据输出 UPIU

DATA OUT UPIU 包含基本 UPIU 头，加上管理数据输出传输所需的附加信息。数据传输从发起设备流向目标设备（写）。DATA OUT UPIU 通常包含一个数据段。

可以有一个空（null）DATA OUT UPIU：数据段为空，数据段长度值为零。

DATA OUT UPIU 是响应目标设备生成的 READY TO TRANSFER UPIU 而发送的，详见 10.7.13 节 "数据输出规则（Data Out rules）"。

10.7.3.1 Basic Header

DATA OUT UPIU 的前 12 字节包含 10.6.2 节 "基本头格式" 中描述的基本头。具体细节如下：

a) Transaction Type（事务类型）

类型码值为 02h 表示 DATA OUT UPIU。

b) Initiator ID (IID)（发起设备 ID）

发起设备 ID 字段（字节 4 的位 [7:4]）指示创建任务请求的发起设备的身份。详见 10.6.2 节基本头格式中的发起设备 ID 描述。

c) Data Segment Length（数据段长度）

数据段长度应指示数据段区域内的有效字节数，并且不应包含填充字节数（如果存在）。

d) Data Buffer Offset（数据缓冲偏移）

数据缓冲偏移字段包含此 UPIU 数据有效载荷在完整数据传输区域内的偏移量。数据缓冲偏移与数据段长度之和不应超过 COMMAND UPIU 中指示的预期数据传输长度Expected Data Transfer Length。

此字段允许 DATA OUT UPIU 包的乱序排序（out of order sequencing）。因此，DATA OUT UPIU 包的顺序不必是顺序的。

注：仅当 UFS 设备支持它（bDataOrdering = 01h）并且此功能被启用（bOutOfOrderDataEn = 01h）时，才会发生乱序排序。

当 DATA OUT UPIU 是 SCSI WRITE 事务的一部分时（即以 WRITE (6)、WRITE (10) 或 WRITE (16) 命令开始的事务），此字段的值应等于逻辑块大小（bLogicalBlockSize）的整数倍。

有个映像，支持乱序，乱序需要设备支持（bDataOrdering = 01h），怎么标志数据包是全部数据的哪一段，用Data Buffer Offset表示

e) Data Transfer Count（数据传输计数）

此字段指示发起设备在此 UPIU 中传输到目标设备的字节数。此值是 UPIU 数据段中包含的字节数。

单个 DATA OUT UPIU 包中可传输的最大字节数为 65535 字节。 因此，如果原始命令的预期数据传输长度需要超过 65535 字节，则发起设备将需要发出多个 DATA OUT UPIU 包。

当 DATA OUT UPIU 是 SCSI WRITE 事务的一部分时（即以 WRITE (6)、WRITE (10) 或 WRITE (16) 命令开始的事务），此字段的值应等于逻辑块大小（bLogicalBlockSize）的整数倍。

此字段和 UPIU 的数据段长度字段应包含相同的值。此字段旨在与数据缓冲偏移字段Data Buffer Offset一起使用，作为 DMA 上下文的一部分。

f) Data Segment（数据段）

这是包含数据有效载荷的数据段区域。

单个 DATA OUT UPIU 包中可传输的最大数据有效载荷大小为 65535 字节。

数据段区域始终从 32 位（DWORD）边界开始。数据段区域应完全填充数据有效载荷到 32 位（DWORD）边界，除非该 UPIU 是传输最后数据部分的 UPIU。在这种情况下，如有必要，数据段区域应填充到下一个最近的 32 位边界。

当 DATA OUT UPIU 是 SCSI WRITE 事务的一部分时（即以 WRITE (6)、WRITE (10) 或 WRITE (16) 命令开始的事务），数据段区域应包含整数个逻辑块。

注：对于乱序 DATA OUT UPIU，最后数据部分可能不由最终 UPIU 传输。

g) 数据输出传输示例（Data out transfer example）

图 10.1 展示了从发起设备到目标设备的数据传输示例。具体来说，命令处理需要传输 577 字节的数据。数据传输是乱序完成的：首先传输数据的中间部分，然后是最后部分，最后是第一部分。

注：第二个 DATA OUT UPIU 传输数据的最后部分。此 UPIU 中的数据段有 65 字节有效数据和 3 个填充字节。其他 UPIU 中的数据段完全填充（无填充字节）。

这张图是核心，CMD UPIU的发送后，只有RTT UPIU回给Host了(我已准备好接收数据)，HOST才能发RTT UPIU，那你怎么发，顺序发还是乱序发随你，但是我需要知道这个数据包的长度，他的偏移，这样你乱发我才能按序排好，当然如果你需要把没有4字节对齐的地方对齐了，再发给我。最后等到所有数据传完了(CMD UPIU有一个总预期数据量Expected Data Transfer Length)，我就回一个RESPONSE UPIU给你，确认一下接收状态。

10.7.4 DATA IN UPIU数据输入 UPIU

DATA IN UPIU 包含基本 UPIU 头，加上管理数据输入传输所需的附加信息。数据从目标设备流向发起设备（读，READ）。DATA IN UPIU 通常包含一个数据段。可以有一个空（null）DATA IN UPIU：数据段为空，数据段长度为 0。

10.7.4.1 Basic Header基本头

DATA IN UPIU 的前 12 字节包含 10.6.2 节 "基本头格式" 中描述的基本头。具体细节如下：

a) Transaction Type（事务类型）

类型码值为 xx10 0010b 表示 DATA IN UPIU。

b) Initiator ID (IID)（发起设备 ID）

发起设备 ID 字段（字节 4 的位 [7:4]）指示创建任务请求的发起设备的身份。详见 10.6.2 节基本头格式中的发起设备 ID 描述。

c) Data Segment Length（数据段长度）

数据段长度应指示数据段区域内的有效字节数，并且不应包含填充字节数（如果存在）。

d) Data Buffer Offset（数据缓冲偏移）

数据缓冲偏移字段包含此 UPIU 数据有效载荷在完整数据传输区域内的偏移量。数据缓冲偏移与数据段长度之和不应超过 COMMAND UPIU 中指示的预期数据传输长度。

此字段允许 DATA IN UPIU 包的乱序排序。因此，SCSI IN UPIU 包的顺序不必是顺序的。

注：仅当 UFS 设备支持它（bDataOrdering = 01h）并且此功能被启用（bOutOfOrderDataEn = 01h）时，才会发生乱序排序。

当 DATA IN UPIU 是 SCSI READ 事务的一部分时（即以 READ (6)、READ (10) 或 READ (16) 命令开始的事务），此字段的值应等于逻辑块大小（bLogicalBlockSize）的整数倍。

e) Data Transfer Count（数据传输计数）

此字段指示目标设备放置在 UPIU 数据段中、用于传输回发起设备的字节数。此值是 UPIU 数据段中包含的有效字节数。单个 DATA IN UPIU 包中可传输的最大字节数为 65535 字节。

当 DATA IN UPIU 是 SCSI READ 事务的一部分时（即以 READ (6)、READ (10) 或 READ (16) 命令开始的事务），此字段的值应等于逻辑块大小（bLogicalBlockSize）的整数倍。

此字段和 UPIU 的数据段长度字段应包含相同的值。

f) Data Segment（数据段）

这是包含数据有效载荷的数据段区域。

单个 DATA IN UPIU 包中可传输的最大数据有效载荷大小为 65535 字节。

数据段区域始终从 32 位（DWORD）边界开始。数据段区域应完全填充数据有效载荷到 32 位（DWORD）边界，除非该 UPIU 是传输最后数据部分的 UPIU。在这种情况下，如有必要，数据段区域应填充到下一个最近的 32 位边界。

当 DATA IN UPIU 是 SCSI READ 事务的一部分时（即以 READ (6)、READ (10) 或 READ (16) 命令开始的事务），数据段区域应包含整数个逻辑块。

注：对于乱序 DATA IN UPIU，最后数据部分可能不由最后一个 UPIU 传输。

g) 数据输入传输示例（Data in transfer example）

图 10.2 展示了从目标设备到发起设备的数据传输示例。具体来说，在命令处理期间，将 577 字节数据发送到发起设备。数据传输是按顺序完成的：首先传输数据的第一部分，然后是中间部分，最后是最后部分。

注：最后一个 DATA IN UPIU 传输数据的最后部分。此 UPIU 中的数据段有 65 字节有效数据和 3 个填充字节。其他 UPIU 中的数据段完全填充（无填充字节）。

这一节与DATA IN UPIU基本上类似，注意这里无RTT，示例给了一个顺序传输，并不意味着没有乱序传输，也是有的，只是给了一个顺序的示例。

为何没有RTT了？

因为不需要！

读操作时，主机提前知道要收多少、也提前分好了缓冲，设备直接发就行；写操作时，设备不知道自己一次能收多少，得用 RTT 告诉主机 "我现在能收 N 字节"。

10.7.5 READY TO TRANSFER UPIU就绪传输 UPIU

READY TO TRANSFER UPIU 由目标设备在其准备好接收数据块时发出，此时正在处理需要数据输出传输的 SCSI 命令（例如，写命令）。目标设备可以通过在 UPIU 内设置适当的字段来请求顺序或乱序的数据。

发起设备通过发送一个 DATA OUT UPIU 包来响应 READY TO TRANSFER UPIU 包。目标设备可以发送一个或多个 READY TO TRANSFER UPIU，以满足关联的 COMMAND UPIU 中指示的预期数据传输长度。单个 READY TO TRANSFER UPIU 可请求的最大字节数不应大于 bMaxDataOutSize 属性指示的值。

有关发起设备到目标设备数据传输的更多详细信息，请参见 10.7.13 节 "数据输出传输规则（Data out transfer rules）"。

有关多LUN，多任务时的数据传输在10.7.13 节有详细说明，上面说的都是传一个，成功了再下一个，类似串行，10.7.13 节介绍类似流水线传输，高效利用CPU。

10.7.5.1 Basic Header基本头

READY TO TRANSFER UPIU 的前 12 字节包含 10.6.2 节 "基本头格式" 中描述的基本头。具体细节如下：

a) Transaction Type（事务类型）

类型码值为 xx11 0001b 表示 READY TO TRANSFER UPIU。

b) Initiator ID (IID)（发起设备 ID）

发起设备 ID 字段（字节 4 的位 [7:4]）指示创建任务请求的发起设备的身份。详见 10.6.2 节基本头格式中的发起设备 ID 描述。

c) Data Segment Length（数据段长度）

数据段长度字段应包含零，因为此 UPIU 中没有数据段。

d) Data Buffer Offset（数据缓冲偏移）

数据缓冲偏移字段向发起设备指示要发送的数据段的起始位置。目标设备可以请求发起设备以多个 UPIU 传输数据，不一定按顺序。数据缓冲偏移与数据传输计数之和不应超过 COMMAND UPIU 中指示的预期数据传输长度。

数据缓冲偏移应为 4 的整数倍。

当 RTT UPIU 是 SCSI WRITE 事务的一部分时（即以 WRITE (6)、WRITE (10) 或 WRITE (16) 命令开始的事务），此字段的值应等于逻辑块大小（bLogicalBlockSize）的整数倍。

e) Data Transfer Count（数据传输计数）

此字段指示目标设备请求的字节数。

数据传输计数字段应始终为 4 字节的整数倍，但请求传输中最后一部分数据的 READY TO TRANSFER UPIU 除外。

当 RTT UPIU 是 SCSI WRITE 事务的一部分时（即以 WRITE (6)、WRITE (10) 或 WRITE (16) 命令开始的事务），此字段的值应等于逻辑块大小（bLogicalBlockSize）的整数倍。

单个 READY TO TRANSFER UPIU 中可请求的最大字节数不应大于 bMaxDataOutSize 属性指示的值。

f) READY TO TRANSFER UPIU 序列示例（sequence example）

图 10.3 展示了 READY TO TRANSFER UPIU 序列的示例。具体来说，在命令处理期间，目标设备请求发起设备发送总共 577 字节的数据。数据传输是乱序（反向）完成的：首先是最后一部分，然后是中间部分，最后是第一部分。

注：第一个 READY TO TRANSFER UPIU 请求发送数据的最后一部分。