如何實現Linux下的U盤(USB Mass Storage)驅動
摘要
本文主要介紹了USB Mass Storage的相關的各種協議之間的關係,以及如何在Linux的USB驅動框架下實現U盤驅動
![]() |
本文提供多種格式供: |
---|---|
HTML版本的在線地址為: https://www.crifan.com/files/doc/docbook/usb_disk_driver/release/html/usb_disk_driver.html |
2012-08-09
修訂曆史 | ||
---|---|---|
修訂 0.4 | 2011-07-01 | crl |
|
||
修訂 0.6 | 2012-08-09 | crl |
|
版權 © 2012 Crifan, https://crifan.com
目錄
- 縮略詞
- 正文之前
- 1. USB基本知識
- 2. USB Mass Storage大容量存儲的基本知識
-
- 2.1. USB Mass Storage相關的協議
-
- 2.1.1. USB Mass Storage相關協議簡介
-
- 2.1.1.1. USB MSC Control/Bulk/Interrupt (CBI) Transport
- 2.1.1.2. USB MSC Bulk-Only (BBB) Transport
- 2.1.1.3. USB MSC UFI Command Specification
- 2.1.1.4. USB MSC Bootability Specification
- 2.1.1.5. USB MSC Compliance Test Specification
- 2.1.1.6. USB Lockable Storage Devices Feature Specification
- 2.1.1.7. USB MSC USB Attached SCSI Protocol (UASP)
- 2.1.2. USB MSC的各個協議之間關係總結
- 2.1.3. U盤與USB中的Class,Subclass和Protocol的對應關係
- 2.2. USB Mass Storage相關的軟件實現
- 3. 實現U盤驅動的整個流程是什麼樣的
- 4. Linux係統下,USB驅動的框架已經做了哪些事情
- 5. Linux下實現U盤驅動,自己需要做哪些事情以及如何做
- 參考書目
插圖清單
- 1. U盤
- 2.1. USB Mass Storage Framework
- 2.2. PC和U盤
- 2.3. PC和U盤的芯片內部結構
- 2.4. PC和U盤的內部邏輯框圖
- 2.5. PC和USB MSC設備
- 2.6. USB MSC的分類
- 2.7. USB Storage Class Protocol Relation
- 2.8. SubClass Codes Mapped to Command Block Specifications
- 2.9. Mass Storage Transport Protocol
- 3.1. USB數據流向圖
關於U盤,估計大家都用過。
比如,筆者手上的宇瞻AH320的8G的U盤:
最常見的用法就是,直接將此8GU盤插到電腦的USB口上,然後係統(Windows的XP或者Linux)就會自動檢測到你的U盤然後生成一個移動盤符,然後你就可以打開對應盤符,讀寫文件數據了。
而此文呢,目的就是,要搞懂,作為驅動開發者來說,對於這樣一個U盤,如何在Linux平台下,去實現U盤驅動,即USB Mass Storage驅動,實現驅動時,需要做哪些事情,以及如何去實現這些事情。
關於USB,其實網上也有不少相關的文章,但是筆者覺得太多帖子,很多帖子,也隻是介紹USB協議,而如何在Linux下麵實現驅動,卻很少提及。或者說是,理論多,實踐少,東一塊,西一塊,很少能把相關知識有機的結合起來,尤其是軟件,硬件,係統框架等結合起來一起說明的,導致看了很多這樣的帖子,還是似懂非懂。
關於USB或者說多數計算機方麵的技術文章,如果有說得明白的,往往都是老外寫的。
所以,為了實現有中文的帖子,也能把問題說明白,所以才有此文的誕生。
所以,簡述此文目的:
- 首先,算為自己學習USB的過程,做個記錄和總結,以備後查。
- 對於其他不懂Linux和USB的人,看了此文後,可以對Linux,USB等有個基本的認識。
- 對於了解Linux和USB的人,搞開發的人,尤其是Linux下USB驅動開發的人,看了此文後,真正能搞懂Linux下USB的Mass Storage的框架,和自己去實現對應的U盤驅動的時候,數據讀寫的前後流程,而其中,係統做了哪些事情,需要我們自己做哪些事情。
總的說來,本人寫任何帖子,要麼不寫,要麼就寫的邏輯清晰,讓人看得明白。
就像某人說的,看了我寫的東西,能達到“醍醐灌頂”的效果,這才是我寫東西的終極目標。
盡可能使得大家不需要有太多的基礎,也能看懂此文。
即不需要對USB以及USB Mass Storage以及Linux有太多知識,然後看了此文,看了此文後,大概清楚這三者是什麼,然後想要在Linux下麵實現USB Mass Storage的驅動的話,自己需要做哪些事情,以及大概怎麼做。
而如果想要實現真正的Linux下U盤驅動開發,那麼最基本的一些知識,包括Linux是啥,USB大概是啥,之類的,那你至少多少有些了解,這也才能看懂後續內容。
了解計算機行業的技術,最好的資料,是官方的規範,其實就是一堆文檔,多數是PDF格式的文件。
關於USB的基礎知識,不像其他多數協議,隻是和軟件相關,USB協議,總的來說,應該是涉及非常多的規範和協議,涉及太多的軟件,硬件,機械等方方麵麵。
之所以出現USB協議涉及內容太多太廣,看起來太繁雜。
關於USB相關的基礎知識,可以參考筆者的另一篇文章:USB基礎知識概論
目錄
- 2.1. USB Mass Storage相關的協議
-
- 2.1.1. USB Mass Storage相關協議簡介
-
- 2.1.1.1. USB MSC Control/Bulk/Interrupt (CBI) Transport
- 2.1.1.2. USB MSC Bulk-Only (BBB) Transport
- 2.1.1.3. USB MSC UFI Command Specification
- 2.1.1.4. USB MSC Bootability Specification
- 2.1.1.5. USB MSC Compliance Test Specification
- 2.1.1.6. USB Lockable Storage Devices Feature Specification
- 2.1.1.7. USB MSC USB Attached SCSI Protocol (UASP)
- 2.1.2. USB MSC的各個協議之間關係總結
- 2.1.3. U盤與USB中的Class,Subclass和Protocol的對應關係
- 2.2. USB Mass Storage相關的軟件實現
【todo】待整理:Linux USB MASS Storage driver流程圖
USB Mass Storage所對應的層次和要實現哪些東西:
PC電腦和U盤之間的關係,以及物理上的組成,可以用下圖表示:
更深入的剖析,對於普通U盤的內部結構,則是一個USB物理接口,加上對應的控製芯片(微控製器(含Nand Flash的控製器)+ USB設備控製器)和一個Nand Flash芯片:
上述PC電腦和U盤的物理關係,以群聯的PS2251-50 USB 2.0 Flash Controller為例,對應的邏輯關係為:
關於U盤容量,再多解釋一句:
一般U盤的大小,就是對應著這個Nand Flash芯片的容量,比如2GB,4GB,8GB等。
當然,比如一個8GB的U盤,內部也可以用兩塊4GB的Nand Flash芯片來構成。
PC和U盤的之間的抽象的邏輯關係,可用下圖來表示:
上圖中,Storage Media,就是我們例子中的Nand Flash芯片。
而例子中的那個控製芯片,是Microcontroller with embedded USB device controller 和Media Controller的集合。
而上圖中的USB MSC(Mass Storage Class) Device,從應用領域來說,可以分為以下幾類:
而像上述例子中那樣的常用的U盤,屬於上圖中的Flash Drive,即,物理上存儲數據的介質用的是Flash Memory,比如例子中的Nand Flash芯片,對應的,Media Controller,也就是Nand Flash的Controller,負責從Nand Flash芯片中讀寫數據。
USB MSC設備中的固件(firmware)或者硬件(hardware),必須要實現下麵這些功能:
- 檢測和響應通用的USB Request和USB總線上的事件。
- 檢測和響應來自USB設備的關於信息或者動作的USB Mass Storage Request。
- 檢測和響應,從USB Transfer中獲得的SCSI Command。這些業界標準的命令,是用來獲得狀態信息,控製設備操作,向存儲介質塊中讀取(read block)和寫入(write block)數據的。
另外,設備如果想要向存儲介質中,創建/讀取/寫入,文件/文件夾的話,那麼就涉及到文件係統,還要實現對應的文件係統。嵌入式係統中常見的文件係統有FAT16或FAT32。
除了本身USB的協議之外,Mass Storage作為其中USB的一種,USB Mass Storage自己又有相關的協議,對應的協議可以去官網下載:
https://www.usb.org/developers/devclass_docs/
中有關於Mass Storage相關的,一堆的協議:
- Mass Storage Class Specification Overview 1.4
- Mass Storage Bulk Only 1.0
- Mass Storage Control/Bulk/Interrupt (CBI) Specification 1.1
- Mass Storage UFI Command Specification 1.0
- Mass Storage Bootability Specification 1.0
- Lockable Mass Storage Specification 1.0 and Adopters Agreement - Lockable Mass Storage IP Disclosure
- USB Attached SCSI Protocol (UASP) v1.0 and Adopters Agreement
說實話,咋一看,這麼多協議,不知道驢年馬月才能看完和真正理解。
不過,等待了解了這些協議的關係之後,會發現,其實需要特別關注和研究的協議,並不是很多,至少很多協議可以不用太關心。
凡事至少得對整體係統有個大致了解後,才能繼續下一步的深入的開發。
所以,我們的目的,首先是要搞懂這麼多協議之間都是啥關係,以及具體寫U盤驅動的話,要看哪些協議。
從上麵那一堆協議的名詞上,我們就能看到,第一個:
Mass Storage Class Specification Overview 1.4
就是對於這麼多協議的概述,其中介紹了各個協議的關係。
下麵就把其中的主要內容摘出來,解釋如下:
關於USB Mass Storage相關的一些協議,都是由一個叫做USB Mass Storage Class Working Group (CWG)的組織定義的,如上所述,包括下麵一些協議:
- USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport
- USB Mass Storage Class Bulk-Only (BBB) Transport
- USB Mass Storage Class Universal Floppy Interface (UFI) Command Specification
- USB Mass Storage Class Bootability Specification
- USB Mass Storage Class Compliance Test Specification
- USB Lockable Storage Devices Feature Specification (LSD FS)
- USB Mass Storage Class USB Attached SCSI Protocol (UASP)
對於這些協議,我們一個個的簡單解釋和分析一下:
我們所關注的U盤,就是所謂的MSC設備,大容量存儲設備。
U盤的功能,就是數據存儲。而對應的數據傳輸,用的是USB中的Bulk Transfer。而Control Transfer是用來發送Class-Specific的信息和Clear Stall。而其他方麵的信息交換,是用Bulk-only協議。
而對於CBI,算是Bulk-only的替代品,也可以用來信息交換,但是隻能用於,full-speed的軟盤(Floppy drive),也不推薦將CBI用於其它新出的MSC設備上。
【總結】
USB MSC Control/Bulk/Interrupt (CBI) 主要用於Floppy設備,對於我們關心的U盤,用不到,不需要太關心,可以忽略之。
如上所述,Bulk-only是USB設備端,此處的U盤和USB Host端,即普通PC,之間信息交換的協議。
Bulk Only Transport,也被簡稱為BOT。
USB MSC中的Bulk-Only 常被叫做BBB,是相對於前麵所說的CBI來說的。
看起來,USB MSC的CBI,是Control/Bulk/Interrupt的簡寫,但是其具體含義是:
-
Control
Control端點用於,除了傳送標準的USB請求之外,還用於通過Class-specific的請求,將命令塊(command block)傳給設備;即Control端點傳送命令塊
-
Bulk
Bulk In和Bulk Out端點用於在主機(Host)和設備(Device)之間數據的傳輸。即,Bulk用於傳送數據
-
Interrupt
Interrupt端點用於(設備向主機)通知命令完成。即Interrupt用於傳送狀態信息
因此,上麵的USB MSC的Control/Bulk/Interrupt,才被簡稱為CBI。
和CBI中的用三種不同的端點來傳送三種類型的信息,而不同的是,Bulk-only傳送這些全部的信息,都之用Bulk端點。
即用Bulk端點來傳送命令塊,數據,狀態,因此,才類似於Control/Bulk/Interrupt被簡稱為CBI一樣,而Bulk/Bulk/Bulk被簡稱為BBB。
【總結】
USB MSC傳輸協議分CBI和BOT,而BOT又稱為BBB。
既然,對於USB MSC設備來說,USB設備和USB主機之間的通信,已經定義了一個CBI規範,那麼為何還要再新定義一個Bulk-only(BBB)呢?
我的理解是,那是因為,最開始USB協議定義的時候,那時候市場上的Floppy Disk還是用的很多的。
所以針對Floppy設備特點,分別定義了多個端點來傳輸不同的信息,即Control端點傳命令塊,Bulk傳數據,Interrupt傳狀態信息,
而後來計算機行業的發展了,Floppy類的設置很少用了,存儲數據的話,多數開始用Flash Memory了,再加上通過合理規劃,可以用同一種端點,即Bulk端點,傳輸上述三種信息,即命令塊,數據,狀態,
因此,隻需要物理上實現一個Bulk端點,節省掉了其他兩個端點:Control端點和Interrupt端點,達到了物理上實現起來方便和節省資源,而達到同樣的信息傳輸的目的。
此部分理解,有待進一步考證。
【總結】
USB MSC Bulk-Only (BBB) 協議,是我們要重點關注的對象。因為我們的U盤和USB主機(PC端)直接信息交互,主要是用此協議。
UFI,即Universal Floppy Interface,因此看名字就知道,是關於軟盤的。
此USB MSC UFI規範,定義了UFI命令集合(Command Set),設計出來此規範,就是用於軟盤的。此UFI命令集合,是基於SCSI-2 和SFF-8070i命令集合的。
【總結】
看完上麵的解釋,就明白了,我們此處關心的是U盤,是USB Flash Memory類型的,不是Floppy Disk類型的,所以,此處也可以不關心,暫忽略之。
目前常見的電腦啟動,很多都是從MSC大容量存儲設備中啟動的,比如硬盤。
因此,設計了這個規範,以使得操作係統可以從USB MSC設備上啟動。關於此規範的具體內容,主要是定義了一些命令和相關的一些數據的定義。
即,如果你想要實現讓操作係統從你的這個MSC設備啟動,那麼你就要實現對應的CDB(Command Descriptor Block,命令描述符塊)或者Data數據。
【總結】
我們主要關心U盤如何和主機數據交互,暫不關心是否能否從此U盤啟動,所以也可不太關心,暫忽略之。
【總結】
無須多解釋,看名字就知道,是一個關於兼容性測試的規範,和我們此處所關心的U盤和主機的數據交互,關係不大,暫忽略之。
“Lockable Storage Devices Feature Specification”,簡稱為 LSD FS。
“Lockable”的意思是,可鎖定,即鎖定以防止其他人訪問或者寫入,即變成隻讀,甚至不允許其他人再訪問。
說白了就是對USB存儲設備的安全控製方麵的規範。
而基於目前還沒有一個標準的規範去定義,如何去控製那些對於USB存儲設備的訪問,所以此處才定義了一個這麼個和訪問控製相關的協議。
此協議可實現允許主機Host或者設備Device去鎖定Lock或者解鎖Unlock 對應的存儲設備。
【總結】
和安全存儲和權限控製相關的協議,我們此處也是暫不關心,可忽略之。
“Attached”顧名思義,是附在某個上麵的,此處即附在SCSI協議的上麵的,即SCSI協議的補充部分。
UASP規範,定義了關於如何在USB 2.0和USB 3.0中,UAS的傳輸標準是如何實現的,並且給出了一些範例和一些推薦的做法。
既然已經有了對應的SCSI協議,用於發送對應命令,實現對應功能。作為U盤等應用的話,直接實現對應的協議,符合對應的規範,不是也就可以實現對應功能了嗎,為何還要另外再弄出一個SSCI的附屬協議UASP?
那是因為,原先的BOT(Bulk Only Transport),雖然協議簡單已實現,適合用於大容量存儲設備中,但其就像一個單線程,不能同時並行執行多個傳輸。
即,對於BOT,每一個由Host發起數據傳輸(transaction),都必須等待設備完成,然後設備再返回對應的已完成狀態信息,然後才能開始下一次數據傳輸。這樣的話,對於整個數據傳輸過程的話,就造成了一個很大(大概有20%)的浪費(overhead)。
而對於USB 3.0來說,速度從USB 2.0的480Mb/s變成了 5.0Gb/s,而如果繼續用BOT的話,那麼相對來說CPU性能的利用率很低,USB傳輸速度也不太高,例如,有研究表明,2.4 GHz Core Duo™的CPU,利用率隻要大概12%,CPU傳輸速度隻有大約250MB/s,而USB 3.0的理論速度是5.0Gb/s=640MB/s,即還不到理論最大速度的一半。
因此,才有了這個UASP,對於SCSI協議進行了補充,以提高USB 2.0的USB總線利用率,和充分利用USB 3.0的全雙工能力,可以使得傳輸速度達到大約400MB/s。此新的協議UASP的實現,也需要對應的新的Host端的軟件,新的Device端的固件(Firmware)。
為了實現設備的向後兼容性,Device同時支持BOT和UAS。
而此UASP規範,定義了就是如何在USB 2.0和USB 3.0上實現對應的UAS協議。
當Host和Device都實現了此UAS協議的話,那麼Host將通過Host端的SCSI Software Stack去訪問Device,而USB的Interface也將從功能上看,變成Host Stack中的另外一個SCSI Host Adapter。Device需要實現SAM4的架構模型,這樣Host也就可以查詢(Queue)Device中的命令了,以及對應性能的提升。
【總結】
為了克服舊的BOT協議的總線利用率不高的缺點,所以定義了新的UAS協議,即UASP,來提升USB的傳輸效率,提升USB速度。
當然,我們此處為了實現U盤功能的話,當然希望性能越高越好了,所以,這個協議也是我們應該好好研究的。
為了說明清楚USB Mass Storage各個協議的關係,我們先給這些協議編個號:
①USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport
②USB Mass Storage Class Bulk-Only (BBB) Transport
③USB Mass Storage Class Universal Floppy Interface (UFI) Command Specification
④USB Mass Storage Class Bootability Specification
⑤USB Mass Storage Class Compliance Test Specification
⑥USB Lockable Storage Devices Feature Specification (LSD FS)
⑦USB Mass Storage Class USB Attached SCSI Protocol (UASP)
直接用圖來表示USB MSC各個協議之間的關係,顯得更加直觀:
如上圖,我們U盤實現的功能,主要就是數據的讀寫,而Device和Host之間的數據通信,主要有兩種:
- CBI:主要用於Floppy設備,所以新的設備,都很少用此協議
- BOT:Bulk-Only Transport,也稱BBB(Bulk/Bulk/Bulk),
而對於BOT/BBB來說,對其提高USB總線利用率,提高了USB速度後,就是對應的UASP協議,故此處稱UASP為BOT的增強版的協議。
協議方麵說完了,再來看看USB Device這一端。
而USB的Device端,根據內部數據存儲的介質類型不同,又分兩種:
- 一種是Floppy設備,對應用的是UFI Command Set;
- 而另外一種,就是我們常見的Flash Memory,對應的是用SCSI Command Set。
而SCSI協議,本身就是有的了,所以不是屬於USB MSC協議範疇,即SCSI隻是和USB MSC相關的協議。
同樣的,對於USB Device本身,如果需要一些用到其他的特性,比如可啟動性,兼容性,可鎖定性等等,那麼分別對應的規範是
④USB Mass Storage Class Bootability Specification
⑤USB Mass Storage Class Compliance Test Specification
⑥USB Lockable Storage Devices Feature Specification (LSD FS)
【總結】
至此,各個協議和規範之間的關係,就很容易理解了。上麵這麼多協議中,其中我們所要關心的,隻有三個規範,如前麵的圖中,已經用星號標識出來了:
-
最需要關心的是BOT,即Host和Device間數據通訊的協議
②USB Mass Storage Class Bulk-Only (BBB) Transport
-
其次,需要關心USB Device內部和數據存儲介質之間通信的協議
SCSI - Small Computer System Interface
-
最後,對於,如果要實現更好的性能,那麼需要關心BOT的升級版
⑦USB Mass Storage Class USB Attached SCSI Protocol (UASP)
對應的,了解USB的都知道,每個設備的描述符中,都有對應下麵這幾個域:
- bInterfaceClass
- bInterfaceSubClass
- bInterfaceProtocol
分別對應著USB的Class,Subclass,Protocol。
而對於我們此處的U盤:
Subclass,所支持的列表如下:
最後更新:2017-04-03 12:56:29
上一篇:
九度題目1342:尋找最長合法括號序列II
下一篇:
regsvr32 注冊.dll的用法
Hibernate聯合主鍵
搭建Gateway向E-MapReduce集群提交作業
一家淘寶老店的14年打拚
展(天津市天士力改(中華人民共和國稅收征收管理法(主席令第四十九號) 2015年8月15日 - 會關於修改〈中華人民共和國文物保護法〉等十二部法律的決定》(主席令第...第八十九條 納稅人、扣繳義務人可以委托稅務代理人代為辦理稅務事宜。 第...)為400
號稱史上最晦澀的算法Paxos,如何變得平易近人?
深度揭秘黑客6種常見攻擊方式
Windows 8 之父明年春天將重返哈佛執教
中國新四大發明背後的“數據智能”
Hibernate的session中的flush
2017國際反病毒大會 亞信安全倡導“消滅移動終端”化解移動威脅