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，则需要相当长的时间。通常的做法是：（1）将自己硬件平台基于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的执行流程如下：
（1）执行startup.s：对CPU，内存控制器，Cache等做一些基本的初始化。
（2）初始化串口：调用函数OEMInitDebugSerial()来完成。
（3）初始化平台：调用函数OEMPlatformInit()，主要对所需硬件资源进行初始化，通常包括：以太网控制器(CS8900A)、系统时钟、存储设备以及其他一些外围设备。
（4）调用函数OEMPreDownload()：做一些准备工作如获取IP地址，初始化TFTP连接等。
（5）执行函数DownloadImage()：下载镜像到SDRAM中。
（6）调用OEMLaunch()函数启动操作映像。
其中startup.s,OEMInitDebugSerial()可以与OAL共享使用，两函数的修改在OAL移植过程中叙述。
Bootloader移植主要过程有：
（1）修改相应的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这个编译系统能够找到这个链接库。
（2）修改makefile.inc，因为该文件指定生成eboot.bin(Ethernet bootloader镜像)所需要的文件以及拷贝eboot.bin到releasedir目录，其中：
romimage $(_TARGETPLATROOT)ebootoot.bib
为生成生成eboot.bin所需要的配置文件，否则，系统通过编译却无法生成eboot.bin.
（3）修改boot.bib，使其不与config.bib中的内存分配造成冲突。
（4）改进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函数，系统时钟函数，中断处理函数等。
（1）修改Startup.s，此函数为OS启动时第一个要调用的函数，也是OEM要实现的重要函数之一，主要完成的功能是：将CPU初试化到一种已知的状态;并调用内核初始化函数kernelstart。Startup.s需要修改，修改后的部分代码如下：
本文关键字：嵌入式 嵌入式系统-技术，单片机-工控设备 - 嵌入式系统-技术
