NO IMAGE

USB協議

1 USB主機系統

在USB主機系統中,通過根集線器與外部USB從機裝置相連的處理晶片,稱為USB主機控制器。USB主機控制器包含硬體、軟體和韌體一部分。

2 USB裝置系統

USB裝置按功能分為兩部分:集線器(Hub)和功能部件。從下圖可知,主機通過根集線器連線到各種外圍裝置(集線器和功能部件)。
image

3 主機和裝置之間通訊模型

image

上圖展示了USB主機和USB裝置之間的資料傳輸過程。在裝置端,USB裝置將非USB格式的資料進行打包處理,轉換成USB格式的資料包,然後傳遞到鏈路層,經過硬體處理、傳遞到物理層,由物理層通過PHY以資料流的形式傳輸到主機。

USB主機在USB裝置和USB主機之間發起的傳輸過程,稱為事務。每次事務以2到3個資料包的形式進行USB匯流排傳輸。每個資料包包含2到3個步驟:
1) USB主機控制器向USB裝置發出命令
2) USB控制器和USB裝置之間傳遞讀寫請求,其方向取決於第一部分的命令是讀還是寫
3) 握手訊號。
USB主機控制器向USB裝置傳送事務型別請求,通過分組識別符號來進行識別。

4 USB分組標識

主機和裝置之間進行操作,通過分組標識(PID)來進行傳輸。資料包傳輸格式一般由:PID、資料/控制資訊、CRC校驗碼組成。

常見的PID主要包括令牌、資料、握手等型別組成。PID碼以特定的方式組成,如下表所示:
image

PID分組碼是資料傳輸流程中的重要元素。無論硬體還是軟體,都要對PID分組碼進行分析,從而做出正確響應。USB主機和裝置嚴格按照PID分組碼資訊進行資訊互動。

5 資料包傳輸模式

當USB裝置連線到集線器,集線器狀態將發生相應的變化,並將狀態變化資訊傳遞給USB主機。USB主機通過根集線器向USB裝置傳送命令,獲取USB裝置的各種資訊,包含USB裝置傳輸型別、ID號、Product、USB速度等資訊。

USB主機和USB裝置之間的資料傳輸共有四種型別:控制傳輸、批量傳輸、中斷傳輸和同頻傳輸。與之對應,USB主機和USB裝置之間有四種事務:控制事務、批量事務、中斷事務和同步事務。

5.1 批量(Bulk)傳輸

image

作用:主要用於非實時性傳輸,資料包較大而延時要求較低。
特點:資料傳輸準備即可,採用批量傳輸模式的USB從機裝置,如U盤資料傳輸分三個階段:

1) 令牌階段:主機傳送請求,USB裝置依據請求PID來判斷IN或OUT傳輸
2) 資料傳輸階段:依據令牌階段的IN或OUT傳輸,來決定資料傳輸為DATA0或DATA1來進行資料傳輸
3) 握手階段:接收資訊的一方傳送ACK訊號以表示接收成功;若為NAK,表示傳送失敗;STALL表示不可預知的錯誤

5.2 控制(Control)傳輸

image

作用:USB傳輸過程必須支援的傳輸模式。USB主機為了獲取裝置描述符、ID、Product等資訊,向USB裝置傳送相應的PID命令。

特點:唯一可以進行IN/OUT傳輸的傳輸模式。

資料寬度:控制傳輸方式可以以8、16、32或64位元組的資料進行傳輸,這取決於裝置的傳輸速度。
USB主機和裝置之間必須支援控制傳輸,通過端點0進行資料傳輸。控制傳輸分為令牌、資料傳輸和握手階段。

5.3 中斷傳輸事務

image

作用:按照一定時刻輪詢裝置是否有中斷傳輸請求

特點:查詢頻率取決於端點的模式結構,從1到255ms不等

中斷傳輸主要用於實時性要求非常高的從機裝置,如鍵盤操縱桿和Mouse等

傳輸過程也分為令牌階段、資料傳輸和握手階段

6 USB描述符

USB協議中共定義了以下四種描述符:
1) 裝置描述符
2) 配置描述符
3) 介面描述符
4) 端點描述符

其關係如下圖所示:

image

6.1 裝置描述符

每個USB裝置都有一個唯一的裝置描述符,如下表所示:

image

6.2 配置描述符

每個USB裝置都有預設的配置描述符,支援至少一個介面,每個配置描述符如下表:

image

6.3 介面描述符

裝置應至少支援一個介面,如:塊傳輸資料介面,部分裝置可能支援其它的介面。複合裝置可以支援額外介面,以支援音訊和視訊功能。標準中並沒有定義此類介面。介面可能有多個可選設定,主機將會檢查每個可選的設定。

6.4 端點描述符

每個裝置至少支援控制端點0。USB裝置應該支援三類端點:控制端點、輸入端點和輸出端點。

image

image

OTG協議

OTG裝置採用Mini-AB插座,相對於傳統的USB資料線,Mini-AB介面多了一根資料線ID,ID線是否接入將Mini-AB介面分為Mini-A和Mini-B介面兩種型別。在OTG裝置之間資料連線的過程中,通過OTG資料線Mini-A和Mini-B介面來確定OTG裝置的主從:接入Mini-A介面的裝置預設為A裝置(主機裝置);接入Mini-B介面的裝置,預設為B裝置(從裝置)。

A裝置和B裝置無需交換電纜介面,即可通過主機交換協議(HNP)實現A、B裝置之間的角色互換。同時,為了節省電源,OTG允許匯流排空閒時A裝置判斷電源。此時,若B裝置希望使用匯流排,可以通過會話請求協議(SRP)請求A裝置提供電源。

2.1 HNP(主機交換)協議

當Mini-A介面接入A裝置並確定A裝置為主機時;若B裝置希望成為主機,則A裝置向B裝置發SetFeature命令,允許B裝置進行主機交換。B裝置檢測到匯流排掛起5ms後,即掛起D 並啟動HNP,使匯流排處於SE0狀態。此時A裝置檢測到匯流排處於SE0狀態,即認為B裝置發起主機交換,A裝置進行響應。待B裝置發現D 線為高電平而D-線為低電平(J狀態),表示A裝置識別了B裝置的HNP請求。B裝置開始匯流排復位並具有匯流排控制權,主機交換協議完成。

2.2 SRP(會話請求)協議

對於主機,要求能響應會話請求;對於裝置,僅要求能夠發起SRP協議。OTG裝置,不僅要求發起SRP,而且還能響應SRP請求。

SRP分為資料線脈衝調製和電壓脈衝調兩種方式,B裝置發起SRP必須滿足以下兩個條件:
1) B裝置檢測到A裝置低於其有效的電壓閾值,同時B裝置低於有效的電壓閾值。
2) B裝置必須檢測到D 和D-資料線至少在2ms的時間內低於有效閾值,即處於SE0狀態。

資料線脈衝調製會話請求:B裝置必須等到滿足以上兩個條件後,將資料線接入上拉電阻一定的時間,以備A裝置過濾資料線上的瞬間電壓。與此同時,B裝置上拉D 以便於在全速模式下進行初始化操作。A裝置在檢測到D 變為高電平或D-變為低電平時產生SRP指示訊號。

Vbus脈衝調製會話請求:B裝置同樣需等待滿足上述兩個初始化條件,然後B裝置通過對電容充電以提高匯流排電壓,待達到匯流排上的電壓閾值,喚醒A裝置。在充電過程中,一定要保證充電的電壓峰值在一定的範圍以避免燒壞A裝置。

USB驅動架構

USB驅動架構如下圖所示:
image

3.1 USB主機端驅動

image

USB核心(USBD)是整個USB驅動的核心部分,從上圖可知,一方面USBD對接收到USB主機控制器的資料進行處理,並傳遞給上層的裝置端驅動軟體;同時也接收來自上層的非USB格式資料流,進行相應的資料處理後傳遞給USB主機控制器驅動。

image

USB資料傳輸都以==URB(USB Request Block)請求、URB生成、URB遞交、URB釋放為主線==。從上圖可知,當載入控制器驅動之後,註冊根據集線器,hub和hcd驅動成為一個整體。接著,主機通過控制傳輸獲取裝置的控制描述符等資訊,接著詳述整個控制傳輸的流程。usb_submit_urb依據是否連線到根集線器來決定呼叫urb_enqueue或rh_urb_enqueue函式。

USB從裝置通過集線器或根集線器連線到USB主機上。比如:主機通過根集線器與外界進行資料互動,==根集線器通過探測資料線狀態的變化來通知USB主機是否有USB外圍裝置接入==。

在主機端控制器驅動載入的過程中,註冊了根集線器,然後匹配了相應的hub驅動程式,同時完成了對Hub的==輪詢函式和狀態處理函式==的設定。這樣,==一旦hub集線器的狀態發生變化,就會產生相應的中斷,主機端控制器就會執行相應的中斷處理函式==,下圖為hub驅動程式的流程圖。

image

USB Core中的usb_init()函式中完成了對hub執行緒(khubd,在usb_hub_init函式中真正地建立)的建立,然後完成相應裝置的探測。主機端控制器驅動進行探測時,將hub驅動和主機端控制器驅動結合在一起,相互之間完成呼叫。 相對於大容量儲存裝置與主機之間通過控制/批量傳輸,集線器與主機之間通過中斷/控制方式完成資料互動。

3.2 USB裝置端驅動

image

image

從上圖可知,裝置端驅動包含兩部分:
1) 底層裝置控制器驅動
2) 上層大容量儲存類驅動

3.2.1 裝置控制器驅動

USB裝置控制器驅動主要實現Gadget API定義的函式和中斷服務函式,可按功能劃分為:API函式實現模組和中斷處理模組。

API函式主要實現Gadget API定義的函式功能,如結構體usb_ep_ops和usb_gadget_ops中的函式、usb_gadget_register_driver函式。這些函式是供Gadget Driver呼叫。

中斷處理模組主要處理裝置控制器產生的各種中斷,包括端點中斷、復位、掛起等中斷。

image

上圖為裝置端控制器基本架構,主要完成了Gadget驅動和控制器驅動繫結usb_gadget_register_driver註冊。

3.3 OTG驅動

image

OS_FS: 檔案系統

USBD: USB核心

HCD: 主機控制器驅動

UDC: 裝置端控制器驅動

OTG裝置支援HNP和SRP協議。OTG裝置通過USB OTG電纜連線到一起,其中接Mini-A介面的裝置為A裝置,預設為主機端,Mini-B介面的裝置預設為B裝置。當A、B裝置完成資料互動之後,A、B裝置之間的USB OTG電纜進入掛起狀態,如下圖所示:

image

當B裝置寫入b_bus_req,向A裝置發起HNP請求。待A裝置響應之後,A裝置傳送a_set_b_hnp_en,B裝置響應之後即進入主機狀態,同時傳送請求使用A裝置set_device,這樣A、B裝置完成主從交換。

USB 傳輸流程

image

4.1 USB初始化過程

USB驅動作為一個系統,整合了眾多的驅動模組,註冊過程非常複雜。從USB系統的角度來說,USB主機驅動主要包含:
1) USB核驅動
2) 主機控制器驅動
3) 集線器驅動

驅動的載入執行流程如下圖所示:

USB初始化過程
image

4.1.1 USB Core的初始化

USB驅動從USB子系統的初始化開始,USB子系統的初始化在檔案

driver/usb/core/usb.c
subsys_initcall(usb_init);  
module_exit(usb_exit);  

subsys_initcall()是一個巨集,可以理解為module_init()。由於此部分程式碼非常重要,開發者把它看作一個子系統,而不僅僅是一個模組。USB Core這個模組代表的不是某一個裝置,而是所有USB裝置賴以生存的模組。在Linux中,像這樣一個類別的裝置驅動被歸結為一個子系統。

subsys_initcall(usb_init)告訴我們,usb_init才是真正的初始化函式,而usb_exit將是整個USB子系統結束時的清理函式。

4.1.2 主機控制器的初始化及驅動執行(以EHCI為例)
module_init(otg_init); 模組註冊
static init __init otg_init(void);
platform_driver_register(); 平臺註冊
static int __init otg_probe(struct platform_device *pdev); 探測處理函式
reg = platform_get_resource(pdev, IORESOURCE_MEM, 0); 獲取暫存器資訊
data = platform_get_resource(pdev,IORESOURCE_MEM, 1); 獲取記憶體資訊
irq = platform_get_irq(pdev,0); 獲取中斷號
usb_create_hcd(&otg_hc_driver, &pdev->dev, pdev->dev.bus_id);

分配和初始化HCD結構體。對裝置資料空間進行分配,初始化計數器、匯流排、定時器、hcd結構體各成員值。

ret = usb_add_hcd(hcd,irq,SA_INTERRUPT);

完成HCD結構體的初始化和註冊。申請buffer,註冊匯流排、分配裝置端記憶體空間,向中斷向量表中申請中斷,註冊根集線器,對根集線器狀態進行輪詢。

4.1.3 註冊集線器
register_root_hub(hcd);

在USB系統驅動載入的過程中,建立了集線器的執行緒(khubd),並且一直查詢相應的執行緒事務。HCD驅動中,將集線器作為一個裝置新增到主機控制器驅動中,然後進行集線器埠的初始化。在USB主機看來,根集線器本身也是USB主機的裝置。USB主機驅動載入完成之後,即開始註冊根集線器,並且作為一個裝置載入到主機驅動之中。

USB主機和USB裝置之間進行資料互動,USB裝置本身並沒有匯流排控制權,U盤被動地接收USB主機傳送過來的資訊並做出響應。USB主機控制器與根集線器構成了主機系統,然後外接其它的USB裝置。

為了更好地探測到根集線器的狀態變化,USB主機控制器驅動增加了狀態輪詢函式,以一定的時間間隔輪詢根集線器狀態是否發生變化。一旦根集線器狀態發生變化,主機控制器就會產生相應的響應。

USB主機和USB裝置之間的資料傳輸以URB(USB Request Block)的形式進行。

4.2 URB傳輸過程

USB初始化過程中,無論是主機控制器驅動還是根集線器驅動,都是通過URB傳輸獲取裝置資訊。

4.2.1 申請URB
struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags)為urb分配記憶體並執行初始化。
4.2.2 初始化URB
初始化具體的urb包 
static inline void usb_fill_bulk_urb(struct urb *urb,  
struct usb_device *dev,  
unsigned int pipe,  
void *transfer_buffer,  
int buffer_length,  
usb_complete_t complete_fn,  
void *context)  
static inline void usb_fill_control_urb(struct urb *urb,  
struct usb_device *dev,  
unsigned int pipe,  
unsigned char *setup_packet,  
void *transfer_buffer,  
int buffer_length,  
usb_complete_t complete_fn,  
void *context)  
static inline void usb_fill_int_urb(struct urb *urb,  
struct usb_device *dev,  
unsigned int pipe,  
void *transfer_buffer,  
int buffer_length,  
usb_complete_t complete_fn,  
void *context,  
int interval)  

不同的傳輸模式下,驅動為之申請不同的URB。其中,Linux核心只支援同步傳輸外的三種傳輸事件,ISO事務需要手工進行初始化工作。控制傳輸事務、批量傳輸事務、中斷傳輸事務API如上所示。

三種事務傳輸模式下的URB初始化函式有很多相似之處,主要引數含義如下:

• urb: 事務傳輸中的urb
• dev: 事務傳輸的目的裝置
• pipe: USB主機與USB裝置之間資料傳輸的通道
• transfer_buffer: 傳送資料所申請的記憶體緩衝區首地址
• length: 傳送資料緩衝區的長度
• context: complete函式的上下文
• complete_fn: 呼叫完成函式
• usb_fill_control_urb()的setup_packet: 即將被髮送的裝置資料包
• usb_fill_int_urb()的interval: 中斷傳輸中兩個URB排程的時間間隔
4.2.3 提交URB

URB初始化完成之後,USBD開始通過usb_start_wait_urb()提交urb請求(它呼叫usb_submit_urb來真正的傳送URB請求),新增completition函式。

接下來,從message.c傳到主機控制器(hcd.c),開始真正的usb_hcd_submit_urb()。此時,根據是否為根集線器,進入不同的工作佇列。

usb_start_wait_urb->
usb_submit_urb->
usb_hcd_submit_urb

1) root_hub傳輸

若為root hub,將呼叫rh_urb_enqueue(),共有兩種傳輸事務(控制傳輸和中斷傳輸)
static int rh_urb_enqueue (struct usb_hcd *hcd, struct urb *urb)  
{  
if (usb_endpoint_xfer_int(&urb->ep->desc)) // 中斷傳輸
return rh_queue_status (hcd, urb);  
if (usb_endpoint_xfer_control(&urb->ep->desc)) // 控制傳輸  
return rh_call_control (hcd, urb);  
return -EINVAL;  
}  

2) 非root_hub傳輸

對於非常root_hub傳輸,它呼叫:
status = hcd->driver->urb_enqueue(hcd, urb, mem_flags);

3) 批量傳輸
root_hub本身沒有批量傳輸流程,按照控制傳輸流程,控制傳輸最終要通過switch語句跳轉到Bulk-Only傳輸流程中。