Linux2.6環(huán)境下USB設(shè)備的驅(qū)動實(shí)現(xiàn)

Linux2.6環(huán)境下USB設(shè)備的驅(qū)動實(shí)現(xiàn)

0? 概述

嵌入式linux系統(tǒng)環(huán)境以其易于移植裁減、內(nèi)核小、效率高、完整、原代碼開放及性能優(yōu)異等特點(diǎn)，在嵌入式領(lǐng)域得到了非常廣泛的應(yīng)用。Linux的USB設(shè)備端的源代碼中主要有USB device的海量存儲設(shè)備、串口設(shè)備、網(wǎng)絡(luò)設(shè)備等設(shè)備驅(qū)動程序及各種USB device控制器芯片的驅(qū)動程序。市場上USB設(shè)備控制器芯片種類繁多，大多數(shù)用戶需要針對特定應(yīng)用來開發(fā)相關(guān)的USB設(shè)備控制器驅(qū)動程序，才能使設(shè)備正常工作在linux操作系統(tǒng)下。

1 USB設(shè)備端驅(qū)動系統(tǒng)

Linux Gadget子系統(tǒng)主要分為三層：第一層為芯片驅(qū)動層，負(fù)責(zé)將各種USB device控制器抽象為統(tǒng)一的函數(shù)接口，以供上層驅(qū)動程序調(diào)用；第二層主要是對操作函數(shù)的簡單封裝；第三層為設(shè)備驅(qū)動層，可根據(jù)系統(tǒng)的需求實(shí)現(xiàn)所對應(yīng)的功能。圖1所示是Linux Gadget子系統(tǒng)的驅(qū)動層次。Linux Gadget子系統(tǒng)的設(shè)備驅(qū)動層主要根據(jù)各個(gè)類別的規(guī)范及協(xié)議實(shí)現(xiàn)各種設(shè)備的驅(qū)動，本設(shè)計(jì)需要使一個(gè)嵌入式設(shè)備擁有移動硬盤的功能，所以，可以根據(jù)海量存儲類的規(guī)范及協(xié)議來實(shí)現(xiàn)該功能。



1.1 UDC驅(qū)動的基本構(gòu)架

圖2所示是UDC驅(qū)動的基本構(gòu)架圖。在控制器驅(qū)動程序中，首先應(yīng)注冊platform驅(qū)動，調(diào)用其probe函數(shù)搜索設(shè)備，并在probe函數(shù)內(nèi)初始化usb_ep和usb_gadget等結(jié)構(gòu)，然后注冊設(shè)備，并申請中斷，接著等待中斷進(jìn)入中斷服務(wù)子程序，最后聲明和實(shí)現(xiàn)usb_gadget_register_driver注冊函數(shù)并輸出給上層驅(qū)動。在該過程中，聯(lián)系它們的紐帶是一些全局結(jié)構(gòu)體變量。

1.2 Gadget API

Gadget API為Gadget系統(tǒng)定義了統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)和接口函數(shù)，它和主機(jī)端的USB Core地位類似，但功能僅限于提供編程接口，如用結(jié)構(gòu)體usb_gadget_ops和usb_ep_ops對設(shè)備控制器驅(qū)動操作函數(shù)和端點(diǎn)操作函數(shù)進(jìn)行重新封裝。比較特殊的是Gadget驅(qū)動程序注冊函數(shù)usb_gadget_register_driver，它們是由設(shè)備控制器(UDC)驅(qū)動直接提供的，用于將UDC綁定到gadget driver。這增加了Gadget Driver和UDC之間的依賴性。

在設(shè)備端，Gadget系統(tǒng)雖然類似主機(jī)驅(qū)動系統(tǒng)分了三層結(jié)構(gòu)，但Gadget API只定義了一些數(shù)據(jù)結(jié)構(gòu)、宏和功能函數(shù)，并對UDC驅(qū)動程序進(jìn)行了簡單包裝，而沒有驅(qū)動管理等功能。

1.3設(shè)備應(yīng)用驅(qū)動程序

設(shè)備端應(yīng)用程序(Gadget Driver)用于控制USB設(shè)備功能的實(shí)現(xiàn)，使設(shè)備表現(xiàn)出“網(wǎng)絡(luò)連接”、“打印機(jī)”或“大容量存儲設(shè)備”等特性。本文以大容量移動存儲設(shè)備為例來實(shí)現(xiàn)移動硬盤的功能。

BULK ONLY傳輸指的是主機(jī)和大容量存儲設(shè)備之間的一種數(shù)據(jù)傳輸方式。

2設(shè)備端驅(qū)動調(diào)度

在嵌入式Linux操作系統(tǒng)中，Gadget driver和Gadget API可完成部分USB協(xié)議處理、BULK ONLY等傳輸協(xié)議以及指令的解析處理，用戶只需要在設(shè)備控制器驅(qū)動程序中完成部分USB協(xié)議處理和Gadget API的銜接工作。

圖3所示的流程圖給出了USB設(shè)備端驅(qū)動程序的基本調(diào)度思想。該方案的主要思路是被動的接受主機(jī)端的傳輸命令(任何類型的通信都由USB主機(jī)發(fā)起，USB設(shè)備間不能直接通信)，然后通過中斷觸發(fā)的方式完成主機(jī)端的數(shù)據(jù)傳輸。當(dāng)產(chǎn)生設(shè)備端中斷時(shí)，設(shè)備控制器驅(qū)動程序首先判斷中斷類型。當(dāng)其為批量傳輸端點(diǎn)IN中斷時(shí)，驅(qū)動程序會將該EP下鏈接的REQ中的數(shù)據(jù)依次寫入U(xiǎn)SB2.0 OTG IP的設(shè)備控制器的內(nèi)存區(qū)；當(dāng)其為批量傳輸OUT中斷時(shí)，驅(qū)動程序會將設(shè)備控制器內(nèi)存區(qū)的數(shù)據(jù)讀入REQ中的buffer中；當(dāng)其為端點(diǎn)0的控制傳輸中斷時(shí)，驅(qū)動程序?qū)⒆x取端點(diǎn)緩沖區(qū)的數(shù)據(jù)，并解析當(dāng)前的設(shè)備請求。如果主機(jī)傳輸給設(shè)備的設(shè)備請求為USB REO SEDRESS(設(shè)置設(shè)備地址)、USB_REQ_GET_STATUS(獲取設(shè)備狀態(tài))、USB_REQ_SET_FEATURE(設(shè)置設(shè)備特性)，設(shè)備控制器驅(qū)動程序會自行響應(yīng)請求。但是，如果是其它設(shè)備請求，如GET_DESCRIPTOR(獲取設(shè)備描述符)時(shí)，設(shè)備控制器驅(qū)動便會將該請求提交給Gadget Driver，然后由Gadget Driver排隊(duì)將該設(shè)備請求提交給端點(diǎn)，以等待下次控制端點(diǎn)中斷。


控制傳輸比較復(fù)雜，它需要完成建立階段、數(shù)據(jù)傳輸階段和狀態(tài)階段。整個(gè)控制端點(diǎn)中斷的處理可通過四個(gè)狀態(tài)實(shí)現(xiàn)，分別是：端點(diǎn)0空閑(EP0_IDLE)、 數(shù)據(jù)IN傳輸(EP0 IN DATA_PHASE)、數(shù)據(jù)OUT傳輸(EP0 OUT DATA_PHASE)和狀態(tài)階段(EPO_STATUS)。

EP0_IDLE狀態(tài)主要處理建立階段的setup令牌，并根據(jù)獲得的設(shè)備請求處理能夠處理的設(shè)備請求，同時(shí)把不能處理的設(shè)備請求(如獲取設(shè)備描述符，配置描述符等)提交給上層Gadget Driver；EP0_OUT_DATA_PHASE狀態(tài)主要處理數(shù)據(jù)階段的OUT傳輸；EP0_OUT_DATA_PHASE狀態(tài)主要處理數(shù)據(jù)階段的IN傳輸；EP0_STATUS狀態(tài)則主要完成控制傳輸過程中的狀態(tài)階段。

在圖3所示的流程圖中，EP0為控制傳輸端點(diǎn)，EP1、EP2、EP3為批量傳輸端點(diǎn)，它們主要包括端點(diǎn)傳輸類型、端點(diǎn)緩沖區(qū)大小等信息。REQ為Gadget Driver提交的端點(diǎn)請求，主要包含傳輸?shù)臄?shù)據(jù)長度和地址。

3 UDC的設(shè)計(jì)與實(shí)現(xiàn)

設(shè)備控制器驅(qū)動主要分為Gadget Driver接口模塊、Gadget API函數(shù)模塊、中斷處理模塊、數(shù)據(jù)結(jié)構(gòu)定義、初始化模塊、硬件讀寫模塊等，各模塊可以單獨(dú)進(jìn)行設(shè)計(jì)。

3.1? 數(shù)據(jù)結(jié)構(gòu)定義

根據(jù)Gadget API提供的數(shù)據(jù)結(jié)構(gòu)，可以定義自己的數(shù)據(jù)結(jié)構(gòu)(如設(shè)備數(shù)據(jù)結(jié)構(gòu)otg_udc，端點(diǎn)數(shù)據(jù)結(jié)構(gòu)otg_udc_ep等)來描述該USB設(shè)備控制器。

定義完特定的設(shè)備控制器驅(qū)動的數(shù)據(jù)結(jié)構(gòu)后，再進(jìn)行相應(yīng)的映射(static struct otg_ip_udcmemory)，以便將具體的設(shè)備控制器、設(shè)備端點(diǎn)和Gadget的抽象數(shù)據(jù)結(jié)構(gòu)聯(lián)系起來。

3.2 Gadget Driver接口模塊

UDC驅(qū)動提供有usb_gadget_driver_register模塊，該模塊可實(shí)usb_gadget_register_driver等綁定函數(shù)的功能，以綁定UDC和Gadget Driver。

3.3 Gadget API函數(shù)模塊

Linux USB gadget driver API定義了一個(gè)通用的gadget driver的接口，利用gadget driver可通過API與底層USB controller driver進(jìn)行通信。該API屏蔽了底層硬件的不同，故可使gadget driver只注重功能的實(shí)現(xiàn)，而盡量與硬件無關(guān)。其代碼如下：



該模塊主要實(shí)現(xiàn)Gadget API定義的函數(shù)功能，如結(jié)構(gòu)體usb_ep_ops和usb_gadget_ops中的函數(shù)，以及usb_gadget_register_driver注冊函數(shù)等。這些函數(shù)可供Gadget Driver調(diào)用。

3.4? 中斷處理模塊

由于設(shè)備是被動的接受主機(jī)的控制，設(shè)備的所有行為都是基于設(shè)備中斷的觸發(fā)，因此，函數(shù)主要處理Reset中斷、Resume中斷、Suspend中斷、EP0中斷以及其他端口中斷。

3.5? 初始化模塊

初始化主要是打開中斷、打開并設(shè)置端點(diǎn)、設(shè)置最大總線轉(zhuǎn)向時(shí)間(此時(shí)問即包間最大等待時(shí)間)，還要設(shè)置最大緩沖區(qū)長度等。

3.6? 硬件讀寫模塊

和主機(jī)控制器驅(qū)動程序類似，設(shè)備控制器的讀寫方式分為PIO讀寫和DMA讀寫兩種模式，讀寫內(nèi)容也分為寄存器讀寫和端點(diǎn)緩沖區(qū)讀寫。在讀寫過程中，所有讀寫地址都必須是雙字節(jié)對齊模式。

4? 驅(qū)動測試結(jié)果

本文研究的HCD已經(jīng)應(yīng)用于實(shí)際的工程中，驅(qū)動測試的硬件環(huán)境如圖4所示。



本系統(tǒng)的硬件平臺是Realview EB，這是一個(gè)高度集成的開發(fā)板，其母板上的硬件資源包括：一個(gè)FPGA (Xilinx Virtex-II XC2V6000)、靜態(tài)和動態(tài)內(nèi)存、集成外圍設(shè)備和兩個(gè)用于Core Tiles連接的tile連接器。設(shè)計(jì)時(shí)可通過增加一個(gè)額外的Core Tile(ARM926EJS CORE)來創(chuàng)建一個(gè)微處理系統(tǒng)。Logic Tile(Xilinx XC2V6000)中包含有一塊具有主機(jī)控制器功能的芯片otg_ip，otg_ip可通過片內(nèi)總線AHB掛載在母板EB上。在該開發(fā)板上運(yùn)行Linux系統(tǒng)時(shí)，可通過交叉編譯調(diào)試環(huán)境將開發(fā)報(bào)與一臺PC機(jī)相連，這樣，調(diào)試信息就可以通過串口打印在該主機(jī)的終端上。otg_ip可通過ULPI接口連接PHY芯片，并與USB設(shè)備相連。

設(shè)備控制器驅(qū)動模塊otg_ip_udc.ko和g_filestorage.ko成功加載后，再將其作為移動優(yōu)盤插入電腦主機(jī)的USB接口，驅(qū)動即可成功識別。圖5所示是內(nèi)核打印的信息結(jié)果。



5? 結(jié)束語

USB通用串行總線具有傳輸速率高、功耗低、可熱插拔和發(fā)展快速等優(yōu)點(diǎn)，而Linus操作系統(tǒng)則具有易于移植和裁減、內(nèi)核小、效率高、原代碼開放等特點(diǎn)，本文通過將其結(jié)合而給出的Linux環(huán)境下的USB設(shè)備驅(qū)動方法，可以快速地實(shí)現(xiàn)大容量的存儲功能，實(shí)驗(yàn)表明：該系統(tǒng)的數(shù)據(jù)讀寫速度可以達(dá)到681 kB／s，而且效果良好。