統(tǒng)一可擴展固件接口UEFI(Unified Extensible Firmware Interface)是Intel推出的新一代BIOS技術，旨在定義一套操作系統(tǒng)與平臺固件之間完整的接口規(guī)范，為操作系統(tǒng)的引導提供標準環(huán)境[1]。相比于使用匯編語言編寫的傳統(tǒng)BIOS，UEFI采用模塊化的設計、C語言風格的參數(shù)堆棧傳遞方式，借由動態(tài)鏈接的形式所構建出來的系統(tǒng)，更易于實現(xiàn)[2]。同時，UEFI是以32 bit或64 bit CPU保護模式運行，突破了傳統(tǒng)16 bit實模式代碼的尋址能力，可達到CPU的最大尋址空間。得益于這些優(yōu)點，UEFI經過近10年的推廣，已經成為主流，將使用傳統(tǒng)BIOS的微型計算機系統(tǒng)逐漸淘汰出市場[3]。
    UEFI中引入了UEFI驅動程序模型的概念，采用驅動/協(xié)議的結構開發(fā)驅動程序，驅動程序和硬件完全獨立，具有很強的擴展性，從而使得UEFI平臺下添加新的特性變得簡單[4]。
1 UEFI基本結構分析
    UEFI主要由引導管理器、固件內核、協(xié)議、驅動模型等組件構成[4]。其中固件內核為UEFI的基礎，它將底層硬件功能抽象化，為上層的引導管理器提供兩種服務：引導服務和運行時服務。引導管理器是一個策略引擎，它使用固件內核提供的服務加載UEFI驅動程序和應用程序，并最終加載操作系統(tǒng)。
    圖1所示為UEFI的系統(tǒng)框架圖。固件內核運行在PEI和DXE階段，UEFI在PEI階段直接與硬件層打交道，啟動必需的硬件資源，譬如完成CPU和芯片組的初始化，進而滿足DXE的執(zhí)行啟動條件；其后，系統(tǒng)在DXE階段完成其他所有硬件的初始化，并為上層接口實現(xiàn)引導服務和運行時服務。引導管理器運行在DXE和BDS階段，它通過加載框架驅動和平臺驅動向上層提供UEFI服務和接口，通過加載應用程序擴展系統(tǒng)功能，并在BDS階段提供一個引導菜單，供用戶選擇引導設備。最終引導加載器在ROM上加載操作系統(tǒng)加載器，將控制權移交給操作系統(tǒng)，完成操作系統(tǒng)的引導。

2 CC2531 ZigBee模塊的設備驅動程序開發(fā)
    CC2531是TI公司推出的一款用于IEEE 802.15.4或ZigBee應用的片上系統(tǒng)解決方案，它能夠以非常低的成本建立網(wǎng)絡節(jié)點，支持低功耗的無線通信，主要用于遠程控制、家庭控制等領域[5]。CC2531集成了USB2.0功能模塊，可以更加方便地與主機進行通信。
    本文將CC2531 ZigBee模塊(以下簡稱CC2531模塊)通過USB接口與無線POS機的主機相連，CC2531模塊通過ZigBee無線網(wǎng)絡與POS機的外設(如打印機、客顯、鍵盤等)進行信息交互。此方案實現(xiàn)了在啟動操作系統(tǒng)之前對POS機及其外設進行相應遠程檢測和診斷的功能。圖2為無線POS機系統(tǒng)的結構框圖。
2.1 UEFI驅動程序模型分析
2.1.1 句柄和協(xié)議
    UEFI驅動程序模型使用句柄代表設備，每個設備對應有自己的句柄，句柄由一個或多個協(xié)議組成。協(xié)議是一個以128 bit的全局唯一標識符GUID(Globally Unique Identifier)命名的結構體，是一些指針和數(shù)據(jù)結構體或者規(guī)范定義的接口函數(shù)指針的集合，協(xié)議代表設備提供的一類服務，服務的具體功能在設備驅動程序（以下簡稱驅動）中實現(xiàn)。開發(fā)者首先找到指定設備句柄上掛載的指定協(xié)議，再通過協(xié)議提供的接口訪問設備驅動中實現(xiàn)服務的功能函數(shù)，對設備進行操作。圖3所示為設備句柄和協(xié)議的結構圖。

2.1.2 驅動程序模型執(zhí)行流程
    UEFI驅動程序模型是一種用于簡化設備驅動設計和執(zhí)行的機制，遵循驅動程序模型規(guī)范的UEFI驅動的可執(zhí)行鏡像大小會得到有效的減小[6]。UEFI驅動程序模型的執(zhí)行流程圖如圖4所示。

    驅動程序模型采用UEFI 驅動載入、連接的形式來進行硬件的辨識、控制及系統(tǒng)資源掌控。在DXE階段，系統(tǒng)調用引導服務的LoadImage()函數(shù)將驅動鏡像文件加載到內存中，調用StartImage()函數(shù)執(zhí)行驅動的入口函數(shù)來啟動驅動。遵循模型規(guī)范的設備驅動在入口函數(shù)的初始化中不涉及任何硬件操作，僅僅實現(xiàn)驅動綁定協(xié)議（Driver Binding Protocol），協(xié)議包含3個接口函數(shù)：Support()、Start()和Stop()。Support()函數(shù)用來驗證驅動程序與給定的設備句柄是否匹配；Start()函數(shù)負責驅動與句柄的連接，即將抽象 I/O 功能的協(xié)議安裝到設備句柄上；相對應的，Stop()函數(shù)則會強制停止驅動對一個設備句柄的管理和控制，并卸載設備句柄在Start()中安裝的所有協(xié)議。
    DXE階段執(zhí)行完成后，雖然加載和啟動了驅動，但還在等待著連接設備句柄。因此，在BDS階段引導管理器將會調用引導服務的ConnectController()函數(shù)執(zhí)行驅動的連接過程。該函數(shù)執(zhí)行所有驅動綁定協(xié)議的Support()進行設備句柄的驗證，若驗證正確，則會繼續(xù)調用Start()連接驅動和設備句柄，并在設備句柄上安裝抽象I/O功能的協(xié)議。
2.2 CC2531模塊USB驅動協(xié)議棧
    圖5所示是由一系列驅動組成的多層次的、完整的 USB 驅動協(xié)議棧。處于上層的驅動會使用下層驅動提供的服務，并為更高層的驅動提供服務。首先，PCI總線驅動枚舉設備時發(fā)現(xiàn)USB主機控制器，并在控制器句柄上安裝EFI_PCI_IO_PROTOCOL協(xié)議，USB主機控制器驅動則使用EFI_PCI_IO_PROTOCOL協(xié)議提供的接口實現(xiàn)EFI_USB_HC_PROTOCOL協(xié)議。然后，USB總線驅動使用EFI_USB_HC_PROTOCOL協(xié)議服務實現(xiàn)對USB設備的枚舉，生成CC2531設備句柄，并在設備句柄上安裝 EFI_USB_IO_PROTOCOL協(xié)議。最后，CC2531模塊設備驅動使用EFI_USB_IO_PROTOCOL協(xié)議服務，在CC2531模塊設備句柄上安裝EFI_USB_CCCONTROL_PROTOCOL協(xié)議，完成CC2531模塊驅動協(xié)議棧的加載。

2.3 CC2531模塊驅動程序設計
    CC2531模塊驅動作為設備驅動，遵循UEFI驅動程序模型規(guī)范，使用驅動綁定協(xié)議的方式實現(xiàn)設備驅動的加載和連接。同時，驅動還提供通信協(xié)議EFI_USB_CCCONTROL_PROTOCOL用于系統(tǒng)與CC2531模塊間的通信，并通過ZigBee網(wǎng)絡與無線POS機外設進行通信。
2.3.1 綁定協(xié)議接口函數(shù)的實現(xiàn)

    (1)Support()：圖6所示為Support函數(shù)實現(xiàn)流程圖，函數(shù)首先檢查給定的目標設備句柄是否安裝有 EFI_USB_IO_PROTOCOL協(xié)議，若有，則說明USB總線驅動已經辨認出該USB設備。其次，使用EFI_USB_IO_PROTOCOL協(xié)議提供的功能接口函數(shù)獲取目標USB設備的設備描述符，描述符中的接口號、接口類型、子類型和協(xié)議等字段指定了的USB設備的類型，檢查這些字段就可得知驅動是否為CC2531模塊設備驅動，如果匹配則說明加載的驅動正確，就會執(zhí)行Start()函數(shù)。以下是部分實現(xiàn)代碼：

    EFI_STATUS USBCC2531DriverBindingSupported(…)
    {…
    //檢查目標設備句柄是否安裝有USB_IO協(xié)議
        Status = gBS->OpenProtocol (Controller，
&gEfiUsbIoProtocolGuid,
    (VOID **) &UsbIo, This->DriverBindingHandle,
    Controller, EFI_OPEN_PROTOCOL_BY_DRIVER );
    …
    //讀出目標USB設備的設備描述符
    Status = UsbIo->UsbGetInterfaceDescriptor (
            UsbIo, &InterfaceDescriptor);
    //檢查是否為USB-CC2531的驅動
    if(InterfaceDescriptor.InterfaceNumber==1
    &&InterfaceDescriptor.InterfaceClass ==0x0a
    && InterfaceDescriptor.InterfaceSubClass==0
    && InterfaceDescriptor.InterfaceProtocol == 0 ) { … }
    //關閉USB_IO協(xié)議
        gBS->CloseProtocol (…);
        return Status;
    }
    (2)Start()：Start()函數(shù)的目標是使用USB總線驅動提供的協(xié)議服務在CC2531模塊設備驅動中安裝通信協(xié)議EFI_USB_CCCONTROL_PROTOCOL。函數(shù)首先打開設備句柄上掛載的EFI_USB_IO_PROTOCOL協(xié)議，使用該協(xié)議提供的接口函數(shù)UsbGetInterfaceDescriptor()和UsbGetEndpointDescriptor()得到USB設備的接口描述符和端點描述符，分析設備描述符中的字段以確定USB設備信息和接口類型等參數(shù)。其次，為驅動私有數(shù)據(jù)結構體分配內存，并使用設備描述符中的字段信息進行初始化。最后，安裝EFI_USB_CCCONTROL_PROTOCOL協(xié)議，完成驅動與設備的連接。圖7所示為Start()函數(shù)實現(xiàn)流程圖。
    (3)Stop()：Stop()是Start執(zhí)行流程的逆過程，該函數(shù)用于卸載EFI_USB_CCCONTROL_PROTOCOL協(xié)議，釋放驅動私有數(shù)據(jù)結構體占用的內存資源，關閉EFI_USB_IO_PROTOCOL協(xié)議，斷開CC2531模塊驅動與設備句柄的連接。

2.3.2 設備通信協(xié)議結構體
    為了實現(xiàn)UEFI系統(tǒng)與CC2531模塊之間的數(shù)據(jù)通信，本文設計了EFI_USB_CCCONTROL_PROTOCOL作為驅動的通信協(xié)議。該協(xié)議中包括了UEFI系統(tǒng)與CC2531模塊間數(shù)據(jù)發(fā)送和接收的接口函數(shù)，還有部分與POS機系統(tǒng)外設交互的命令函數(shù)，如系統(tǒng)外設啟動和復位命令的接口函數(shù)。協(xié)議的部分成員函數(shù)定義如下：
struct _EFI_USB_CCCONTROL_PROTOCOL {…
    EFI_USB_CONTROLL_RESET Reset;//復位設備
    EFI_USB_TEXTOUTPUT_STRING OutputString;
//數(shù)據(jù)發(fā)送
    EFI_USBINPUT_STRING    ReadInput;  //數(shù)據(jù)讀取
    EFI_USB_DETECTDEVICE    DetectDevice;
//設備啟動命令
    EFI_EVENT WaitForInputString;//等待讀入事件
    };
2.3.3 設備通信協(xié)議接口函數(shù)的實現(xiàn)
    CC2531 模塊的USB接口固件代碼是基于USB通信設備類CDC(Communication Device Class)協(xié)議實現(xiàn)的。CDC由通信接口類和數(shù)據(jù)接口類組成，通信接口類主要負責設備的管理和控制，數(shù)據(jù)接口類則負責數(shù)據(jù)的傳輸。CC2531模塊的USB接口采用端點0作為通信接口類中的控制端點來管理設備的枚舉和命令控制，數(shù)據(jù)接口類使用塊傳輸輸入（IN）端點和塊傳輸輸出（OUT）端點實現(xiàn)數(shù)據(jù)的雙向傳輸。因此，UEFI系統(tǒng)對CC2531模塊的枚舉和識別采用控制傳輸方式，數(shù)據(jù)通信則采用批量傳輸方式。
    協(xié)議的發(fā)送接口函數(shù)為UsbCCDataTransmit()，該函數(shù)調用EFI_USB_IO_PROTOCOL協(xié)議提供的服務函數(shù)UsbBulkTransfer()，通過將數(shù)據(jù)寫入輸出端口完成數(shù)據(jù)從主機到CC2531模塊的批量傳輸。設備驅動發(fā)送數(shù)據(jù)接口函數(shù)的部分代碼實現(xiàn)如下所示：
    EFI_STATUS UsbCCDataTransmit (…)
    { …
    //選擇發(fā)送數(shù)據(jù)的輸出端口
    Endpoint=UsbCC2531Device->BulkOutEndpointDescriptor;
    //等待發(fā)送或接收的超時時間
    Timeout = Timeout / USB_MASS_1_MILLISECOND;
        //發(fā)送數(shù)據(jù)
        Status=UsbCC2531Device->UsbIo->UsbBulkTransfer (
        UsbCC2531Device->UsbIo, Endpoint.EndpointAddress,
Data, TransLen, Timeout, &Result);
        if (EFI_ERROR (Status)) { …}
        return Status;
    }
    CC2531模塊設備驅動的數(shù)據(jù)接收操作亦通過調用函數(shù)UsbBulkTransfer()檢測輸入端口的緩沖隊列完成。由于數(shù)據(jù)接收操作的被動性，驅動需要建立一套讀操作的響應觸發(fā)機制。本方案使用UEFI的事件(EVENT)機制實現(xiàn)對數(shù)據(jù)接收操作的響應：首先在驅動的Start()創(chuàng)建一個定時器事件，并在定時器的響應函數(shù)USBCC2531Timer-
Handler()中周期性調用UsbCCDataRecevice()執(zhí)行對輸入端口緩沖隊列的讀操作，如果成功讀到數(shù)據(jù)，則將讀回的數(shù)據(jù)存入私有數(shù)據(jù)結構體的循環(huán)隊列UsbDataQueue中。其次，創(chuàng)建一個等待事件WaitForInputString，并在等待事件的觸發(fā)函數(shù)中檢查循環(huán)隊列，如有數(shù)據(jù)則讀取，否則循環(huán)等待。部分數(shù)據(jù)讀取操作的代碼如下：
    EFI_STATUS UsbCCDataRecevice ( …)
    { …
        Status=UsbCC2531Device->UsbIo->UsbBulkTransfer (…);
        if (EFI_ERROR (Status)) {  …  }
        else {
            //將讀取的數(shù)據(jù)存入鏈表
            Enqueue (UsbCC2531Device->UsbDataQueue,
Data,MaxItemSize);
                }
        return Status;
    }
    UEFI采用的模塊化設計和驅動程序模型都為整體系統(tǒng)提供了良好的兼容性和擴展性，簡化了UEFI驅動和應用程序的開發(fā)難度，提高了可維護性，有助于計算機固件的進一步發(fā)展。相對于傳統(tǒng)BIOS，UEFI具有明顯的優(yōu)越性，越來越得到業(yè)界和市場的認可。本文從UEFI功能擴展的角度考慮，分析了UEFI的架構和驅動程序模型，設計并實現(xiàn)了CC2531模塊的設備驅動程序，最終實現(xiàn)了在啟動操作系統(tǒng)之前通過CC2531模塊與無線POS機外設進行通信的目標。本方案的下一目標是擴展UEFI下的網(wǎng)絡應用，實現(xiàn)對POS機系統(tǒng)的遠程管理和診斷。
參考文獻
[1] Unified EFI，Inc.Unified extensible firmware interface specification[S].Version2.3.1 Errata C.2012：1-22.
[2] 朱賀新.基于UEFI的可信BIOS平臺研究與應用[D].西安：西安科技大學，2008：11-15.
[3] 萬象.基于UEFI系統(tǒng)的LINUX通用應用平臺的設計與實現(xiàn)[D].上海：上海交通大學，2012.
[4] 潘登，劉光明.EFI結構分析及Driver開發(fā)[J].計算機工程與科學，2006，28(2)：115-117.
[5] Texas Instruments.CC2531 SOC solution for IEEE 802.15.4 and ZigBee applications(Rev.A)[Z].2011.
[6] ZIMMER V，ROTHMAN M，MARISETTY S.Beyond BIOS：developing with the unified extensible firmware interface(2  Edition)[M].Intel Press，2010.