摘要
本文主要介紹了usb mass storage的相關的各種協定之間的關系，以及如何在linux的usb驅動架構下實作u盤驅動
線上閱讀
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/html/usb_disk_driver.html">html</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/htmls/usb_disk_driver.html">htmls</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/pdf/usb_disk_driver.pdf">pdf</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/chm/usb_disk_driver.chm">chm</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/txt/usb_disk_driver.txt">txt</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/rtf/usb_disk_driver.rtf">rtf</a>
下載下傳（7zip壓縮包）
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/html/usb_disk_driver.html.7z">html</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/htmls/usb_disk_driver.html.7z">htmls</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/pdf/usb_disk_driver.pdf.7z">pdf</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/chm/usb_disk_driver.chm.7z">chm</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/txt/usb_disk_driver.txt.7z">txt</a>
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/rtf/usb_disk_driver.rtf.7z">rtf</a>
html版本的線上位址為：
<a target="_blank" href="http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/html/usb_disk_driver.html">http://www.crifan.com/files/doc/docbook/usb_disk_driver/release/html/usb_disk_driver.html</a>
2012-08-09
修訂曆史
修訂 0.4
2011-07-01
crl
介紹如何在linux下實作u盤驅動
修訂 0.6
通過docbook釋出
<a target="_blank"></a>
目錄
<dl></dl>
<dd></dd>
插圖清單
<dt></dt>
mass storage class
大容量存儲類型
常說的大容量儲存設備，就是此處的msc裝置，最常見的例子就是u盤
iso/iec 14776-414, scsi architecture model-4 (sam-4) (ansi incits 447:2008)
scsi架構的mode-4
specification
規範
關于u盤，估計大家都用過。
比如，筆者手上的宇瞻ah320的8g的u盤：
圖 1. 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大概是啥，之類的，那你至少多少有些了解，這也才能看懂後續内容。
此文不可能面面俱到，但是旨在把問題說清楚的目的，又會在具體内容方面，盡量做到面面俱到，是以，也會使得整個文章顯得很臃腫，不過也是以友善了，不了解的人去看懂後續所要解釋的内容。
提及一下，文中一些内容的表述，是中英文摻雜，主要是因為有些含義，用英文表述更加貼切，就懶得再去費時費力翻譯為中文了。
版權所有，歡迎轉載，但請注明作者：crifan。謝謝合作。
水準有限，難免有誤，歡迎任何意見和建議：admin (at) crifan.com
了解計算機行業的技術，最好的資料，是官方的規範，其實就是一堆文檔，多數是pdf格式的檔案。
關于usb的基礎知識，不像其他多數協定，隻是和軟體相關，usb協定，總的來說，應該是涉及非常多的規範和協定，涉及太多的軟體，硬體，機械等方方面面。
之是以出現usb協定涉及内容太多太廣，看起來太繁雜。
usb mass storage所對應的層次和要實作哪些東西：
圖 2.1. usb mass storage framework
pc電腦和u盤之間的關系，以及實體上的組成，可以用下圖表示：
圖 2.2. pc和u盤
更深入的剖析，對于普通u盤的内部結構，則是一個usb實體接口，加上對應的控制晶片（微控制器（含nand flash的控制器）+ usb裝置控制器）和一個nand flash晶片：
圖 2.3. pc和u盤的晶片内部結構
上述pc電腦和u盤的實體關系，以群聯的ps2251-50 usb 2.0 flash controller為例，對應的邏輯關系為：
圖 2.4. pc和u盤的内部邏輯框圖
關于u盤容量，再多解釋一句：
一般u盤的大小，就是對應着這個nand flash晶片的容量，比如2gb，4gb，8gb等。
當然，比如一個8gb的u盤，内部也可以用兩塊4gb的nand flash晶片來構成。
pc和u盤的之間的抽象的邏輯關系，可用下圖來表示：
圖 2.5. pc和usb msc裝置
上圖中，storage media，就是我們例子中的nand flash晶片。
而例子中的那個控制晶片，是microcontroller with embedded usb device controller 和media controller的集合。
而上圖中的usb msc（mass storage class） device，從應用領域來說，可以分為以下幾類：
圖 2.6. usb msc的分類
而像上述例子中那樣的常用的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自己又有相關的協定，對應的協定可以去官網下載下傳：
<a target="_blank" href="http://www.usb.org/developers/devclass_docs/">http://www.usb.org/developers/devclass_docs/</a>
中有關于mass storage相關的，一堆的協定：
<a target="_blank" href="http://www.usb.org/developers/devclass_docs/mass_storage_specification_overview_v1.4_2-19-2010.pdf">mass storage class specification overview 1.4</a>
<a target="_blank" href="http://www.usb.org/developers/devclass_docs/usbmassbulk_10.pdf">mass storage bulk only 1.0</a>
<a target="_blank" href="http://www.usb.org/developers/devclass_docs/usb_msc_cbi_1.1.pdf">mass storage control/bulk/interrupt (cbi) specification 1.1</a>
<a target="_blank" href="http://www.usb.org/developers/devclass_docs/usbmass-ufi10.pdf">mass storage ufi command specification 1.0</a>
<a target="_blank" href="http://www.usb.org/developers/devclass_docs/usb_msc_boot_1.0.pdf">mass storage bootability specification 1.0</a>
<a target="_blank" href="http://www.usb.org/developers/devclass_docs/lockable_mass_storage_spec_and_adopters_agreement.zip">lockable mass storage specification 1.0 and adopters agreement - lockable mass storage ip disclosure</a>
<a target="_blank" href="http://www.usb.org/developers/devclass_docs/uasp_1_0.zip">usb attached scsi protocol (uasp) v1.0 and adopters agreement</a>
說實話，咋一看，這麼多協定，不知道驢年馬月才能看完和真正了解。
不過，等待了解了這些協定的關系之後，會發現，其實需要特别關注和研究的協定，并不是很多，至少很多協定可以不用太關心。
凡事至少得對整體系統有個大緻了解後，才能繼續下一步的深入的開發。
是以，我們的目的，首先是要搞懂這麼多協定之間都是啥關系，以及具體寫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各個協定之間的關系，顯得更加直覺：
圖 2.7. usb storage class protocol relation
如上圖，我們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本身，如果需要一些用到其他的特性，比如可啟動性，相容性，可鎖定性等等，那麼分别對應的規範是
至此，各個協定和規範之間的關系，就很容易了解了。上面這麼多協定中，其中我們所要關心的，隻有三個規範，如前面的圖中，已經用星号辨別出來了：
最需要關心的是bot，即host和device間資料通訊的協定
其次，需要關心usb device内部和資料存儲媒體之間通信的協定
scsi - small computer system interface
最後，對于，如果要實作更好的性能，那麼需要關心bot的更新版
對應的，了解usb的都知道，每個裝置的描述符中，都有對應下面這幾個域：
binterfaceclass
binterfacesubclass
binterfaceprotocol
分别對應着usb的class，subclass，protocol。
而對于我們此處的u盤：
class就是usb mass storage class，
subclass，所支援的清單如下：
圖 2.8. subclass codes mapped to command block specifications
protocol，所支援的清單如下：
圖 2.9. mass storage transport protocol
從上面這些規範中所定義的支援的協定來看，加上顔色框的那幾個，也就是我們前面所解釋過的，需要我們關心和研究的協定，即scsi，bbb和uas。
usb資料流向圖：
圖 3.1. usb資料流向圖