基于S3C2410的Windows CE 5.0 BSP移植

出處：楊真人發(fā)布于：2008-08-27 10:03:33

　　摘要嵌入式開發(fā)中一個重要的環(huán)節(jié)是板級支持包（BSP）的開發(fā)，實際開發(fā)過程更傾向于移植BSP而不是重新開發(fā)BSP。本文先介紹了samsung公司的S3C2410微處理器和嵌入式操作系統(tǒng)Windows CE 5.0 特性，分析BSP結構，在此基礎上，通過bootloader, OAL, 觸摸屏驅動的移植來具體探討B(tài)SP移植過程。

　　1 引言

　　在當今后PC時代，嵌入式系統(tǒng)應用得越來越廣泛，嵌入式產(chǎn)品充斥著許多領域，日常生活的手機，MP4，PDA等都屬于典型的嵌入式系統(tǒng)。在嵌入式系統(tǒng)中，微處理器和操作系統(tǒng)是進行應用開發(fā)的基礎。在微處理器方面，S3C2410是Samsung公司推出的一款基于ARM920T內(nèi)核的16/32位RISC嵌入式CPU，主要面向手持設備以及高性價比、低功耗的應用。在操作系統(tǒng)方面，Windows CE 5.0是由微軟提供的一款嵌入式操作系統(tǒng)，在Windows CE 4.2基礎上，它又加入了一些新特性以滿足市場需求。板級支持包 (Board Support Package，BSP)是操作系統(tǒng)的一個組成部分，提供對硬件的支持。BSP的開發(fā)在整個產(chǎn)品開發(fā)時間上占了很大比例，快速的移植滿足產(chǎn)品需求的BSP在競爭激烈的市場環(huán)境里顯得很重要。目前已有許多關于S3C2410、Windows CE以及BSP相關的研究報道，文獻[1]研究基于s3c2410的GPS通信技術及實現(xiàn)，文獻[2]中詳盡分析Windows CE的結構，文獻[3]中歸納了Windows CE 4.2專用操作系統(tǒng)的定制和裁剪方法，文獻[4]則探討基于DSP嵌入式多媒體應用系統(tǒng)板級支持包的開發(fā)。目前關于Windows CE的應用主要采用Windows CE 4.2及以下版本，本文研究基于S3C2410的Windows CE 5.0 BSP移植技術。

　　2 Windows CE 5.0及BSP結構分析

　　移植基于S3C2410的Windows CE 5.0 BSP，需要分析Windows CE 5.0 及BSP結構。Windows CE 5.0是一款開放的、可升級的32位嵌入式操作系統(tǒng)，具有高可靠性，是一種硬實時嵌入式操作系統(tǒng)，它可以在多種處理器架構（如x86、MIPS、ARM和SH4）上運行，Windows CE支持ARM體系結構，這是基于S3C2410 處理器進行BSP移植的前提條件。Windows CE 5.0 BSP通常包含以下幾部分：Bootloader，OAL(OEM adaptation layer)，設備驅動程序，配置文件等。www.51kaifa.com

　　BootLoader是加電即運行的一段程序，它初始化硬件，建立系統(tǒng)的內(nèi)存空間映射，為終調(diào)用系統(tǒng)內(nèi)核做準備。在Windows CE 5.0系統(tǒng)中，它主要用于和啟動鏡像nk.bin，也就是兩種工作模式：啟動加載模式：用戶終使用的產(chǎn)品即為該模式；模式：鏡像首先被bootloader到目標機的RAM中，然后被固化到Flash。

　　設備驅動程序按照導出的接口不同可分為：本機驅動程序以及流接口驅動程序.本機驅動程序有GEWS.exe加載的鼠標，鍵盤，觸摸屏，顯示驅動等。而流接口驅動程序使用一組流函數(shù)來實現(xiàn)，通常由Device.exe加載，如網(wǎng)卡，聲卡，USB等。

　　OAL是邏輯上駐留在Windows CE內(nèi)核與目標設備之間的代碼層，在物理上OAL與內(nèi)核庫連接來產(chǎn)生內(nèi)核可執(zhí)行文件。OAL簡化了操作系統(tǒng)與目標代碼之間的通信，OAL代碼用來處理中斷，記時器，電源管理，通用I/O控制等[5]。

　　Configuration File里面包含的是與生成的鏡像相關的配置信息。www.51kaifa.com

　　移植Windows CE下S3C2410對應的BSP，就是修改Windows CE自帶的BSP或者修改硬件平臺以前版本的BSP的幾個主要組成部分，使得BSP能有效支持硬件系統(tǒng)。

　　3 BSP移植

　　如果從零開始開發(fā)Widows CE 5.0 BSP，則需要相當長的時間。通常的做法是：⑴將自己硬件平臺基于Windows CE 4.2及以前版本的BSP移植到Windows CE 5.0系統(tǒng)上；⑵從Windows CE 5.0 BSP中尋找與硬件平臺接近的作為模板，然后再從自己的硬件平臺上入手做相應的修改，從而得到可以在自己系統(tǒng)上使用的BSP。本文探討的BSP移植屬于種情況。

　　本次移植平臺采用的是深圳英蓓特公司的EdukitIII實驗箱，微處理器是S3C2410，外帶64M NAND Flash芯片等相關硬件資源。軟件資源有：edukit2410包（Windows CE 4.2版本下的BSP）。

　　3.1 bootloader移植

　　bootloader的執(zhí)行流程如下：

　　⑴ 執(zhí)行startup.s：對CPU，內(nèi)存控制器，Cache等做一些基本的初始化。

　　⑵ 初始化串口：調(diào)用函數(shù)OEMInitDebugSerial（）來完成。

　　⑶ 初始化平臺：調(diào)用函數(shù)OEMPlatformInit（），主要對所需硬件資源進行初始化，通常包括：以太網(wǎng)控制器（CS8900A）、系統(tǒng)時鐘、存儲設備以及其他一些外圍設備。

　　⑷ 調(diào)用函數(shù)OEMPreDownload（）：做一些準備工作如獲取IP地址，初始化TFTP連接等。

　?、?執(zhí)行函數(shù)DownloadImage（）：鏡像到SDRAM中。www.51kaifa.com

　?、?調(diào)用OEMLaunch（）函數(shù)啟動操作映像。

　　其中startup.s,OEMInitDebugSerial（）可以與OAL共享使用，兩函數(shù)的修改在OAL移植過程中敘述。

　　Bootloader移植主要過程有：

　?、?修改相應的dir，source文件，下面列出部分庫路徑：

　　TARGETLIBS=\

　　$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\csp_arm.lib \

　　$(_COMMONOAKROOT)\lib\$(_CPUDEPPATH)\eboot.lib \

　　$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\cs8900dbg.lib \

　　其中csp_arm.lib這個庫只存在于Windows CE 4.2的$(_PUBLICOAKROOT)，是ARM體系結構鏈接庫之一，在Windows CE 4.2系統(tǒng)下位于PUBLIC目錄，而在Windows CE 5.0系統(tǒng)下存在于PLATFORM，導致編譯系統(tǒng)找不到該庫文件，因此，修改這個庫的鏈接路徑，使得Platform builder這個編譯系統(tǒng)能夠找到這個鏈接庫。

　?、?修改makefile.inc，因為該文件指定生成eboot.bin(Ethernet bootloader鏡像)所需要的文件以及拷貝eboot.bin到releasedir目錄，其中：

　　romimage $(_TARGETPLATROOT)\eboot\boot.bib

　　為生成生成eboot.bin所需要的配置文件，否則，系統(tǒng)通過編譯卻無法生成eboot.bin.

　　⑶ 修改boot.bib，使其不與config.bib中的內(nèi)存分配造成沖突。

　?、?改進eboot，因為eboot燒寫NK.BIN(OS鏡像)的時候會查找BINFS分區(qū)，然后把的image燒寫到BINFS分區(qū)。如果沒有找到現(xiàn)存的BINFS分區(qū)，eboot會低格NAND FLASH，并創(chuàng)建MBR(main boot record),在MBR中有分區(qū)表。目前多支持4個分區(qū)，而BINFS分區(qū)的大小是以NK.BIN展開的大小按block對齊，所以會出現(xiàn)個問題，當修改過重新生成的NK.BIN比之前寫進NAND FLASH的IMAGE大并且超出block對齊的時候，將會導致燒寫新的NK.BIN失敗，我們可以通過每次燒寫NK.BIN前先低格NAND FLASH來解決這個問題，但顯然這不是妥善的解決方法，增加用戶使用復雜度，所以我們可以把BINFS分區(qū)的大小固定，而這個固定的大小可以參考生成NK.BIN的config.bib中定義的ROMSIZE，這樣無論NK怎么修改，BINFS一經(jīng)創(chuàng)建無需更改，eboot把NK寫進NAND FLASH之后，會把剩余的FREE空間創(chuàng)建一個FAT分區(qū)，如果我們要實現(xiàn)HIVE REGISTRY就可以把這個分區(qū)mounts成MountAsBootable。

　　3.2 OAL移植

　　OAL的移植過程中，OEM主要實現(xiàn)以下幾個函數(shù)：Startup.s，調(diào)試串口函數(shù)，OEMInit函數(shù)，系統(tǒng)時鐘函數(shù)，中斷處理函數(shù)等。

　?、?修改Startup.s，此函數(shù)為OS啟動時個要調(diào)用的函數(shù)，也是OEM要實現(xiàn)的重要函數(shù)之一，主要完成的功能是：將CPU初試化到一種已知的狀態(tài)；并調(diào)用內(nèi)核初始化函數(shù)kernelstart。Startup.s需要修改，修改后的部分代碼如下：

　　……

　　ldr r0, = 0X4A000008

　　ldr r1, = 0xffffffff ; 禁止所有中斷

　　str r1, [r0]

　　ldr r0, = 0X4A00001C

　　ldr r1, = 0x7ff ; 禁止所有子中斷

　　str r1, [r0]

　　……..

　　add r0, pc, #g_oalAddressTable - (. + 8)

　　bl KernelStart //跳轉到KernelStart

　?、?修改串口調(diào)試函數(shù)。執(zhí)行完Startup.s,系統(tǒng)就跳轉到Kernelstart函數(shù)，位于private目錄，該函數(shù)個任務就是初始化串調(diào)試口，否則，就無法進行后面的調(diào)試工作。其中OEMReadDebugByte, OEMWriteDebugByte, OEMWriteDebugString不用做修改，需要注意的是OEMInitDebugSerial，選UART0，UART1的寄存器配置不一樣，若選用UART0，使用配置：

　　s2410IOP->rGPHCON &= ~((3 << 4) | (3 << 6));

　　s2410IOP->rGPHCON |= ((2 << 4) | (2 << 6));

　　而選擇UART1，則使用配置的是：

　　s2410IOP->rGPHCON &= ~((3 << 8) | (3 << 10));

　　s2410IOP->rGPHCON |= ((2 << 8) | (2 <<10));

　?、?實現(xiàn)OEMInit()，該函數(shù)將調(diào)用以下函數(shù)：OALCacheGlobalsInit()，OALIntrInit()，OALTimerInit（），OALKitlStart()來初始化Cache Global,中斷，時鐘，啟動KITL，實現(xiàn)代碼如下：

　　void OEMInit()

　　{

　　OALCacheGlobalsInit();// 初試化cache globals

　　if (!OALIntrInit()) {

　　OALMSG(OAL_ERROR, (

　　L"ERROR: OEMInit: failed to initialize interrupts\r\n"

　　));

　　} // 初試化中斷

　　OALTimerInit(1, S3C2410X_PCLK/2000, 0); // 初始化時鐘

　　OALKitlStart();// 初始化KITL

　　}

　?、?實現(xiàn)OALTimerInit(),該函數(shù)用于初始化OS TIMER,設置每毫秒產(chǎn)生一個System tick,為系統(tǒng)計數(shù)，觸發(fā)進程調(diào)度。由CPU的運行主頻和硬件定時器資源來確定，執(zhí)行過程有：初始化時鐘狀態(tài)全局變量，初始化高分辨率時鐘函數(shù)指針，使能TIMER。

　?、?實現(xiàn)中斷處理處理函數(shù)：OALIntrInit()，該函數(shù)通常先初始化中斷映射表，因為WINCE為了模塊化，把平臺相關物理中斷號和系統(tǒng)中斷號建立映射。然后清除外部中斷，內(nèi)部中斷等。

　　3.3 驅動移植

　　以觸摸屏為例，來探討Windows CE 5.0系統(tǒng)驅動程序移植。這里以三星公司ARM9內(nèi)核芯片S3C2410觸摸屏接口為基礎，通過外接4線電阻式觸摸屏構成硬件基礎,整個觸摸屏由橫向電阻線和縱向電阻線組成。觸摸屏驅動的主要函數(shù)組成有：

　　TSP_Poweron 該函數(shù)將執(zhí)行觸摸屏的一些初始化，主要是寄存器的配置。

　　DdsiTouchPanelEnable：使能DDSI接口，使得硬件能將流數(shù)據(jù)提供給DDSI接口，就可以實現(xiàn)觸摸的操作了。

　　DdsiTouchPanelSetMode：模式設置函數(shù)，設置觸摸屏是高采樣率還是低采樣率

　　DdsiTouchPanelGetPoint ：觸摸屏進行采樣函數(shù)

　　TSP_CalibrationPointGet：坐標轉換函數(shù)，該函數(shù)實現(xiàn)將從AD采樣植轉換成坐標。

　　移植主要過程：

　?、?修改source文件，要添加如下庫文件：

　　TARGETLIBS=$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib

　　SOURCELIBS= \

　　$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\tch_cal.lib \

　　$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\tchmdd.lib \

　　因為這個驅動在Windows CE 4.2下面是在Public目錄，而這里將該觸摸屏移到了Platform下面，在Windows CE4.2下面是沒有以上三條鏈接庫，但Platform，Public編譯路徑，先決條件都不同。因此引用的庫不一樣。

　?、?刪除如下庫文件：

　　$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\drvlib.lib

　　該庫在Windows CE 4.2系統(tǒng)下為觸摸屏與音頻共用庫，但在Windows CE5.0系統(tǒng)下，這個庫已經(jīng)不是必要的并且已經(jīng)不存在了，所以刪除掉，否則系統(tǒng)會出編譯錯誤。

　?、切薷膒latform.bib,將我們移植過來的驅動dll包含到nk.bin中

　?、刃薷膒latform.reg,其中CalibrationData是觸摸屏的一個參數(shù)：

　　[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]

　　"MaxCalError"=dword:7

　　portrait

　　"CalibrationData"="517,610 897,934 142,936 129,290 891,285 "

　　其他驅動的過程與觸摸屏類似。

　　3.4 移植小結

　　此次移植是升級BSP，而硬件上基本沒有變化，因此很多代碼不需做修改即可使用，通過以上移植，不難發(fā)現(xiàn)此類移植BSP過程中所要做的工作主要在以下幾個方面：

　　⑴ 修改dir文件，在dir文件中指定了當前目錄哪些文件夾被系統(tǒng)編譯，編譯器根據(jù)dir層層搜索，而移植BSP不可避免的帶來了目錄的變化，通過修改dir來指定新的編譯路徑。

　　⑵ 修改sources文件，在sources文件中，指定了編譯類型有PLATFORM，OAK；編譯的時候引用的庫sourcelib,targetlib不一樣，移植的時候一定得注意。目標文件類型有Library，Dynlink，program；include字段包含的則是編譯時候所需要的頭文件目錄。有個比較特殊的sources是位于Platform(例如smdk2410)下的sources.cmn，它包含了該平臺的通用庫，頭文件路徑，這個文件在移植過程中需要修改的，否則，編譯出錯。

　?、?修改platform.bib，platform.reg等文件，因為這兩個文件決定了鏡像中包含哪些模塊(dll)以及注冊表相關信息，驅動移植的過程中，每個模塊的改動都需要修改這兩個配置文件。

　?、?驅動源文件中的頭文件的修改以及函數(shù)，變量修改等，這些依據(jù)編譯時候出現(xiàn)的錯誤來確定。

　　除此之外，各部分的移植還需特別注意的地方有：

　　Bootloader部分：因為bootloader，燒寫，啟動鏡像過程會涉及到內(nèi)存地址的問題，各種入口地址不能出錯誤，以及內(nèi)存超出范圍，沖突都需要特別小心。尤其是g_oalAddressTable這個表，這個表定義了物理地址虛擬地址之間的轉換以及內(nèi)存的大小，如果設置不正確，將出現(xiàn)校驗錯誤，失敗或者鏡像無法啟動等錯誤。

　　OAL部分：startup.s以及OEMInitDebugSerial兩函數(shù)需要特別注意，這兩個主要是初始化硬件及串口，這是系統(tǒng)運行及驅動調(diào)試的基礎，如果硬件配置以及調(diào)試串口有改變，則需要適當?shù)男薷?。此次BSP移植，因硬件平臺沒有變化，因此OAL部分很多代碼無須修改即可使用。

　　驅動部分：Windows CE4.2與Windows CE5.0的結構，庫有了很大的改變，因此需要修改引用庫路徑，以及頭文件的引用路徑，大部分驅動都將會遇到這樣的問題。

　　4 結束語

　　本文創(chuàng)新點：通過對BSP結構分析，將具體平臺的Windows CE 4.2 BSP移植到Windows CE 5.0版本，包括移植bootloader,OAL,驅動程序，使之能夠通過編譯并生成鏡像，已經(jīng)能在平臺上成功運行。通過這次移植，使筆者體會到BSP移植是一個挺復雜，煩瑣的過程，因Windows CE 5.0跟Windows CE 4.2 BSP包的組織結構不同，導致很多鏈接庫無法找到或者是這些庫已經(jīng)被替換，刪除，只有耐心的根據(jù)這些錯誤提示來定位，有時候也需要去makefile里去找答案。不過移植BSP比重新開發(fā)BSP更加節(jié)省開發(fā)時間，從而縮短產(chǎn)品的研發(fā)。

　　歡迎轉載,信息來自維庫電子市場網(wǎng)（m.58mhw.cn）