更深的理解UPIU数据包的格式

最佳留言者将获得《深入浅出SSD》电子书一本

UPIU是命令、数据和状态信息传输的载体，是UFS协议栈的灵魂。UPIU是有固定格式的数据包，我们分析数据包格式，有助于我们更深的理解UPIU以及整个UFS协议。这一章我们看看UPIU数据包的格式。

每个UPIU都有一个12字节的Header，再加上跟每个UPIU相关的域。一个UPIU（包括Header）最小为32字节，最大为65600字节。

我们看通用的Header，具体如下：

我们看看其中的一些域。

1. Transaction Type：就是指定该UPIU是前面12个UPIU中的哪一个,具体如下：

2. Flags：只对命令和其响应的UPIU有用，指定命令的属性。

R: 如果该比特置起来，说明该命令是读命令；

W: 如果该比特置起来，说明该命令是写命令；

ATTR: 命令属性域。UFS命令有simple ，ordered 和Head of Queue命令。

那么，这些命令有什么不一样呢。

Simple command：就是一般的命令，设备收到这样的命令无需特别处理，一般谁先到谁先执行。

Ordered command：设备收到这样的命令，应该把该命令之前的命令都处理完，才能处理该命令。（明星出场，先清个场。）

Head of Queue command：设备收到该命令后，放到命令队列的头部，立刻执行。（又见插队，这个没有上过幼儿园吧，连基本的排队意识都没有。）

CP: 表示命令的优先级。1为高优先级，0为低优先级。注意，该比特只适合简单命令（simple command）。

3. LUN: Logical Unit Number。UFS上层协议来自SCSI，它继承了LU的概念，即把存储物理空间划分成若干个逻辑空间，每个逻辑空间都是从LBA 0开始，用LUN标识。主机在发命令或者请求时，应该在命令中指定该命令是发给哪个LU。LUN用以寻址。UFS的LU和NVMe中的Namespace一个概念。

4. Task Tag：UFS支持命令队列，主机可以同时发送很多个命令给设备。为区分这些命令或者请求，主机需要为每个命令贴上标签Tag。然后跟这个命令或者请求相关的数据UPIU和状态UPIU，都具有跟这个命令UPIU一样的Tag。

举例：

对这个读命令来说，COMMAND UPIU、所有的DATA IN UPIU和RESPONSE UPIU都具有同一个task tag。

5. Command Type：命令类型。UFS预期有三类命令：一是简化的SCSI命令，二是UFS自己原生的命令，三就是用户自定义命令。目前UFS的命令都是从别人家（SCSI）借来的，自己一个命令也没有制定。如用户无自定义命令，该域就是0（SCSI命令）。

6. Initiator ID： 主机的ID，手机系统中一般一个主机连接一个UFS设备，所以主机ID一般为0。

7. Response：设备告知主机命令或请求执行是否成功。

8. Status：设备返回命令执行状态。对SCSI命令的状态信息，UFS有如下状态：

9. Query Function, Task Manag. Function：指定具体Query和Task Management功能。

任务管理器有如下功能（Function）：

设备管理器有如下功能：

总的来说，就是读写设备属性（Attributes）、标识（flags）和描述符（descriptors）。

关于设备属性、标识和描述符，后面有专门章节讲述。

10. Device Information：设备信息。该域往往跟该命令或者请求无关，属于设备夹带私货。因为UFS主机和设备是主从关系，如果UFS主机没有向设备发命令或者请求，UFS设备是不能主动向主机报告设备状况的。如果UFS设备有特殊事件发生，它可以趁返回RESPONSE UPIU的时候把事件顺带告诉主机。所以该域只对RESPONSE UPIU有效。

以上是UPIU头的基本信息，这个是所有UPIU都具有的。除此之外，每个UPIU有它独有的其它信息，UFS spec上都有介绍，读者可以自行阅读。