帶你遨游USB世界

1、什麼是USB

USB的全稱是Universal Serial Bus,通用串列匯流排。它的出現主要是為了簡化個人電腦與外圍設備的連接，增加易用性。USB支持熱插拔，並且是即插即用的，另外，它還具有很強的可擴展性，傳輸速度也很快，這些特性使支持USB介面的電子設備更易用、更大眾化。

本文將從USB協議、枚舉流程、host和device驅動等各方面，全面介紹Linux USB模塊的工作原理和代碼流程，下麵就請隨我一起，遨游多姿多彩而又複雜嚴謹的USB世界吧~

2、USB傳輸基礎知識介紹

2.1、USB金字塔型拓撲結構

2.1.1、USB協議基礎

塔頂為USB主控制器和根集線器(Root Hub)，下麵接USB集線器(Hub)，集線器將一個USB口擴展為多個USB口，USB2.0規定集線器的層數最多為6層，理論上一個USB主控制器最多可接127個設備，因為協議規定USB設備具有一個7 bit的地址(取值範圍為0~127，而地址0是保留給未初始化的設備使用的)。

2.1.2、NRZI編碼

USB採用差分信號傳輸，使用的是如上圖所示的NRZI編碼方式：數據為0時，電平翻轉；數據為1時，電平不翻轉。如果出現6個連續的數據1，則插入一個數據0，強制電平翻轉，以便時鐘同步。上面的一條線表示的是原始數據序列，下麵的一條線表示的是經過NRZI編碼後的數據序列。

2.1.3、包(packet)格式

USB匯流排上的傳輸數據是以包為基本單位的，包格式如上圖所示。根據PID的不同，USB協議中規定的包類型有令牌包、數據包、握手包和特殊包等。

USB晶元（硬體）會完成CRC校驗、位填充、PID識別、數據包切換、握手等協議處理。

2.1.4、USB數據傳輸規範和約定

1. USB傳輸是主從模式，主機負責發起數據傳輸過程，從機負責應答。

2. USB傳輸使用小端結構(Little-Endian),一個位元組在USB匯流排上的傳輸先後順序為：b0 b1 b2 …b7 (與I2C相反,I2C是大端結構)。

3. 數據傳輸方向均以主機為參考

比如啟動USB傳輸的令牌包名稱

IN令牌包 用來通知設備返回一個數據包

數據包的傳輸方向：主機←從機( IN )

OUT令牌包 用來通知設備將要輸出一個數據包

數據包的傳輸方向：主機→從機( OUT )

2.1.5、四種傳輸模式

針對不同的數據傳輸場景，USB分為四種數據傳輸模式，這四種傳輸模式分別由不同的包(packet)組成，並且有不同的數據處理策略。每種數據傳輸模式的流程示意圖以及應用場景如下：

1. 控制傳輸—— Control Transfers

用於枚舉過程，要保證數據傳輸過程的數據完整性。

2. 批量傳輸—— Bulk Transfers

用於數據量大、對實時性要求不高的場合，如U盤。

3. 中斷傳輸—— Interrupt Transfers

用於數據量小的場合，保證查詢頻率，如滑鼠、鍵盤。

4. 同步傳輸(等時傳輸)—— Isochronous Transfers

用於數據量大、同時對實時性要求較高的場合，如音視頻。

不保證數據完整性，沒有ACK/NAK應答包，不進行數據重傳。

2.1.6、USB設備結構及描述符

一個USB設備通常有一個或多個配置，但在同一時刻只能有一個配置；

一個配置通常有一個或多個介面；

一個介面通常有一個或多個端點；

驅動是綁定到USB介面上的，而不是整個USB設備。

枚舉過程中，device將各種描述符返回給host。

2.2、Linux USB驅動總體結構

Linux USB驅動總體結構圖

從Host側看，在Linux驅動中，處於USB驅動最底層的是USB主機控制器硬體，在其上運行的是USB主機控制器驅動，在主機控制器上的為USB核心層，再上層為USB設備驅動層（插入主機上的U盤、滑鼠、USB轉串口等設備驅動）。主機控制器驅動負責識別和控制插入其中的USB設備，USB設備驅動控制USB設備如何與主機通信，USB Core則負責USB驅動管理和協議處理的主要工作。

從Device側看，UDC驅動程式直接訪問硬體，控制USB設備和主機間的底層通信。Gadget API是UDC驅動程式回調函數的包裝。Gadget Driver具體控制USB設備功能的實現。

2.3、USB描述符

對應上述USB設備的構成，USB採用描述符來描述USB設備的屬性，在USB協議的第九章(chaper 9)中，有對USB描述符的詳細說明，在Linux驅動的以下文件中，定義了USB描述符的結構體，文件名直接命名為ch9.h。

設備描述符結構體

/* USB_DT_DEVICE: Device descriptor */

struct usb_device_descriptor {

__u8 bLength; //該描述符結構體大小（18位元組）

__u8 bDescriptorType; //描述符類型（本結構體中固定為0x01)

__le16 bcdUSB; //USB 版本號

__u8 bDeviceClass; //設備類代碼（由USB官方分配）

__u8 bDeviceSubClass; //子類代碼（由USB官方分配）

__u8 bDeviceProtocol; //設備協議代碼（由USB官方分配）

__u8 bMaxPacketSize0; //端點0的最大包大小（有效大小為8,16,32,64）

__le16 idVendor; //生產廠商編號（由USB官方分配）

__le16 idProduct; //產品編號（製造廠商分配）

__le16 bcdDevice; //設備出廠編號

__u8 iManufacturer; //設備廠商字元串索引

__u8 iProduct; //產品描述字元串索引

__u8 iSerialNumber; //設備序列號字元串索引

__u8 bNumConfigurations; //當前速度下能支持的配置數量

} __attribute__ ((packed));

配置描述符結構體

struct usb_config_descriptor {

__u8 bLength; //該描述符結構體大小

__u8 bDescriptorType; //描述符類型（本結構體中固定為0x02)

__le16 wTotalLength; //此配置返回的所有數據大小

__u8 bNumInterfaces; //此配置的介面數量

__u8 bConfigurationValue; //Set_Configuration 命令所需要的參數值

__u8 iConfiguration; //描述該配置的字元串的索引值

__u8 bmAttributes; //供電模式的選擇

__u8 bMaxPower; //設備從匯流排提取的最大電流

} __attribute__ ((packed));

介面描述符結構體

struct usb_interface_descriptor {

__u8 bLength; //該描述符結構大小

__u8 bDescriptorType; //介面描述符的類型編號(0x04）

__u8 bInterfaceNumber; //介面描述符的類型編號(0x04）

__u8 bAlternateSetting; //介面描述符的類型編號(0x04）

__u8 bNumEndpoints; //該介面使用的端點數，不包括端點0

__u8 bInterfaceClass; //介面類型

__u8 bInterfaceSubClass; //介面子類型

__u8 bInterfaceProtocol; //介面遵循的協議

__u8 iInterface; //描述該介面的字元串索引值

} __attribute__ ((packed));

端點描述符結構體

struct usb_endpoint_descriptor {

__u8 bLength; //端點描述符位元組數大小（7個位元組）

__u8 bDescriptorType; //端點描述符類型編號（0x05)

__u8 bEndpointAddress; //端點地址及輸入輸出屬性

__u8 bmAttributes; //端點的傳輸類型屬性

__le16 wMaxPacketSize; //端點收、發的最大包大小

__u8 bInterval; //主機查詢端點的時間間隔

/* NOTE: these two are _only_ in audio endpoints. */

/* use USB_DT_ENDPOINT*_SIZE in bLength, not sizeof. */

__u8 bRefresh; //音效卡用到的變數

__u8 bSynchAddress;

} __attribute__ ((packed));

3、USB枚舉

3.1、枚舉示意圖

USB枚舉實際上是host檢測到device插入後，通過發送各種標準請求，請device返回各種USB描述符的過程。USB枚舉的示意圖如下：

3.2、USB標準請求的結構

上述提及的USB標準請求的結構如下：

3.2、USB標準請求的結構

上述提及的USB標準請求的結構如下：

3.3、枚舉過程數據流抓取

用Bus Hound抓取的枚舉過程數據流，device側USB配置（功能組合）為mtp+adb

數據示意圖如下：

4、USB gadget驅動分析

4.1、USB gadget功能框架

4.2、USB gadget驅動代碼流程圖

4.3、MTP interface開機啟動流程代碼分析

根據上面所講的結構框圖和代碼流程圖，結合MTP interface的實際運行流程，分析如下：

1）系統開機時，kernel啟動init進程啟動zygote啟動孵化出SystemServer進程USB Service等一系列Service啟動UsbManager啟動UsbDeviceManager啟動。

2）UsbDeviceManager.java

3）init.qcom.usb.rc

usb屬性配置文件

4）android.c

接收屬性節點的值；向framework發送usb狀態改變的uevent

5）f_mtp.c

mtp驅動文件

映射到文件節點/dev/mtp_usb ：

配置mtp interface的描述符：

4.4 MTP傳輸啟動流程代碼分析

在"PC和Android設備建立MTP連接"後，UsbManager向MtpReceiver發送廣播，接著MtpReceiver會啟動MtpService，MtpService會啟動MtpServer(Java層)，MtpServer(Java)層會調用底層的JNI函數。在JNI中，會打開MTP文件節點"/dev/mtp_usb"，然後調用MtpServer對象的run()方法不斷的從中讀取消息併進行處理。

1）frameworks\av\media\mtp\MtpServer.cpp

2）kernel\drivers\usb\gadget\f_mtp.c

5、USB host驅動分析

5.1、URB

USB請求塊(USB Request Block,URB)是USB設備驅動中用來描述與USB設備通信所用的基本載體和核心數據結構。

一個URB用來向一個特定USB設備的特定USB端點發送數據或接收數據。設備中的每個端點都處理一個URB隊列。

URB的處理流程：

5.2、滑鼠驅動

在Linux kernel中，drivers\hid\usbhid\hiddev.c和drivers\hid\usbhid\usbmouse.c兩個驅動文件均可以支持USB滑鼠，具體使用哪個驅動，取決於kernel的編譯配置。下麵我們就以drivers\hid\usbhid\usbmouse.c這個驅動文件為例，分析USB滑鼠的驅動代碼流程。

USB滑鼠遵循USB HID(Human Interface Device)規範。

在probe中探測設備是否符合HID規範，並且創建和初始化URB:

在usb_mouse_open函數中提交URB:

執行回調函數，向user space上報input事件：

5.3、U盤驅動

5.3.1、U盤驅動框架

如上圖所示，USB Device Driver識別到U盤設備後，還需要將U盤模擬為SCSI(小型電腦系統介面)設備，才能與User Space進行數據傳輸。相關代碼路徑如下：

drivers\usb\storage\unusual_devs.h //添加非常規設備的參數

drivers\usb\storage\usb.c          //USB Device Driver

drivers\usb\storage\scsiglue.c      //SCSI Driver

5.3.2、U盤mount流程

Linux Kernel將U盤模擬為SCSI設備後，會向vold(volume deamon)發送如下格式的Uevent：

vold的NetlinkManager接收到uevent消息後，只處理SUBSYSTEM=block的消息：

system\vold\NetlinkHandler.cpp

並按以下流程完成U盤的mount：

其中vold的process_config函數會根據配置文件配置VM對象：

system\vold\main.cpp

配置文件路徑：

device\qcom\msm_xxx\fstab.qcom

最後，vold的handlePartitionAdded函數識別並mount設備的所有分區:

system\vold\DirectVolume.cpp