最佳留言者將獲得《深入淺出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上都有介紹，讀者可以自行閱讀。