UFS中流淌的數據包叫做UPIU(UFS Protocol Information Unit,UFS協議信息單元),它是固定格式的數據結構,用以傳輸應用層發來的命令或者請求,以及跟它們相關的數據或者狀態信息。它就是SATA中的FIS,PCIe中的TLP。我們看看UFS中命令或請求是怎么執行的。
UFS采用“客戶-服務器”或者說主從的命令架構,UFS主機(Client,命令發起者,Initiator,他們都是一個意思)發送命令或者請求(Request)給UFS設備(服務器,Target),然后UFS設備執行命令并返回命令狀態(Response)。
一個命令或者請求的執行包含下面幾個階段:
命令階段:主機發起命令或請求給設備,這是“因”;
數據階段:傳輸跟命令相關的數據,比如讀寫命令,都涉及到數據的傳輸;有些命令不涉及數據的傳輸,所以這個階段并不是總是存在的,跟具體命令和請求相關。
狀態階段:設備執行完命令,必須給主機返回命令執行狀態信息。這個是“果”,必不可少的。在PCIe中,有Posted和Non-posted的TLP。對前者,命令執行者無需返回命令執行狀態給命令發起者,對后者,命令執行者必須返回狀態給命令發起者。對UFS來說,它的命令總是non-posted,即設備必須返回命令狀態給主機。
在命令執行過程中,無論是處在哪個階段,UFS主機和設備間都是通過UPIU進行信息的交互。
1. UFS主機通過命令或者請求UPIU發命令請求給設備;
2. UFS主機或者設備通過UPIU傳輸數據;
3. UFS設備通過UPIU返回命令狀態信息給主機。
下面我們看看UFS當中都有哪些UPIU。
命令或者請求UPIU
前一章看到,應用層包括UFS命令、設備管理器和任務管理器三個模塊,傳輸層根據不同模塊發來的命令或者請求,分別產生不同類型的UPIU。
UFS命令模塊發送簡化版本的SCSI命令,當傳輸層收到命令請求后,它會生成:COMMAND UPIU,把命令封裝起來。
應用層通過任務管理器來管理任務隊列,比如終止(Abort)和查詢命令隊列中的命令。當傳輸層收到來自任務管理器中的請求后,它會生成:TASK MANAGEMENT REQUEST UPIU,把請求封裝起來。
UFS通過設備管理器來管理UFS設備,比如設置和查詢UFS設備的配置(Configuration)。當傳輸層收到來自設備管理器發來的請求后,它會生成:QUERY REQUEST UPIU,把請求封裝起來。
數據傳輸相關UPIU
當主機發送了類似讀命令給設備之后,設備需要返回數據給主機,設備通過DATA IN UPIU向主機傳輸數據。
當主機發送了類似寫命令給設備之后,主機需要往設備寫數據,主機通過DATA OUT UPIU向設備傳輸數據。
UFS的主機是個暖男,它在向設備寫數據的時候,會考慮到設備這個時候能不能接收數據(因為設備可能這個時候沒有足夠的空間接收主機數據),它在向設備發了寫命令之后,不會立刻把數據傳輸給設備,而是在那里等設備的通知。當設備準備好接收數據,以及接收多少數據,設備通過READY TO TRANSFER UPIU (RTT)告知主機。當主機接收到該RTT后,才開始按照RTT的信息傳輸數據。至于每次傳輸數據的多少,RTT中包含這信息,主機根據RTT進行傳輸。
所以,主機只有在收到設備的RTT,才能發DATA OUT UPIU!
注意,讀命令無需這種機制。因為設備從閃存中獲得數據后,是設備控制數據的傳輸。對主機來說,它在發讀命令之前,已經準備好足夠的空間用以接收數據,所以不存在主機沒有空間接收數據的情況。
狀態UPIU
前面看到,主機有三種請求:SCSI命令,任務管理器發出的Task Management Request,以及設備管理器發出的Query request。針對不同的命令或者請求,設備在執行完相應的任務后,分別返回對應的狀態UPIU給主機。
其它UPIU
除了以上常規的UPIU,還有其它一些UPIU作為他用。
設備上電后,主機檢測是否與之連接,會發NOP OUT UPIU給設備。我們平時想看看跟某個電腦或者網站能否連接上,會發一個ping命令。NOP OUT UPIU跟ping命令作用類似。
當設備收到NOP OUT UPIU后,會返回NOP IN UPIU。主機收到該UPIU后,確認與設備連接,然后可以進行后續操作。
最后一個UPIU就是REJECT UPIU。當設備收到一個無效的UPIU時,它會發REJECT UPIU拒絕無效的UPIU。
UPIU匯總
偷個懶,我就直接把UFS spec這張表貼這里。數了數,一共12個UPIU。經過我之前的解釋,讀者現在應該清楚每個UPIU的作用了。
讀寫命令中UPIU交互例子
前面我們都是單個來看UPIU,現在我們以讀寫命令為例,看看他們是如何組合完成命令處理的。
首先是一個“主機往設備讀取96KB數據”的例子。
首先,主機發送讀96KB數據的命令給設備,然后設備執行命令,分了三批把數據返回給主機,最后返回命令執行狀態給主機。
然后是一個“主機往設備寫64KB數據”的例子。
主機發送寫64KB數據的命令給設備,然后在那里等設備響應。很快,設備說,你可以傳24KB數據下來了,于是主機寫24KB數據給設備;接著,設備又來通知說可以繼續傳32KB數據,主機照做。最后,設備通知說可以把最后8KB數據也傳過來,主機于是寫最后8KB數據。最后,主機收到設備命令執行完成的響應。
我們看到,主機必須等收到RTT后才能啟動數據傳輸!
-
管理器
+關注
關注
0文章
252瀏覽量
18911 -
數據包
+關注
關注
0文章
269瀏覽量
24865 -
UFS
+關注
關注
6文章
109瀏覽量
24753
原文標題:蛋蛋讀UFS之三:UFS數據包UPIU
文章出處:【微信號:SSDFans,微信公眾號:SSDFans】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
請問Z-Stack Home中發送端的命令或請求是如何對應接收端的回調函數的?
UFS Card是什么?
掃描請求是否在中央(TX)或外圍(RX)模塊上產生任何事件?
UFS電源管理的相關資料推薦
手機研發必須了解的UFS相關知識
USB主機如何識別USB設備及請求命令
什么是UFS?為什么說UFS是手機存儲的未來?
來看看UFS的電源管理

UFS系列十:UFS電源管理

評論