Windows CE.NET是微软公司向嵌入式领域推出的一款操作系统。它最大程度继承了桌面版Windows操作系统的丰富功能,同时又副入了许多新特性,以适应嵌入式领域的实际情况和要求。无论是商业应用需求,还是人们的多媒体消费需求,都能被采用CE操作系统的设备很轻松的满足。最新的.NET版本较之3.0版本,在实时性和稳定性上有大幅度提高,开始广泛地被平板电脑、数码相机、彩屏手机、PDA等多种高性能产品所采用。
但是,CE并不是一个通用的安装版操作系统,在形形色色的嵌入式硬件设备世界里, 一款CE系统通常只会针对某一种硬件平台生成。所以,作为原始设备生产商,必须根据自己的硬件平台和应用场合定制CE,最主要的工作就是编写适合于自己的板级支持包(BSP)。在BSP中,包含了一个重要的组成部分——BootLoader。创建一未功能完善的BootLoader,是开发WinCE系统的第一步,也是极为关键的一步。本文将结合开发实例,介绍如何开发适合于自己硬件的BootLoader。
1. 定制CE操作系统的基本知识
定制CE操作系统是采用微软的工具软件:Platform Builder(PB)。该工具能够根据用户的需求,选择构建具有不同内核功能的CE系统。同时,它也是一个集成的编译环境,可以为所有CE支持的CPU目标代码编译C/C++程序。前面所说的BSP和BootLoader程序就是在该环境下编译,并整合到CE系统中去的。一旦成功地编译了一个CE系统,就会得到一个名为nk.bin的映像文件。只要将该文件下载到目标平台(device端),就能够运行CE了。
2 .BootLoader
BootLoader是一段单独的程序代码,它存放于目标平台的非易失存储介质中,如ROM或Flash。在开发CE的过程中,它主要用于启动硬件和下载nk.bin到目标板上,并有一定的监控作用。
一般来说,对于BootLoader的功能要求并不是严格定义的,不同的场合区别很大。比如,在PC的硬件平台上,由于硬件启动根本就不是通过BootLoader(而是通过BIOS),所以BootLoader就不需要对CPU加电后的初始化做任何工作;而在笔者的开发平台(MIPS32)上,BootLoader是最先被执行的程序,所以就必须包括加电初始化程序。通常,BootLoader必须包含下载CE映像文件的功能。另外,管理监控硬件设备通常也是必须的,因为这可以极大地方便工程开发。由于BootLoader涉及到基本的硬件操作,如CPU的结构、指令等,同时又涉及到以太网下载协议(TFTP,当然也可能通过串口)和策软设定的映像文件格式。因此从零实现的话,会需要相当长的过程。好在微软为每种类型的CPU都提供了某种标准开发板的BootLoader例程,因此通常的做法是:从这些例程中寻找与硬件平台最接近的作为标本程序,然后再从自己的硬件平台上入手做相应的改动。一些新的评估板可能会由第三方的厂商来提供Bootloader。如果硬件平台是从这样的基板设计而来的话,那么最好去寻求这些厂商获取Bootloader来移植,以减少工作量。
笔者使用的硬件平台基于MIPS32架构,下载端口采用的是以太网口,同时还具备一个串口,主机相连,通过超级终端对该平台加以控制。该平台是参考AMD的一款标准估计板设计的,BootLoader以该板的BootLoader为参考进行了移植。
3. 编写BootLoader源程序
前面已经提到,由于硬件的不同,BootLoader的功能可能有多有少,此处笔者以自己开发BootLoader的过程进行叙述。
3.1 启动部分
首先要实现初台化硬件的功能。在参考板的BootLoader目录下,会发现一些.s文件,可能会是init.s或者是reset.s等,这样的文件是CPU加电后最先执行的代码。由于此处是用汇编语言编写的,所以与CPU关系紧密。一般参考板的CPU与开发平台的CPU会是相同或者是同一个架构的。笔者使用的是属于同一种CPU的情况,所以对寄存器的定义和初始化流程都可以不加改动。接着就是对于平台配置的分析,包括平台存储空间的分配、外围设备的工作设定等。一般这里的区别是非常大的。所以必须要对CPU寄存器的值作相应设定。这部分工作可能需要CPU提供商方面的帮助。
应该说,这部分工作是BootLoader的一大重点,但由于和实际的硬件非常大,所以不可能做进一步的详细叙述。
3.2 主控部分
从这一部分开始,均用C语言编写。
为了增加BootLoader对平台的控制,一般BootLoader都会设计成支持命令输入的方式,通过串口来接收用户的命令。这种机制中,如果参考板有Loader支持的话,那么可以自己添加有实用价值的命令,完成一些需要的功能。
从图2中可以看出,一般在平台调试完毕后,可以在不用人工干预的情况下自动加载CE(这也是BootLoader必需的功能之一);而在调试阶段,基本上是通过Loader所支持的命令来进行操作的。提供足够丰富的命令,能极大简化和全面测试开发平台。如表1所列,是笔者Loader所提供的命令。
表1
命令 说明
Help_______列出所有支持的命令并加以说明
Eboot _____从开发台下载CE映像并加载
Write______向某一内存地址写入数据
Read______显示某一内存地址的数据
Jump______跳转到某一地址执行程序
Xmodem___从计算机的超级终端接收以Xmodem协议传送的文件
Toy_______测试平台CPU的计数器是否运转
Flash______擦除或者更新Flash中的数据
Tlbread____显示CPU的所有TLB表
Tlbwrit____设置CPU的TLB
Macaddr___设置CPU的MAC地址
Seti_______设置平台的IP地址
这些命令涉及到平台调试的各个方面,像内存检测、Flash操作、文件下载等。借助于这些命令,不仅可以完成硬件平台的部分测试,还完成了作为CE的BootLoader程序最为重要的一个功能——下载CE映像。
3.3 下载部分
在用Platform Builder编译生成CE的映像文件后,接下来就需要将该文件下载到目标板上。如果说硬件调试功能可以由其它的程序代替而不放入BootLoader中,但是下载映像文件却是BootLoader必需的功能。
CE映像文件通常叫做nk.bin,它是Windows CE二进制数据格式文件,不仅包含了有效的程序代码,还有按照一定规则加入的控制信息。当然,也可以选择生成.sre格式的代码文件,但是相于对前一种格式,它的代码要长很多,所需要的下载时间也更长。在这里,我们以下载.bin格式的文件来说明下载的实现。
首先看一下图3所示的BootLoader下载部分的流程图。
通常,在Platform Builder自带的代码中,会包含完成TFTP连接的了基本的函数。
*初始化TFTP连接:用函数EbootInitTFtp()和EbootInitTFtpd()完成。
*登记解析.bin格式数据的回调函数:用EbootTFtpdServerRegister()完成。
*发出连接请求:用EbootSendBootme()完成。
*接收主机端发出的数据包:用EbootTFtpReceiver()完成。
在这里,需要重点说明的有两点。
①对于接收数据包的函数EbootTFtpReceiver(),它只能处理已经存入内存的以太网包,也就是说,从以太网控制器接收数据的功能必须要用户去完成。由于这一功能与硬件密切相关,所以不能使用PB自带的函数来完成。
②函数EbootTFtpdServerRegister()会登记一个回调函数,一般用户可以自己定义这个函数,该函数用于完成,bin格式数据的解析和保存,有效数据至目的地RAM。PB有自带的例程函数可作参考。一般来说,如果目的地就是RAM的话,直接参考例程函数即可。但是如果目的地就是Flash,不要直接存入Flash(字为单位),应先存入内存中待下载完毕以后再导入Flash。当然,这种方法必须要有足够的内存。如果没有足够的内存,也可以缓存部分数据后,分段写入Flash。
3.4 支持DOC
对于WinCE操作系统而言,丰富的多媒体功能是其一大特点,使其成为当前消费类电子产品操作系统中的一个不错选择。但是随之而来的问题是,系统的容易已经大大超过出了传统嵌入式系统上百KB的数量级。一般来说,如果选择了图形界面和汉语支持,容量一般会超过16MB。DOC(Disk o-n Chip)则提供了一种相对廉价的大存储容量的解决方案。
DOC本质上是一种加以软件控制的NAND格式的Flash,通过TFFS这一软件层提供对WinCE的支持。
由于DOC不能像内存一样被直接访问,所以其加载WinCE的过程有些特殊,必须要在BootLoader中加入专门的代码,才能使用DOC来存放WinCE映像文件。
为了说明怎样在Loader文件中提供对DOC的支持,先看一下如何采用DOC系统启动CE,如图4所示。
从图4可以看出,当采用DOC作为存储体的时候,实际上是在启动的时候把映像文件拷贝到内存中执行。为了实现这一启动过程,就必须涉及到DOC的读写操作。首先要从M-SYSTEM的网站上获取DOC的BOOT软件开发包。在这个开发包里,提供了一系列DOC的操作函数。将此开发包嵌入到CE的BootLoader中去,然后按照图4的步骤,调用相应的读写函数完成这一过程。对于开发包中相关函数的说明,笔者就不具体介绍了,可以参考开发包的说明文档。
4 BootLoader的编译、链接和下载
BootLoader程序可以通过PB的集成编译环境编译链接,控制文件为.bib文件,下面是一个简单的BootLoader的.bib文件。
MEMORY
CLI 9fc00000 00050000 RAMIMAGE
RAM 80080000 00070000 RAM
CONFIG
COMPRESSION=ON
SRE=ON
ROMSTART=9fc00000
ROMSIZE=00020000
ROMWIDTH=32
ROMOFFET=000000
MODULES
Nk.exe $(_FLATRELEASEDIR).exe CLI
MEMORY部分 定义了生成的映像文件的目标地址,以及程序运行可以使用的内存空间。
CONFIG部分 COMPRESSION是否对目标代码进行压缩;SRE是否生成格式为sre的目标代码;ROMSTART与ROMSIZE、ROMWIDTH、ROMOFFSET共同定义了开发平台上存放BootLoader物理介质的起始地址、大小、宽度和偏移量。
MODULES部分 定义了BootLoader所包含的文件,一般就只有一个文件:cli.exe。
编译过程中,首先用命令build-c编译生成文件cli.exe,然后用romimage cli.bib命令产生最后的映像文件cli.sre。
对于BootLoader文件的下载;有很多种方法:可以通过仿真器下载;也可以通过其它调试程序下载;还可以直接烧写到Flash中。需要说明的一点是,这些方法可能会要求不同的映像格式。在PB环境下,可以生成的有.sre格式、纯二进制格式(用于直接烧写Flash)以及和CE映像一样的.bin格式。
结语
从CE的BootLoader开发流程可以看出,BootLoader在完成下载CE映像和加载映像的主要功能外,还具有一些调试硬件的功能。当然,这些功能不是必需的,随不同的用户可能有自己的定义。但是不管Loader的功能设计得多么简单或者是多么复杂,都是在开发CE系统中不可跳过的一环。实际上,由于Loader有和CE系统交互数据的区域,所以还有对CE启动过程的控制作用,也是PB控制目标板CE启动的一个窗口。可以说,一个功能齐全的Loader,不论是对调试硬件,还是控制和检测CE系统,甚至是成为产品之后的维护工作,都是大有帮助的。
编写BootLoader是开发WinCE系统第一步,也是关键的一步。只有得到一个稳定工作的Loader程序,才能够更进一步开发WinCE的BSP,直至最后整个系统的成功。