《電子技術應用》
您所在的位置:首頁 > 嵌入式技術 > 設計應用 > 基于OMAP3530的Windows Embedded Compact 7 BSP的開發(fā)與移植
基于OMAP3530的Windows Embedded Compact 7 BSP的開發(fā)與移植
來源:電子技術應用2012年第2期
韓德強,劉立哲,劉 濤,聶 帥
北京工業(yè)大學 計算機學院,北京100124
摘要: 介紹了TI公司的OMAP3530雙核處理器和基于該處理器設計的開發(fā)板,描述了BSP的一般概念及開發(fā)方法。通過實例說明了在嵌入式系統(tǒng)開發(fā)中如何實現Windows Embedded Compact 7 BSP的開發(fā)和移植。
中圖分類號: TP316.7
文獻標識碼: A
文章編號: 0258-7998(2012)02-0014-04
The development of BSP under Windows Embedded Compact 7 based on OMAP3530
Han Deqiang,Liu Lizhe,Liu Tao,Nie Shuai
College of Computer, Beijing University of Technology, Beijing 100124,China
Abstract: This paper produces the architecture of OMAP3530 microprocessor of TI Corporation and demo board based on this processor. It discusses the general concept of BSP and solutions in board development. It illustrates the method and steps to develop Windows Embedded Compact 7 BSP.
Key words : BSP replant;OMAP3530;Windows Embedded Compact 7

    Windows Embedded Compact 7(以下簡稱Compact 7)操作系統(tǒng)在訪問底層硬件時,不直接訪問硬件,而是通過抽象出來的函數訪問。抽象出來的函數層,就是通常所說的板支持包BSP(Board Support Package)[1]。BSP介于底層硬件和操作系統(tǒng)之間,完成硬件初始化并將控制權切換給操作系統(tǒng)。由于嵌入式系統(tǒng)的底層硬件具有無標準、非規(guī)范等特性,操作系統(tǒng)都存在著BSP移植的問題,這就要求BSP開發(fā)人員在BSP開發(fā)過程中熟練掌握具體的硬件原理和軟件實現方法。

    Compact 7與之前的Windows CE版本一樣,提供了一整套平臺開發(fā)工具Platform Builder,使開發(fā)人員能夠快速靈活地創(chuàng)建解決方案[2]。而且Platform Builder本身也提供了多種目標板的BSP樣例,可以在開發(fā)移植BSP時作參考。
1 OMAP3530處理器
    TI公司推出的OMAP3530是一款技術先進的高性能嵌入式異構雙核處理器,主要由一個600 MHz的CortexTM-A8 ARM核和一個430 MHz的DSP 核組成。嵌入式操作系統(tǒng)在ARM核上運行,與數字信號處理相關的任務則由DSP核負責。盡管OMAP3530是一個異構多核架構的微處理器,但DSP核對于基于ARM核開發(fā)的工程師而言是透明的。在軟件工具鏈中,TI引入了DSP橋的概念。DSP橋是針對ARM應用程序開發(fā)提供的一組面向DSP算法的應用程序接口(API),以便應用程序獲取DSP核的計算資源和數據資源。
2 Compact 7操作系統(tǒng)
    Windows Embedded Compact 7是Windows CE 6.0的后續(xù)產品,它不僅是一個功能強大的實時操作系統(tǒng),而且還為開發(fā)者提供了全套開發(fā)工具。作為Windows CE家族的換代產品,Compact 7繼承了之前Windows CE系統(tǒng)的優(yōu)良傳統(tǒng),又在其上增加了對ARMv7構架的支持;對Windows CE先前版本的強大功能進行了進一步的擴充和豐富,如支持多點觸控、優(yōu)化電源管理等。
    與Windows CE 6.0不同,Compact 7的平臺開發(fā)工具Platform Builder依托于Visual Studio 2008,內嵌的Silverlight for Windows Embedded有利于減輕開發(fā)者開發(fā)界面的負擔。在軟件開發(fā)上,Compact 7徹底摒棄傳統(tǒng)的MFC程序框架,轉而全面支持.Net framework。高效的開發(fā)框架,將最大限度地提高開發(fā)者的工作效率,有助于提高產品的市場競爭力。
3 OMAP3530開發(fā)板硬件構成
    開發(fā)板硬件平臺主要以TI公司的OMAP3530雙核處理器為核心,配有256 MB SDRAM和512 MB Nand Flash用以啟動系統(tǒng)和存儲運行程序。同時,還配有電源管理、USB、UART、以太網控制器、液晶屏等外圍電路?;贠MAP3530處理器開發(fā)板的硬件結構框圖如圖1所示。

4 Compact 7操作系統(tǒng)下BSP開發(fā)與移植
    Compact 7中BSP是由Boot Loader、OEM適配層、設備驅動程序、內核獨立傳輸層(KITL)以及鏡像配置文件五部分組成[3]。關于各部分之間的相互聯(lián)系以及與硬件平臺之間的關系如圖2所示。

4.1 Clone BSP
    Compact 7提供了兩種方法開發(fā)BSP,一種是從零開始進行BSP開發(fā)的方法,另一種是克隆已有的BSP再進行移植的方法。Clone BSP實質就是對現有的BSP進行復制并按照開發(fā)者要求改變BSP的名稱等信息。Clone BSP保留了原有BSP的程序架構和全部代碼,開發(fā)者只需對BSP中部分代碼進行修改添加即可實現新開發(fā)板的功能,簡化了開發(fā)流程,提高了開發(fā)效率??紤]到從零開始開發(fā)BSP相當困難,OMAP3530開發(fā)板的BSP開發(fā)就采用Clone相似平臺的BSP的方法進行移植。這樣的實現方法可以大幅度降低開發(fā)BSP的難度并縮短開發(fā)周期。
    具體方法是,在Platform Builder中使用其自帶的Clone BSP工具,克隆TI公司提供的OMAP3530樣例BSP,并自行定義名稱(如MyBSP),然后設置相關描述(如平臺目錄名稱、供應商名稱以及版本號等信息)。如果設置信息合法,單擊Clone按鈕后會提示成功克隆BSP??寺〕龅腂SP位于%_WINCEROOT%\PLATFORM目錄下。
4.2 移植Boot Loader
    BSP移植首先要實現Boot Loader的功能。Boot Loader是一段啟動引導程序,主要在Compact 7系統(tǒng)加載前初始化相關硬件,并把系統(tǒng)鏡像加載到內存中運行。根據鏡像boot的方式,Boot Loader分為nboot、eboot和uboot等。
    OMAP3530處理器內嵌的RAM只有64 KB,對Boot Loader生成的可執(zhí)行文件而言過于小,無法將其加載到內部RAM中,所以只能使用外部RAM進行加載。但OMAP3530上電時不能自動初始化memory controller,無法讀寫外部RAM。因此,需要一個程序負責初始化外部的RAM控制器,把可執(zhí)行文件從 Nand Flash或者SD卡中讀取到外部RAM中,然后跳轉到入口處執(zhí)行。實現這一功能的程序稱為x-Loader,x-Loader是Compact 7啟動之后運行的第一段程序,實質上是一個精簡版的Boot Loader。x-Loader運行的第一個函數是startup()函數,startup()采用匯編語言編寫,首要功能是對目標系統(tǒng)的CPU進行最基本的初始化。例如,清空TLB和cache、關閉中斷、配置PLL、設置內存控制器、設置跳轉到main的函數地址等。OMAP3530開發(fā)板上電后,CPU會自動從Nand Flash或者SD卡中加載x-Loader到內部RAM,然后執(zhí)行初始化任務,最后將控制權交給Boot Loader。Startup()函數實現main函數跳轉地址代碼如下:
    ldr sp, =( XLDR_STACK_PA+XLDR_STACK_SIZE)
    b        XLDRMain
    其中,XLDR_STACK_PA和XLDR_STACK_ SIZE是任務堆棧起始地址和大小,系統(tǒng)通過使sp指針指向x-Loader中的任務堆棧起始地址的方法實現程序的跳轉。
    x-Loader位于BSP目錄下的boot文件夾中,需要修改其中的platform.c和main.c兩個文件。platform.c的作用是對OMAP3530功能進行設置,文件中包括PinMuxSetup()、GpioSetup()、ClockSetup()、MemorySetup()等幾個重要的函數。
    PinMuxSetup()函數專門用于設置引腳功能,這樣做的好處是可以有統(tǒng)一的啟動代碼并且不必擔心在啟動過程中對復用引腳功能的再度修改。其實現樣例代碼如下:
    OUTREG16(&pConfig->CONTROL_PADCONF_SDRC_D0,
    (INPUT_ENABLE | PULL_INACTIVE | MUX_MODE_0));
    OUTREG16函數用于設置OMAP3530 中的16 bit寄存器,該函數通過CONTROL_PADCONF_SDRC_D0獲得處理器相應管腳的寄存器地址;通過設置INPUT_ENABLE、PULL_INACTIVE等參數來實現對管腳屬性的定義;通過設置MUX_MODE_X的方法實現管腳功能的定義。具體MUX_MODE_X代表的功能定義,可參閱OMAP3530技術手冊。
    MemorySetup()函數用于初始化通用存儲控制器(GPMC)和外部RAM(SDRC)。由于GPMC信號在Flash和以太網控制器上都用到。因此,在MemorySetup()函數中需要對GPMC片選信號進行設置。實現樣例代碼如下:
    OUTREG32(&pGpmc->GPMC_CONFIG1_3,
    BSP_GPMC_LAN_CONFIG1);
    OUTREG32函數用于設置OMAP3530 中的32 bit寄存器,通過GPMC_CONFIG獲得設置寄存器的地址;通過宏定義BSP_GPMC_LAN+CONFIG1設置具體數值。
    main.c文件是x-Loader的主程序,在RELEASE模式下能夠生成MLO執(zhí)行文件,在DEBUG模式下編譯配置文件 sources 跳過了對其的編譯。因為x-Loader對大小有要求, 若DEBUG 編譯文件過大,即使生成可執(zhí)行文件也無法加載到OMAP3530內部RAM中。
    x-Loader移植完成后,需要進行Boot Loader的移植。為了與x-Loader一致,Boot Loader下執(zhí)行的第一個函數也是Startup()函數。Boot Loader下的Startup()函數同樣是采用匯編語言編寫的,主要完成靜態(tài)邏輯地址到物理地址的映射以及跳轉到BootloaderMain函數執(zhí)行的功能。
    Boot Loader開發(fā)重點是實現OEMPlatformInit()函數用以硬件初始化,這個函數與硬件具有高度的相關性[4]??偟膩碚f,OEMPlatforminit()函數需要完成五項初始化任務:首先是通過OEMEthGetSecs()函數初始化定時器,其次初始化Nand Flash存儲器,再次是復位外圍設備,然后初始化用于下載鏡像的以太網控制器,最后初始化操作系統(tǒng)的內存空間。
    為了使Boot Loader支持以太網下載方式,需要實現與以太網控制器相關的函數。開發(fā)板以太網控制器選用SMSC公司的Lan9220芯片。其具體的實現過程如下:
    (1)在%_WINCEROOT\PLATFORM\MyBSP\SRC\BOOT\
EBOOT下添加Lan9220dbg.c。
    (2)在Lan9220dbg.c文件中實現LAN9220_Init、LAN-
9220_SendFrame和LAN9220_GetFrame 3個函數。
    (3)在%_WINCEROOT\PLATFORM\MyBSP\SRC\INC下的kitl_cfg.h文件中聲明上述3個函數,并定義BSP_ETHDRV_LAN9220結構體。結構體定義如下:
    #define BSP_ETHDRV_LAN9220 {
    (OAL_KITLETH_INIT) LAN9220_Init, NULL, NULL,
    (OAL_KITLETH_SEND_FRAME) LAN9220_SendFrame,
    (OAL_KITLETH_GET_FRAME) LAN9220_GetFrame,
    NULL, NULL, NULL, NULL,  NULL, NULL }
    (4)在%_WINCEROOT\PLATFORM\MyBSP\SRC\BOOT\
EBOOT下的boot_cfg.h文件中添加BSP_ETHDRV_LAN-
9220到g_bootDevices內容中即可。
    初始化傳輸端口通過修改OEMPreDownload()函數實現,在OEMPreDownload函數中首先需要為硬件平臺指點一個靜態(tài)IP地址,其次通過設置g_bootCfg.kitlFlags變量來設置IP協(xié)議,然后將boot方式設置成以太網下載模式,最后調用OEMLaunch函數來下載鏡像。OEMLaunch函數的功能是下載鏡像,并將程序計數器的指針直接設置到操作系統(tǒng)鏡像的開始地址。它是啟動操作系統(tǒng)前Boot Loader的最后一個函數,沒有返回值??梢詤⒖嘉④浱峁┑臉藴蔅SP中的代碼實現該函數。實現此函數后,Boot Loader的功能基本完成。
4.3 移植OEM適配層
    OEM適配層OAL(OEM Adaptation Layer)邏輯上位于Compact 7內核和硬件平臺之間。物理上可以生成可執(zhí)行文件(NK.EXE)。OAL的出現大大方便了操作系統(tǒng)和硬件平臺之間的通信。OAL還用來處理中斷、控制時鐘、管理電源、控制I/O接口等。
    通常情況下,OAL創(chuàng)建的方法就是復制與自己開發(fā)平臺相近且已經成功應用的OAL文件,然后進行適當的修改,OAL文件位于%_WINCEROOT\PLATFORM\MyBSP\SRC\OAL目錄下。移植過程中需要修改OEMInit函數,該函數是在OEM適配層中初始化中斷、時鐘、KITL、計數器以及看門狗功能的。需要注意的是,如果要打開串口的debug功能,也要在OEMInit函數中進行設置,將OEMDeinitDebugSerial()函數注釋掉。
4.4 開發(fā)設備驅動程序
    BSP驅動程序屬于內置驅動,與流驅動不一樣的是,它不用設備管理器來管理,也不用導出與流驅動程序類似的API接口。此類驅動通常放在硬件平臺的目錄之下,如LCD顯示、USB接口驅動就放在SRC\DRIVERS目錄下。
    以Touch的開發(fā)為例,簡要介紹Compact 7下內置驅動的開發(fā)過程。Compact 7中Touch驅動采用分層方式實現,分為MDD(Model Device Driver)層和PDD(Platform Dependent Driver)層,分層結構方便了驅動程序的維護和移植。Touch驅動分層示意圖如圖3所示。

 

 

    Touch驅動程序接收用戶的觸摸信息,并將其轉換為觸摸屏上的位置坐標信息,再傳給圖形、窗口和事件的子系統(tǒng)GWES(Graphics,Windowing, and Events Subsystem)模塊。主要的工作是處理用戶交互和圖形輸出等任務。觸摸屏驅動就是被它加載的,同時被GWES加載的還有鼠標驅動、鍵盤驅動以及顯示設備驅動。
    對于初學者只需實現PDD層函數以及與MDD層通信的DDSI函數即可。MDD層與GWES模塊通信的DDI函數已由微軟實現。這樣驅動開發(fā)的工作量會少很多,而代碼的可靠性則有了更好的保證。
    Compact 7觸摸屏驅動程序采用中斷方式對按下狀態(tài)進行檢測,如果檢測到觸摸動作時將產生中斷并觸發(fā)一個事件通知一個工作線程開始采集數據。同時,驅動將打開一個定時器,若觸摸動作仍然存在,則定時觸發(fā)同一個事件通知工作線程采集數據。驅動中采用了觸摸屏中斷以及定時器中斷2個中斷源,不僅可以監(jiān)控觸摸筆按下和抬起的動作,還可以檢測到觸摸屏按下時的拖動軌跡[5]。
    由于OMAP3530開發(fā)板與觸摸屏之間采用I2C總線通信,而Compact 7提供的樣例是以SPI接口進行數據通信,因此,需要修改PDDInitializeHardware函數和PDDGetControllerData函數。對SPI接口的讀寫改為對I2C總線的讀寫;之后在PDDTouchPanelGetPoint函數中修改代碼,按照具體觸摸屏控制芯片的數據定義格式進行坐標轉換;最后更改.reg文件中的注冊信息,定義管腳號、驅動加載位置等。Compact 7系統(tǒng)啟動過程中加載GWES模塊后,GWES模塊將根據注冊表的信息加載觸摸屏驅動。
4.5 移植內核獨立傳輸層
    在Windows CE系統(tǒng)中使用了內核獨立傳輸層KITL(Kernel Independent Transport Layer)技術,其設計目標是向開發(fā)者提供一種簡單的開發(fā)方式以支持調試服務。從Windows CE 6.0開始,KITL模塊已經獨立出OAL,在操作系統(tǒng)運行時已經有了一個獨立的KITL.dll動態(tài)鏈接庫。Compact 7操作系統(tǒng)繼承了這一特性,同時也提供了大量的程序樣例用于開發(fā)參考。
    KITL的開發(fā)過程只需要完善OEM部分代碼即可,這部分代碼位于\SRC\KITL目錄下。用戶需要實現OEMKitlStartup函數、OEMKitlInit函數,同時需要構造相關結構體數據。OEMKitlStartup的功能是構造實際參數的數據,如代表KITL連接設備的標識符字符串、記錄用戶對系統(tǒng)KITL功能配置的數據以及所有可選KITL連接設備的硬件位置。OEMKitlInit的功能是構造一個設置KITL傳輸層端口的結構體數據。
    OMAP3530開發(fā)板的KITL采用中斷方式進行驅動。中斷方式在OEMKitlStartup函數中設置。具體代碼如下:
    // Prepare interrupt
    pGPIORegs = OALPAtoUA(BSP_ETHER_GPIO_PA);
    SETREG32(&pGPIORegs->OE,
            1 << (BSP_IRQ_ETHER_KITL % 32));
    // Interrupt on falling edge
    SETREG32(&pGPIORegs->FALLINGDETECT,
            1 << (BSP_IRQ_ETHER_KITL % 32));
    OEMKitlEnableClocks(FALSE);
    之后在OEMKitlEnableClocks函數中修改IRQ管腳對時鐘的響應。具體代碼如下:
    // IRQ pin
    clockRoutines.pfnEnableDeviceFClock(OMAP_DEVICE_GPIO,
bEnable);
    其中宏定義BSP_IRQ_ETHER_KITL和OMAP_DEVICE_GPIO的值由開發(fā)板上實際連接到LAN9220的中斷信號的管腳決定。移植過程中對這兩個宏定義進行修改即可實現KITL的功能。
4.6 設置配置文件
    當創(chuàng)建一個Compact 7的工程時,可以通過添加環(huán)境變量、修改.bib和.reg等文件來重新配置BSP。Compact 7將配置文件分為兩類,一類是源代碼配置文件,如Dirs文件、Makefile文件以及Sources文件;另一類是鏡像配置文件,如.bib文件、.reg文件、.dat文件等。開發(fā)人員必須理解相關配置文件的作用和使用方法才能合理地配置系統(tǒng)資源。
    至此,BSP的開發(fā)流程已基本完成。開發(fā)移植好的BSP要在Platform Builder中編譯生成可以在硬件開發(fā)平臺上運行的二進制代碼,通過SD卡將MLO和eboot.nb0下載到Nand Flash上,然后再通過以太網下載NK.bin到開發(fā)板上。
    開發(fā)BSP 是一個基于具體硬件和軟件的復雜過程,需要開發(fā)者對硬件和軟件知識都有較為深入的了解[6]。BSP開發(fā)的正確性將直接影響到系統(tǒng)運行的穩(wěn)定性。
參考文獻
[1] 周建設.Windows CE設備驅動及BSP開發(fā)指南[M].北京:中國電力出版社,2009.
[2] 陳瑞,張永瑞,歐陽雄.基于XSCALE架構處理器WinCE系統(tǒng)BSP開發(fā)[J].電子科技,2006(2).
[3] Microsoft.BSP porting guide for Windows Embedded Compact 7[Z].2010.
[4] 李大為.Windows CE工程實踐完全解析[M].北京:中國電力出版社,2008.
[5] 張毅,王海濤.基于S3C2410A的WinCE 5.0下觸摸屏驅動的實現[J].重慶郵電大學學報(自然科學版),2008(6).
[6] 李海林,趙惠林,熊文峰.基于XScale PXA255處理器WinCE 420系統(tǒng)BSP開發(fā)[J].艦船電子工程,2006(3).

此內容為AET網站原創(chuàng),未經授權禁止轉載。