近期,公司让我负责一个嵌入式消费产品的开发项目。此产品原来的操作系统是WinCE 5.0,现在因应市场需求不但要增加功能更加强大的硬件,而且公司也要求把操作系统升级为WinCE 6.0。在接手此项目后,我立即开始进行操作系统的定制开发,但结果却是欲速则不达。
后来,我在时间和成本的多重压力因素下反思时,发现我犯了一个致命的错误,就是为了更快的把产品推向市场,在开发过程应该是移植操作系统而不是重新定制操作系统。本文根据我在此项目上得到的经验和总结,先分析BSP移植对WinCE的重要性和影响,然后在此基础上通过对Bootloader、OAL和驱动程序的移植来具体探讨BSP的移植过程。
什么是WinCE操作系统移植?
(1)为什么要进行操作系统移植?
目前嵌入式系统应用变得越来越广泛了,嵌入式产品充斥着许多领域,如日常生活的手机、MP4、PDA等都属于典型的嵌入式系统。随着技术和消费者需求的变化,即使是同一类型的嵌入式产品也会存在着硬件平台的变化,或会存在着软件平台的更新换代。因此,为了更快的适应市场需求,在实际开发过程更倾向于移植操作系统而不是重新开发操作系统。这样不但可以节省时间,还能大大提高开发效率。
由于嵌入式系统是一个软硬件紧密结合的系统,因此操作系统移植包含两个层面上的工作:一个层面是CPU级的,另一个层面是板级的。由于WinCE操作系统几乎完全是用C语言编写的,所以可移植到众多的32位微处理器上。这其中包括ARM、x86、MIPS和SHx等,而且CPU级的移植通常由微软或芯片制造商来完成,这会极大地减轻0EM厂商开发过程中移植操作系统的工作量,但板级层面的移植则还是需要由OEM厂商来完成的。
一般来说,一个WinCE系统包括四层结构:应用程序、WinCE内核映像、板级支持包(BSP)、硬件平台。而基本软件平台则主要由WinCE系统内核映像(OS Image)和板卡支持包(BSP)两部分组成。因为WinCE系统是一个软硬件紧密结合的系统,因此即使CPU处理器相同,但是如果开发板上的外围硬件不相同,这个时候还是需要修改BSP来完成一个新的BSP。因此换句话说,就是WinCE的移植过程主要是改写BSP的过程。
(2)什么是板级BSP移植?
一般来说,从零开始开发和定制WinCE BSP是需要相当长的时间,BSP的定制开发在整个嵌入式产品开发时间上占了很大比例。所以,快速的BSP移植是适应激烈竞争的市场环境的一个捷径。BSP(Board Support Packet——板级支持包)是介于底层硬件和上层软件之间的底层软件开发包,它主要的功能是给上层提供统一接口,同时屏蔽各种硬件底层的差异,以及提供操作系统的驱动及硬件驱动。简单的说,就是BSP包含了所有与硬件有关的代码,为操作系统提供了硬件平台无关性。因此,通过BSP系统,就能将CPU的硬件系统与Windows CE的软件系统联系为一个整体。
从WinCE开发文档中我们可知,BSP是一个包括启动程序Bootloader、OEM适配层程序(OAL)、标准开发板(SDB)和相关硬件设备的驱动程序和配置文件的软件包。其中Bootloader是加电即运行的一段程序,它能初始化硬件,建立系统的内存空间映射,为最终调用系统内核做准备。主要用于下载和启动镜像nk.bin。而OAL则是逻辑上驻留在Windows CE内核与目标设备之间的代码层,OEM厂商使用这些代码把WinCE适配到自己的硬件上;在物理上OAL是与内核库连接在一起产生内核可执行文件。OAL简化了操作系统与目标代码之间的通信,OAL代码用来处理中断、记时器、电源管理、通用I/O控制等。最后,设备驱动程序是指本机驱动程序以及流接口驱动程序。本机驱动程序有GEWS.exe加载的鼠标、键盘、触摸屏、显示驱动等;而流接口驱动程序使用一组流函数来实现,通常由Device.exe加载,如网卡、声卡、USB等。
WinCE BSP移植的流程和步骤
从前文分析我们可以知道,WinCE系统移植的重点是BSP 的移植。而BSP移植主要包括启动程序Bootloader、OEM适配层程序OAL、标准开发板(SDB)本地驱动程序以及一些文件配置的修改。以下是WinCE BSP移植的主要内容和流程步骤:
(1)启动程序Bootloader的移植步骤
修改Bootloader是移植Win CE系统第一步,也是关键的一步。只有得到一个稳定工作的启动程序,才能够进一步完成WinCE BSP的移植。Bootloader主要用来管理目标平台的启动过程,它是一段单独的程序代码,通过这段小程序可以初始化硬件设备、建立内存空间的映射图和下载操作系统的映像文件等,从而将系统的软硬件环境带到一个合适的状态,它一般存放于目标平台的非易失存储介质中,如ROM或Flash。
一般来说,对于Bootloader的功能,不同的场合区别很大。比如,在桌面Windows版的PC硬件平台上,由于硬件启动根本就不通过Bootloader(而是通过BIOS),所以Bootloader就无需对CPU加电后的初始化做任何工作;而在嵌入式WinCE平台上,Bootloader是最先被执行的程序,所以就必须包括加电初始化程序,同时通常Bootloader必须包含下载WinCE映像文档的功能。由于Bootloader会涉及到基本的硬件操作,如CPU的结构、指令等,也会又涉及到以太网下载协议和映像文档格式。因此,从零开发实现的话会需要相当长的过程,通常的做法是利用微软为每种类型的CPU提供的某种标准研发板的Bootloader例程。
根据我在这次项目移植得到的经验,Bootloader的移植步骤主要是:①是修改相应的dir、source文件;②是修改makefile.inc;③是修改boot.bib,使其不与config.bib中的内存分配造成冲突;④是改进eboot,因为eboot烧写NK.BIN的时候会查找BINFS分区,然后把下载的image烧写到BINFS分区。
(2)OAL的移植步骤
OAL的全称是OEM Adaption Layer,即原始设备制造商适配层。它是位于Windows CE内核和目标硬件平台之间的一个代码层,OAL主要负责Windows CE与硬件通信,它与CPU、中断、内存、时钟和调试口等核心设备相关,也是OAL各个模块代码被编译后(.lib)和其它内核库链接到一起形成Windows CE的内核可执行文档NK.EXE的关键。简单的说,OAL就是用来屏蔽CPU平台的细节和抽象硬件功能,以实现操作系统内核的可移植性。
从逻辑结构上看,OAL位于WinCE操作系统的内核与硬件之间,是连接WinCE系统与硬件的枢纽;从功能上看,OAL颇似桌面PC上的BIOS,具有初始化设备、引导操作系统以及抽象硬件功能等作用。但与B10S不同的是,0AL隶属于操作系统,是操作系统的一部分。
从我在这次项目中得到的经验来看,Windows CE安装目录的子目录中都包含有OAL的部分源码。OAL的移植实现应是在fwxsc1.s、main.c、Flash.c、Edeviceinit.c等文件中,可根据实际需要修改相应的代码。在OAL移植过程中,主要是修改这几个函数:修改Startup.s函数、修改串口调试函数、修改OEMInit函数、修改系统时钟函数和修改中断处理函数等。实际上,大多数情况下开发工程师对OAL只要修改即可,甚至无需修改。
(3)驱动程序的移植和开发
驱动程序(Device Drivers)是指能够管理虚拟或者物理设备、协议、服务等的一段软件模块,操作系统是通过驱动程序直接和硬件打交道的。设备驱动程序能为WinCE提供设备控制功能,包括:LCD/LED/VGA/SVGA显示设备、鼠标、键盘和触摸屏等。根据我在这次项目移植得到的经验,建议设备驱动程序的移植可通过Platform. Builder创建一个新的平台,然后再根据硬件平台的需要插入和移除驱动。一般来说,需要修改的文件有Platform. Bib、Platform. reg及驱动程序源代码等。
(4)平台文件配置的修改
平台配置文件包括源代码配置文件和操作系统镜像配置文件。源代码配置文件主要是告诉Build工具需要用到的路径,包括Dirs文件、Sources文件和Makefile文件等。操作系统镜像配置文件则主要用于给Makeimag工具生成操作系统镜像,包括.bib、.reg、.dat、.db等文件。因此,在进行BSP移植的时候,也需要对这些平台配置文件进行适当的修改和变更。
(5)移植时需特别注意的地方
很多嵌入式开发实践都证明BSP移植是一个挺复杂、烦琐的过程。因为WinCE 不同版本的BSP包的组织结构是不同的,所以会导致很多链接库无法找到或者是这些库已经被替换、删除,唯一的方法是只有耐心的根据错误提示来一一定位修改。
例如,在移植Bootloader时因为Bootloader的下载、烧写、启动镜像过程会涉及到内存地址,所以在处理各种入口地址时应该要避免出现差错或内存超出范围,尤其是处理地址冲突时需要特别小心。还有在移植OAL时,startup.s以及OEMInitDebugSerial两个函数需要特别注意,因为它们主要是初始化硬件及串口,系统运行及驱动调试的基础,如果硬件配置以及调试串口有改变,则需要适当的修改。