閱讀609 返回首頁    go 阿裏雲 go 技術社區[雲棲]


如何實現Linux下的U盤(USB Mass Storage)驅動

摘要

本文主要介紹了USB Mass Storage的相關的各種協議之間的關係,以及如何在Linux的USB驅動框架下實現U盤驅動

[注意] 本文提供多種格式供:
在線閱讀 HTML HTMLs PDF CHM TXT RTF
下載(7zip壓縮包) HTML HTMLs PDF CHM TXT RTF

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
  1. 介紹如何在Linux下實現U盤驅動
修訂 0.6 2012-08-09 crl
  1. 通過Docbook發布

版權 © 2012 Crifan, https://crifan.com

本文章遵從:署名-非商業性使用 2.5 中國大陸(CC BY-NC 2.5)


目錄

縮略詞
正文之前
1. 此文目的
2. 閱讀此文所需要的前提知識
3. 聲明
1. USB基本知識
1.1. USB的硬件
1.2. USB相關的協議
1.3. 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.2.1. 為何USB MSC中Bulk-only Transport被叫做 BBB
2.1.1.2.2. 為何已經有了CBI,又再弄出個BBB
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.1.7.1. 已有SCSI協議,為何還要再弄一個UASP
2.1.2. USB MSC的各個協議之間關係總結
2.1.3. U盤與USB中的Class,Subclass和Protocol的對應關係
2.1.3.1. bInterfaceClass=0x08=Mass Storage
2.1.3.2. bInterfaceSubClass=0x06=SCSI Transparent
2.1.3.3. bInterfaceProtocol=0x50=Bulk Only Transport
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數據流向圖

縮略詞

MSC (MSC)

Mass Storage Class

大容量存儲類型

常說的大容量存儲設備,就是此處的MSC設備,最常見的例子就是U盤

SAM4 (SAM4)

ISO/IEC 14776-414, SCSI Architecture Model-4 (SAM-4) (ANSI INCITS 447:2008)

SCSI架構的Mode-4

Spec (Spec)

Specification

規範

正文之前

目錄

1. 此文目的
2. 閱讀此文所需要的前提知識
3. 聲明

1. 此文目的

關於U盤,估計大家都用過。

比如,筆者手上的宇瞻AH320的8G的U盤:

圖 1. U盤

U盤

最常見的用法就是,直接將此8GU盤插到電腦的USB口上,然後係統(Windows的XP或者Linux)就會自動檢測到你的U盤然後生成一個移動盤符,然後你就可以打開對應盤符,讀寫文件數據了。

而此文呢,目的就是,要搞懂,作為驅動開發者來說,對於這樣一個U盤,如何在Linux平台下,去實現U盤驅動,即USB Mass Storage驅動,實現驅動時,需要做哪些事情,以及如何去實現這些事情。

關於USB,其實網上也有不少相關的文章,但是筆者覺得太多帖子,很多帖子,也隻是介紹USB協議,而如何在Linux下麵實現驅動,卻很少提及。或者說是,理論多,實踐少,東一塊,西一塊,很少能把相關知識有機的結合起來,尤其是軟件,硬件,係統框架等結合起來一起說明的,導致看了很多這樣的帖子,還是似懂非懂。

關於USB或者說多數計算機方麵的技術文章,如果有說得明白的,往往都是老外寫的。

所以,為了實現有中文的帖子,也能把問題說明白,所以才有此文的誕生。

所以,簡述此文目的:

  1. 首先,算為自己學習USB的過程,做個記錄和總結,以備後查。
  2. 對於其他不懂Linux和USB的人,看了此文後,可以對Linux,USB等有個基本的認識。
  3. 對於了解Linux和USB的人,搞開發的人,尤其是Linux下USB驅動開發的人,看了此文後,真正能搞懂Linux下USB的Mass Storage的框架,和自己去實現對應的U盤驅動的時候,數據讀寫的前後流程,而其中,係統做了哪些事情,需要我們自己做哪些事情。

總的說來,本人寫任何帖子,要麼不寫,要麼就寫的邏輯清晰,讓人看得明白。

就像某人說的,看了我寫的東西,能達到“醍醐灌頂”的效果,這才是我寫東西的終極目標。

2. 閱讀此文所需要的前提知識

盡可能使得大家不需要有太多的基礎,也能看懂此文。

即不需要對USB以及USB Mass Storage以及Linux有太多知識,然後看了此文,看了此文後,大概清楚這三者是什麼,然後想要在Linux下麵實現USB Mass Storage的驅動的話,自己需要做哪些事情,以及大概怎麼做。

而如果想要實現真正的Linux下U盤驅動開發,那麼最基本的一些知識,包括Linux是啥,USB大概是啥,之類的,那你至少多少有些了解,這也才能看懂後續內容。

3. 聲明

此文不可能麵麵俱到,但是旨在把問題說清楚的目的,又會在具體內容方麵,盡量做到麵麵俱到,因此,也會使得整個文章顯得很臃腫,不過也因此方便了,不了解的人去看懂後續所要解釋的內容。

提及一下,文中一些內容的表述,是中英文摻雜,主要是因為有些含義,用英文表述更加貼切,就懶得再去費時費力翻譯為中文了。

版權所有,歡迎轉載,但請注明作者:crifan。謝謝合作。

水平有限,難免有誤,歡迎任何意見和建議:admin (At) crifan.com

第 1 章 USB基本知識

目錄

1.1. USB的硬件
1.2. USB相關的協議
1.3. USB相關的軟件實現

了解計算機行業的技術,最好的資料,是官方的規範,其實就是一堆文檔,多數是PDF格式的文件。

關於USB的基礎知識,不像其他多數協議,隻是和軟件相關,USB協議,總的來說,應該是涉及非常多的規範和協議,涉及太多的軟件,硬件,機械等方方麵麵。

之所以出現USB協議涉及內容太多太廣,看起來太繁雜。

關於USB相關的基礎知識,可以參考筆者的另一篇文章:USB基礎知識概論

1.1. USB的硬件

1.2. USB相關的協議

1.3. 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.2.1. 為何USB MSC中Bulk-only Transport被叫做 BBB
2.1.1.2.2. 為何已經有了CBI,又再弄出個BBB
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.1.7.1. 已有SCSI協議,為何還要再弄一個UASP
2.1.2. USB MSC的各個協議之間關係總結
2.1.3. U盤與USB中的Class,Subclass和Protocol的對應關係
2.1.3.1. bInterfaceClass=0x08=Mass Storage
2.1.3.2. bInterfaceSubClass=0x06=SCSI Transparent
2.1.3.3. bInterfaceProtocol=0x50=Bulk Only Transport
2.2. USB Mass Storage相關的軟件實現

【todo】待整理:Linux USB MASS Storage driver流程圖

USB Mass Storage所對應的層次和要實現哪些東西:

圖 2.1. USB Mass Storage Framework

USB Mass Storage Framework

PC電腦和U盤之間的關係,以及物理上的組成,可以用下圖表示:

圖 2.2. PC和U盤

PC和U盤

更深入的剖析,對於普通U盤的內部結構,則是一個USB物理接口,加上對應的控製芯片(微控製器(含Nand Flash的控製器)+ USB設備控製器)和一個Nand Flash芯片:

圖 2.3. PC和U盤的芯片內部結構

PC和U盤的芯片內部結構

上述PC電腦和U盤的物理關係,以群聯的PS2251-50 USB 2.0 Flash Controller為例,對應的邏輯關係為:

圖 2.4. PC和U盤的內部邏輯框圖

PC和U盤的內部邏輯框圖

關於U盤容量,再多解釋一句:

一般U盤的大小,就是對應著這個Nand Flash芯片的容量,比如2GB,4GB,8GB等。

當然,比如一個8GB的U盤,內部也可以用兩塊4GB的Nand Flash芯片來構成。

PC和U盤的之間的抽象的邏輯關係,可用下圖來表示:

圖 2.5. PC和USB MSC設備

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的分類

USB MSC的分類

而像上述例子中那樣的常用的U盤,屬於上圖中的Flash Drive,即,物理上存儲數據的介質用的是Flash Memory,比如例子中的Nand Flash芯片,對應的,Media Controller,也就是Nand Flash的Controller,負責從Nand Flash芯片中讀寫數據。

USB MSC設備中的固件(firmware)或者硬件(hardware),必須要實現下麵這些功能:

  1. 檢測和響應通用的USB Request和USB總線上的事件。
  2. 檢測和響應來自USB設備的關於信息或者動作的USB Mass Storage Request。
  3. 檢測和響應,從USB Transfer中獲得的SCSI Command。這些業界標準的命令,是用來獲得狀態信息,控製設備操作,向存儲介質塊中讀取(read block)和寫入(write block)數據的。

另外,設備如果想要向存儲介質中,創建/讀取/寫入,文件/文件夾的話,那麼就涉及到文件係統,還要實現對應的文件係統。嵌入式係統中常見的文件係統有FAT16或FAT32。

2.1. USB Mass Storage相關的協議

除了本身USB的協議之外,Mass Storage作為其中USB的一種,USB Mass Storage自己又有相關的協議,對應的協議可以去官網下載:

https://www.usb.org/developers/devclass_docs/

中有關於Mass Storage相關的,一堆的協議:

說實話,咋一看,這麼多協議,不知道驢年馬月才能看完和真正理解。

不過,等待了解了這些協議的關係之後,會發現,其實需要特別關注和研究的協議,並不是很多,至少很多協議可以不用太關心。

2.1.1. USB Mass Storage相關協議簡介

凡事至少得對整體係統有個大致了解後,才能繼續下一步的深入的開發。

所以,我們的目的,首先是要搞懂這麼多協議之間都是啥關係,以及具體寫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)

對於這些協議,我們一個個的簡單解釋和分析一下:

2.1.1.1. USB MSC Control/Bulk/Interrupt (CBI) Transport

我們所關注的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盤,用不到,不需要太關心,可以忽略之。

2.1.1.2. USB MSC Bulk-Only (BBB) Transport

如上所述,Bulk-only是USB設備端,此處的U盤和USB Host端,即普通PC,之間信息交換的協議。

Bulk Only Transport,也被簡稱為BOT。

2.1.1.2.1. 為何USB MSC中Bulk-only Transport被叫做 BBB

USB MSC中的Bulk-Only 常被叫做BBB,是相對於前麵所說的CBI來說的。

看起來,USB MSC的CBI,是Control/Bulk/Interrupt的簡寫,但是其具體含義是:

  1. Control

    Control端點用於,除了傳送標準的USB請求之外,還用於通過Class-specific的請求,將命令塊(command block)傳給設備;即Control端點傳送命令塊

  2. Bulk

    Bulk In和Bulk Out端點用於在主機(Host)和設備(Device)之間數據的傳輸。即,Bulk用於傳送數據

  3. 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。

2.1.1.2.2. 為何已經有了CBI,又再弄出個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端)直接信息交互,主要是用此協議。

2.1.1.3. USB MSC UFI Command Specification

UFI,即Universal Floppy Interface,因此看名字就知道,是關於軟盤的。

此USB MSC UFI規範,定義了UFI命令集合(Command Set),設計出來此規範,就是用於軟盤的。此UFI命令集合,是基於SCSI-2 和SFF-8070i命令集合的。

【總結】

看完上麵的解釋,就明白了,我們此處關心的是U盤,是USB Flash Memory類型的,不是Floppy Disk類型的,所以,此處也可以不關心,暫忽略之。

2.1.1.4. USB MSC Bootability Specification

目前常見的電腦啟動,很多都是從MSC大容量存儲設備中啟動的,比如硬盤。

因此,設計了這個規範,以使得操作係統可以從USB MSC設備上啟動。關於此規範的具體內容,主要是定義了一些命令和相關的一些數據的定義。

即,如果你想要實現讓操作係統從你的這個MSC設備啟動,那麼你就要實現對應的CDB(Command Descriptor Block,命令描述符塊)或者Data數據。

【總結】

我們主要關心U盤如何和主機數據交互,暫不關心是否能否從此U盤啟動,所以也可不太關心,暫忽略之。

2.1.1.5. USB MSC Compliance Test Specification

【總結】

無須多解釋,看名字就知道,是一個關於兼容性測試的規範,和我們此處所關心的U盤和主機的數據交互,關係不大,暫忽略之。

2.1.1.6. USB Lockable Storage Devices Feature Specification

“Lockable Storage Devices Feature Specification”,簡稱為 LSD FS。

“Lockable”的意思是,可鎖定,即鎖定以防止其他人訪問或者寫入,即變成隻讀,甚至不允許其他人再訪問。

說白了就是對USB存儲設備的安全控製方麵的規範。

而基於目前還沒有一個標準的規範去定義,如何去控製那些對於USB存儲設備的訪問,所以此處才定義了一個這麼個和訪問控製相關的協議。

此協議可實現允許主機Host或者設備Device去鎖定Lock或者解鎖Unlock 對應的存儲設備。

【總結】

和安全存儲和權限控製相關的協議,我們此處也是暫不關心,可忽略之。

2.1.1.7. USB MSC USB Attached SCSI Protocol (UASP)

“Attached”顧名思義,是附在某個上麵的,此處即附在SCSI協議的上麵的,即SCSI協議的補充部分。

UASP規範,定義了關於如何在USB 2.0和USB 3.0中,UAS的傳輸標準是如何實現的,並且給出了一些範例和一些推薦的做法。

2.1.1.7.1. 已有SCSI協議,為何還要再弄一個UASP

既然已經有了對應的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盤功能的話,當然希望性能越高越好了,所以,這個協議也是我們應該好好研究的。

2.1.2. USB MSC的各個協議之間關係總結

為了說明清楚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

USB Storage Class Protocol Relation

如上圖,我們U盤實現的功能,主要就是數據的讀寫,而Device和Host之間的數據通信,主要有兩種:

  1. CBI:主要用於Floppy設備,所以新的設備,都很少用此協議
  2. BOT:Bulk-Only Transport,也稱BBB(Bulk/Bulk/Bulk),

而對於BOT/BBB來說,對其提高USB總線利用率,提高了USB速度後,就是對應的UASP協議,故此處稱UASP為BOT的增強版的協議。

協議方麵說完了,再來看看USB Device這一端。

而USB的Device端,根據內部數據存儲的介質類型不同,又分兩種:

  1. 一種是Floppy設備,對應用的是UFI Command Set;
  2. 而另外一種,就是我們常見的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)

【總結】

至此,各個協議和規範之間的關係,就很容易理解了。上麵這麼多協議中,其中我們所要關心的,隻有三個規範,如前麵的圖中,已經用星號標識出來了:

  1. 最需要關心的是BOT,即Host和Device間數據通訊的協議

    USB Mass Storage Class Bulk-Only (BBB) Transport

  2. 其次,需要關心USB Device內部和數據存儲介質之間通信的協議

    SCSI - Small Computer System Interface

  3. 最後,對於,如果要實現更好的性能,那麼需要關心BOT的升級版

    USB Mass Storage Class USB Attached SCSI Protocol (UASP)

2.1.3. U盤與USB中的Class,Subclass和Protocol的對應關係

對應的,了解USB的都知道,每個設備的描述符中,都有對應下麵這幾個域:

  • bInterfaceClass
  • bInterfaceSubClass
  • bInterfaceProtocol

分別對應著USB的Class,Subclass,Protocol。

而對於我們此處的U盤:

2.1.3.1. bInterfaceClass=0x08=Mass Storage

Class就是USB Mass Storage Class,

2.1.3.2. bInterfaceSubClass=0x06=SCSI Transparent

Subclass,所支持的列表如下:

圖 2.8. SubClass Codes Mapped to Command Block Specifications

SubClass Codes Mapped to Command Block Specifications

2.1.3.3. bInterfaceProtocol=0x50=Bulk Only Transport

Protocol,所支持的列表如下:

圖 2.9. Mass Storage Transport Protocol

Mass Storage Transport Protocol

從上麵這些規範中所定義的支持的協議來看,加上顏色框的那幾個,也就是我們前麵所解釋過的,需要我們關心和研究的協議,即SCSI,BBB和UAS。

2.2. USB Mass Storage相關的軟件實現

第 3 章 實現U盤驅動的整個流程是什麼樣的

USB數據流向圖:

圖 3.1. USB數據流向圖

USB數據流向圖

第 4 章 Linux係統下,USB驅動的框架已經做了哪些事情

第 5 章 Linux下實現U盤驅動,自己需要做哪些事情以及如何做

最後更新:2017-04-03 12:56:29

  上一篇:go 九度題目1342:尋找最長合法括號序列II
  下一篇:go regsvr32 注冊.dll的用法