帶你遨遊USB世界

一、什麼是USB

USB的全稱是Universal Serial Bus,通用串行總線。它的出現主要是爲了簡化我的計算機與外圍設備的鏈接，增長易用性。USB支持熱插拔，而且是即插即用的，另外，它還具備很強的可擴展性，傳輸速度也很快，這些特性使支持USB接口的電子設備更易用、更大衆化。

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

二、USB傳輸基礎知識介紹

2.一、USB金字塔型拓撲結構

2.1.一、USB協議基礎

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

2.1.二、NRZI編碼

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

2.1.三、包(packet)格式

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

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

2.1.四、USB數據傳輸規範和約定

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

2. USB傳輸使用小端結構(Little-Endian),一個字節在USB總線上的傳輸前後順序爲：b0 b1 b2 …b7 (與I2C相反,I2C是大端結構)。

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

好比啓動USB傳輸的令牌包名稱

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

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

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

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

2.1.五、四種傳輸模式

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

1. 控制傳輸—— Control Transfers

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

2. 批量傳輸—— Bulk Transfers

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

3. 中斷傳輸—— Interrupt Transfers

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

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

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

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

2.1.六、USB設備結構及描述符

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

一個配置一般有一個或多個接口；

一個接口一般有一個或多個端點；

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

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

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.三、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));

三、USB枚舉

3.一、枚舉示意圖

USB枚舉其實是host檢測到device插入後，經過發送各類標準請求，請device返回各類USB描述符的過程。USB枚舉的示意圖以下：

3.二、USB標準請求的結構

上述說起的USB標準請求的結構以下：

3.二、USB標準請求的結構

上述說起的USB標準請求的結構以下：

3.三、枚舉過程數據流抓取

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

數據示意圖以下：

四、USB gadget驅動分析

4.一、USB gadget功能框架

4.二、USB gadget驅動代碼流程圖

4.三、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

五、USB host驅動分析

5.一、URB

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

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

URB的處理流程：

5.二、鼠標驅動

在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.三、U盤驅動

5.3.一、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.二、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