1 引言

在當今后PC時代，嵌入式系統應用得越來越廣泛，嵌入式產品充斥著許多領域，日常生活的手機，MP4，PDA等都屬于典型的嵌入式系統。在嵌入式系統中，微處理器和操作系統是進行應用開發的基礎。在微處理器方面，S3C2410是Samsung公司推出的一款基于ARM920T內核的16/32位 RISC嵌入式CPU，主要面向手持設備以及高性價比、低功耗的應用。在操作系統方面，Windows CE 5.0是由微軟提供的一款嵌入式操作系統，在Windows CE 4.2基礎上，它又加入了一些新特性以滿足市場需求。板級支持包 (Board Support Package，BSP)是操作系統的一個組成部分，提供對硬件的支持。BSP的開發在整個產品開發時間上占了很大比例，快速的移植滿足產品需求的BSP 在競爭激烈的市場環境里顯得很重要。目前已有許多關于S3C2410、Windows CE以及BSP相關的研究報道，文獻[1]研究基于s3c2410的GPS通信技術及實現，文獻[2]中詳盡分析Windows CE的結構，文獻[3]中歸納了Windows CE 4.2專用操作系統的定制和裁剪方法，文獻[4]則探討基于DSP嵌入式多媒體應用系統板級支持包的開發。目前關于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位嵌入式操作系統，具有高可靠性，是一種硬實時嵌入式操作系統，它可以在多種處理器架構（如x86、MIPS、ARM和 SH4）上運行，Windows CE支持ARM體系結構，這是基于S3C2410 處理器進行BSP移植的前提條件。Windows CE 5.0 BSP通常包含以下幾部分：Bootloader，OAL(OEM adaptation layer)，設備驅動程序，配置文件等。

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

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

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

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

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

3 BSP移植

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

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

3.1 bootloader移植

bootloader的執行流程如下：

⑴ 執行startup.s：對CPU，內存控制器，Cache等做一些基本的初始化。

⑵ 初始化串口：調用函數OEMInitDebugSerial（）來完成。

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

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

⑸ 執行函數DownloadImage（）：下載鏡像到SDRAM中。

⑹ 調用OEMLaunch（）函數啟動操作映像。

其中startup.s,OEMInitDebugSerial（）可以與OAL共享使用，兩函數的修改在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系統下位于PUBLIC目錄，而在Windows CE 5.0系統下存在于PLATFORM，導致編譯系統找不到該庫文件，因此，修改這個庫的鏈接路徑，使得Platform builder這個編譯系統能夠找到這個鏈接庫。

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

romimage $(_TARGETPLATROOT)ebootboot.bib

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

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

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

3.2 OAL移植

OAL的移植過程中，OEM主要實現以下幾個函數：Startup.s，調試串口函數，OEMInit函數，系統時鐘函數，中斷處理函數等。

⑴ 修改Startup.s，此函數為OS啟動時第一個要調用的函數，也是OEM要實現的重要函數之一，主要完成的功能是：將CPU初試化到一種已知的狀態；并調用內核初始化函數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

⑵ 修改串口調試函數。執行完Startup.s,系統就跳轉到Kernelstart函數，位于private目錄，該函數第一個任務就是初始化串調試口，否則，就無法進行后面的調試工作。其中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));