WinCE案例解说开发实现OEM函数.doc.pdf

《WinCE案例解说开发实现OEM函数.doc.pdf》由会员分享，可在线阅读，更多相关《WinCE案例解说开发实现OEM函数.doc.pdf（25页珍藏版）》请在三一文库上搜索。

1、案例解说开发实现OEM函数 3.1 DeviceEmulator虚拟平台的硬件设计 尽管三星的 S3C2410作为典型的 SoC (System on Chip)芯片片内己经集成了开发消费类嵌入 式产品所需的人多数端II 外设控制器，与木书相关的典型的外设端II 有 UART 串口、内 存控制器、 LCD 控制器等，但是仍然需耍一些外接的端口控制器，被DeviceEmulator的虚拟 硬件平台使用的 主要是以 A 网接口和 PCMCIA 总线的控制器。虽然DeviceEmulator 是一个虚拟的基于 S3C2410 的开发板，但是虚拟的逼真度相当高，微软为之开发的BSP的各组成部分 是基于

2、一个统一的硬件 平台的，构成了一个完整的恢入式系统。 实际上，DeviceEmulator 的 前身是在存在于WindowsCE5.() 及以前版本屮的一套基于一块真实的三星S3C2410 开发板的BSP,可以直接在实际硬件平台上运 行，当时的 Emulator调试工具是棊于x86 平台的。 为了后文讲述 DeviceEmulator BSP的 BootLoader的 OEM 函数开发实例做准备，这里有必要 先探讨一卜 DeviceEmulator这个虚拟的嵌入式平台的硬件设计，重点在于搞清楚与软件开发密切 相 关 的 系 统 物 理 地 址 的 使 用 分 配 布 局 ， 分 析 的 依 据

3、 是 %_WINCEROOT%PLATFORM DEVICEEMULATORSRClNCoemaddrtab_cfg.inc 文件中的g_oalAddressTable 数组： g_oalAddressTab1e DCD 0x80000000, 0x30000000, 64 ; 64 MB DRAM BANK 6 DCD 0x84000000, 0x10000000, 32 ; nGCS2: PCMCIA/PCCARD DCD 0x86000000, 0x18000000, 32 ; 32 MB SROM (SRAM/ROM) BANK 3 (CS8900 netcard) DCD 0x880

4、00000, 0x00000000, 96 ; 96mb NOR flash DCD 0x90800000, 0x48000000, 1 ；Memory control register DCD 0x90900000, 0x49000000, 1 ；USB Host register DCD 0X90A00000, 0x4A000000z1 ；Interrupt Control register DCD 0X90B00000, 0X4B000000, 1 ；DMA control register DCD 0x90000000, 0x4C000000z1 ；Clock original loc

5、ation of 32MB of NOR flash DCD 0x94000000, 0x34000000, 192 ; 192 MB bank 6offset into the RAM add r0 f rO. #PHYBASE ;add physical base mov rl frO ；(rl) copy destination ldr r2, = 0x0 ;(r2) flash started at physical address 0 ldr r3f=0x10000 ;counter (0x40000/4) 实例解析 第 - 龍 开 发 Windows om 的 Boo 产 oade

6、r ldr r0, =INTMSK ldr rl, =Oxffffffff ；disable all interrupts str rl f r0 工程实践 10 ldr r4, r2 # #4 str r4, rl f #4 subs r3, r3, bne %blO 设定好关键的 3个数据：复制操作的Nor Flash源起始地址、复制操作的RAM 冃的起始 地址 和以 4 字节为单位的待复制数据量，然后依次将BootLoader的镜像数据从Nor Flash中读 岀并且 存入 RAM 中。复制操作的源地址起始值是Nor Flash的起始物理地址0x00000000,存 放在寄存器 r2 屮

7、。复制的起始目的地址是RAM 起始物理地址加上0x21000, H数值存放在 寄存器 N 中，RAM 内存的最开始的132KB (0x21000B) 存储空间被 DcviccEmulator 用于其 他用途。 3寄存器充当复 制计数器，取值为0x10000,因为 DeviceEmulator的 BootLoader镜 像占用 256KB (0x40000Byte)存 储空间，而每次复制搬移4 个 Byte ( 因为 32位的 CPU其内 部寄存器是 32Bit)的数据。 复制操作完成以后，随后的汇编程序代码将程序计数器PC赋值为 BootLoader在 RAM 屮 的 起始指令所在的物理地址：

8、 ； Restart from the RAM position after copying ? mov pcz rO 这意味着 BootLoader又耍从头开始运行，但是这下一次在RAM 中的运行过程就不再执行复 制 B 身的操作，而是直接进入下一?步骤设置页表并且启用MMU 。 対嵌入式的 CPU启用 MMU 硬件单沅就意味着対嵌入式系统使用虚拟内存地址而不再是先前 的系统物理地址。对包括嵌入式系统在内的计算机系统使用虚拟内存有许多好处，木书会在在第 二篇详细介绍。客观地说，对Windows CE 的 BootLoader这么一个规模不大的嵌入式软件采用虚 拟内存并不能充分地体现虚拟内存的

9、好处。但是微软对Windows CE的 BootLoader所建议实现的 功能与特性之一就是BootLoader 的硬件初始化代码应该尽最大限度地和 OAL 的初始化代码保持 共享，而 OAL 作为 Windows CE 操作系统运行的开始是需要启用熄拟内存并且为MMU 的正确工 作设置所需的页表的。 除此 Z 外，在 BootLoader中启川虚拟内存还冇一个更为重要的理由。指导Windows CE 的编 译系统产牛可执行二进制文件的.bib I 程文件中使用的内存地址都是虚拟内存地址，而这些虚拟地 址是编译系统对二进制代码文件进行地址重定位的依据。以卜?是从DeviceEmulator B

10、SP 的 BootLoader 的 丁 程 文 件D: WINCE600PLATFORMDEVICEEMULATORSRCBOOT- LOADEREBOOTboot.bib 中摘取的部分内容： MEMORY Name Start Size Type PTS 80000000 00020000 RESERVED ARGS 80020000 00000800 RESERVED SLEEPSTATE 80020800 00000800 RESERVED EBOOT 80021000 00040000 RAMIMAGE STACK 80061000 00004000 RESERVED RAM 8006

11、5000 00006000 RAM 命名为 EBOOT 的起始地址 0x80021000的 RAM 区域用来存放 DeviceEmulator 的 BootLoader 镜像，这个镜像的数据最人小正好是256KB (0x40000B)o 0x80021000却是一个虚拟内存地址，虽 然不难根据 g_oalAddressTable数组得知它对应的物理内存地址是0x30021000,但是 Windows CE 的 编译系统会依据上表中EBOOT 一行的数据内容而将整个 BootLoader 的源代码中所有的变量名竽和函数名都映射为0x80021000? 0x80060FFF 之间的 虚拟 内存地址

12、数值。只有在BootLoader ?启用虚拟内存，它的执行代码才可能依靠MMU 将 这些虚拟 地址转换成物理内存地址，否则CPU会把 0x80021000? 0x80060FFF范围的地址当作系统物理地 址使用，而这是不被S3C2410的内存控制器硕件接受的。 计算机系统的 MMU 碾件单元的功能是将CPU发出的虚拟内存地址转换成可访问实际物理存 储的系统物理地址， MMU 实现地址转换的依据是一个地址转换表，这个地址转换表就是前文提 到的页表。页表的存放位迸在RAM 内存屮，MMU 只需知道它的存放起始位置。 供 DcviccEmulator 的 BootLoader 使用的页表存放位置就是

13、前文摘录的boot.bib 工程文件的PTS 一行所指示的从 0x80000000开始的 128KB (0x20000B)的 RAM 内存区域。构造贝表并且启川 MMU 可以看作是对 MMU 硬件单元的初始化，是前面提到的硬件初始化工作的继续。 相对于 Windows CE 操作系统而言， BootLoader的虚拟内存设计并不复杂，它不涉及较为复 杂的二级页表，只使用以1MB 为单位的一 - 级页表。一级页表就是供MMU 使用的地址转换表中 的每一个表项对应着1MB 的虚拟内存地址空间和相同大小的物理存储空间。Windows CE 也称这 1MB 的地址空间为“段” ( Section),但

14、这只是借用了一个概念而已，因为以ARM 为代表的嵌入式 CPU人多采用的是页式的存储管理技术，内部并没有类似x86 架构 CPU中 的段寄存器。 BootLoader构造一级页表的依据就是g_oalAddressTable数组。 每个标准的 Windows CE 的 BSP 其中都会定义这样一个命名为g_oalAddressTable的数组，这个数组不仅BootLoader 会用到，而且 它实际上主要是供WindowsCE 的 OAL 模块使用的。在BSP的高级语言程序代码中，这个数组的 元素类型定义为OAL_ADDRESS_TABLE ,这是一个在头文 件%_WINCEROOT%PLATFO

15、RMCOMMONSRCINCoal_memory.h 屮定义的结构体： typedef struct UINT32 CA; / cached virtual address UINT32 PA; / physical address UINT32 size ； / size, in MB bytes OAL ADDRESS TABLE, *P0AL ADDRESS TABLE; CA 和 PA 成员分别是一个g_oalAddressTable数组元索所指向的内存段的虚拟内存起始地址 和物理存储起始地址 , size成员是一个数组元素所包含的内存段的以MB 为单位的容量大小。 细心的读者也许已经

16、注意到了，DeviceEmulator的 g_oalAddressTable数组其笫一列的所有虚 拟内存地址、即所有的数组元素的OAL_ADDRESS_TABLE 结构体数据的 CA 成员取值 都限制在 0x80000000? 0x9FFFFFFF的共 512MB 地址范 | 韦 I 内。这不是偶然的， 而是任何一个 Windows CE BSP开发者定义它的g_oalAddressTable数纽时必须遵守的规则， 在后文 OAL 篇里读者会详细 地了解到，这一块虚拟内存地址被称作WindowsCE 的 cachablc 静态映射虚拟内存。什么是 cachable 、什么是静态映射以及二级页表

17、的原理都在后面讲述OAL 开发的一篇 里会有详尽的解释， 现在读者需耍知道的是，任何一个基于Windows CE 的嵌入式系统，它的所有物理存储都必须映 射到这块虚拟内存区域，这也就是为什么Windows CE系统的物理 存储总容量不得超过512MB 的 缘由。注意这里的物理存储不是仅指物理RAM 内存，也包括其他的 CPU 可直接寻址访问的物理 存储单元，比如Flash存储器及 CPU芯片内置外设的SFR 寄存器等。 MMU 硬件单元使用 - 级页表将虚拟内存地址转换成物理存储地址的原理是这样的。一个32 位嵌入式系统的任何地址值都是32位的，其中的低 20位是段内偏移，高12位是段索引。

18、从内存 实例解析 第 - 龍 开 发 Windows om 的 Boo 产 oader 工程实践 中的页表起始存放物理地址( 记做 TableStartP) 开始，侮 4个字节存放一个页表项，- 个页表项的起 始存放位置的物理地址记做EntryP,其中的 4字节数据衣示为 *(EntryP),则 MMU 将任一虚拟内存地 址 VA 转换为对应的物理地址PA 的计算方法可用下面的等式表达： PA = *( ( VA/OxlOOOOO )*4+ TableStartP ) OALVAtoPA 函数的功能是将0x80000000? 0x9FFFFFFF范围的虚拟内存地址转换成对应的 系统物理地址，实

19、现地址转换的依据是g_oalAddressTable数组。其屮的实际参数、记录跳转操作 目的位置的虚拟内存地址dwLaunchAddr 变量的取值來源于Downloadlmage函数解析操作系统镜 像文件吋所获知的操作系统起始执行指令的地址。另有一个执行与OALVAtoPA 相 反功能的函数 是OALPAtoVA,对ARM架构的CPU來说它们都在%_WINCEROOT% PLATFORMCOMMONSRCARMCOMMONBOOTBLMEMORYmemory.c 源文件屮实现。 OEMLaunch 函数在执行指令跳转之前，可能还要做的一件重要的工作是保存下载所得的操 作系统镜像以及用八配置数据

20、到Flasho Downloadimage函数下载得到的操作系统镜像数据通常暂 存在 RAM 内存中，而 BootloaderMain 函数本身的代码没有做保存镜像到非町易失存储器的工作， 所以如果用户开发的BootLoadcr冇这样的需求，则应该在OEMLaunch 函数调 用 Launch函数执行 跳 转 之 前 做 这 件 事 。 此 外 ， DeviceEmulator 的 OEMLaunch 函 数 还 要 调 用Eboot 库 函 数 EbootWaitForHostConnect从位于开发 计算机上的Platform Builder处获取 EDBG_OS_CONFIG_DATA

21、结构体数据，有关这个结构体的内容请参阅询文的对Eboot支持 库的 介绍。 3.4调试功能OEM函数 为 BootloaderMain 函数提供服务的第二人类OEM 函数是实现调试输入输出功能的函数。理 论上，儿乎所有的嵌入式外设端口都可以被BootLoader用作调试端口，但是硬件上最容易获得、 软件上最容易实现的是使用串口作为BootLoader 及 Windows CE 操作系统的调试端口。在 DeviceEmulator 的虚拟硬件及BSP软件设计中，选择S3C2410芯片内置的 3 个 UART 端口 屮的 UART1 作为调试功能串口。为BootloaderMain 函数提供调试功

22、能的OEM 函数主要是以 下 4 个，见表 3? 3。 表 3-3 为 BootLoader Main 函数提供调试功能的OEM 函数 函数名功能定义 OEMInitDcbugScrial本函数负责初始化调试串口。它主要被BootLoadcr主控制流的OEMDebuglnit函数调用 , BootloaderMain函数必须在调用了OEMDebuglnit函数并且执行成功以后才可以使用其他的调 试输入输出功能函数 OEMReadDebugByte 本函数从调试端口中读取- 个字节的输入 ( 相对于目标嵌入式设备而言) 数据 OEMWriteDebugByte本函数向调试端口中写入一个字节的输岀

23、数据 OEM Wri teDebugStri ng 本函数通过诡试端口向川户输出一个字符串，这是故频繁被使用的BootLoader调试功能函 数 Windows CE 的 BootLoader和 OAL 模块都耍使用调试端口实现调试功能的输入输出，所以微软建 议这两者共享使用实现调试输入输出的以上4 个 OEM 函数，这样做既可减轻开发者的工作量， 也有利于提高软件代码的可复用性和可维护性。 DeviceEmulator 的 OEMlnitDebugSerial 函数在 %_WINCEROOT%PLATFORMDEVICEE- MULATORSRCOALOALLIBdebug.c源文件中实现。

24、初始化调试串口的第一步是设置 S3C2410的 GPIO 控制寄存器 , 将芯片的 GPH4和 GPH5引脚选用作 TXD1 和 RXD1,即串口 UART1 的数据输出和输入引脚： CLRREG32( / if (status else Ch = OEM DEBUG READ NODATA; return (int)ch； VOID OEMWriteDebugByte(UINT8 ch) / Wait for transmit buffer to be empty while (INREG32( / Send character OUTREG32( 这是典型的以轮询 ( 査询) 方式操作外设

25、的代码。 S3C2410的 UTRSTAT1 寄存器 ( 系统 物理地 址为 0x50004010)指示出 UART1 端口的串口数据收发状态，当UART1 的接收 FIFO 屮接收到有效 数据时，UTRSTATI 寄存器的第 0 比特位査 1。 OEMReadDebugByte函数根据 这一原理判断 UART1 实例解析 第 - 龍 开 发 Windows om 的 Boo 产 oader (3 ? 10); (2 ? 10); BSP_UART1_UFCON); BSP_UART1_UMCON); BSP_UART1_ULCON); BSP_UART1_UCON); BSP_UART1_U

26、BRDIV); 工程实践 端口是否接收到了数据，如有数据则读収UART1 的接收缓冲区寄存器URXHI ( 系统物理地址为 0X50004024)。 当 UART1 的发送 FIFO 为空、 即待发送的串口数据已被全部发送出去时， UTRSTAT1 寄存器的第 1 比特位被置 1,表示 UART1 端口町以继续发送数据， OEMWriteDebugByte 函数正是 根据这一原理通过不断查询UTRSTAT1 寄存器来达到正确地写串口的目的。 OEMWriteDebugByte 函数的功能毕竟太局限了，实际上用八经常需要向调试端口输岀一个字 符串而不是单个字符。OEMWriteDebugStri

27、ng 函数正是为了满足这一需求而设计的，它的实现很 简单，只是循环地调用OEMWriteDebugByte 函数将一个字符串中的多个字符逐一地发送出去 : VOID OEMWriteDebugString(UINT16 *string) while (*string != L 101) OEMWriteDebugByte(UINT8)*string+) ； 3.5下载功能OEM函数 BootLoader的卜 ?载功能OEM 函数主要为 BootLoader卜?载操作系统镜像服务。 属于这一 类 别的 OEM 函数有 3 个，它们的函数名和函数的功能定义见表3-40o 表 3-4 BootLoa

28、der 的下载功能 DEM 函数 函数名功能定义 OEMReadData该函数负责从下载端口读取操作系统镜像数据 OEMMapMcmA ddr 当BootLoader卜载的操作系统镜像自身记录的目的存储位置是Flash存储器时，该函数负责将它 以重定向的方式暂存到一块RAM内存缓冲区中，待镜像数据下载全部完成以后再-?起写入Flash 存储器中 OEMShowProgre ss 该函数在下载操作系统镜像的过程中向用户显示下载的进度 OEMReadData是最重要的下载功能OEM 函数，它只被 Downloadlmage函数调用， Downloadlmage函数全靠它从卜?载端口读取操作系统镜像

29、的数据。理论上OEMReadData函数 应 该能够适应任何类型的下载端口，但是在实用上只需考虑通过以A 网端口下载镜像的情况。在 DeviceEmulator 的 Eboot类型的 BootLoader P, OEMReadData函数要从以太网端口读取操作系统镜 像数据，它主要依靠调川Eboot库函数 EbootEtherReadData來实现这一功能。虽然 EbootEtherReadData函数是一个由微软提供实现代码的库函数，但是它的源代码需要调用另一个 OEM 函数 OEMEthGetFrame才能实现门身的功能。 OEMEthGetFrame函数的归类是以太网控制器 操作函数，它

30、所实现的功能是从以太网端口读取一个完整的以太网数据帧。OEMEthGetFrame函 数和 OEMReadData两数尽管在 DeviceEmulator111都是实现读取以太网数据功能的 OEM 函数，但 是前者的普遍适用性不及后者，OEMEthGetFrame函数仅适用于读取以太网数据帧， Iflj OEMReadData函数应该能适应所有类型的负责从开发计算机下载操作系统镜像的外设端口。 OEMMapMemAddr 函数用于当下载得到的操作系统镜像自身所记录的目的地址是Flash 存储 设备时，该 OEM 函数要负责将镜像的数据以重定位的方式暂存到一块RAM 内存缓冲区 中去。由 于向

31、Flash写数据的速度大大落后于从网络读取的数据量，而H 写 Flash Z前通常还 要执行擦除的操作，这更会影响写Flash的速度，所以 BootLoader在下载操作系统镜像的同时将 它写入 Flash的做法是不可取的。合理的做法应该是在系统的RAM 内存中专门开辟一块暂存下载 镜像数据的缓冲区，如果镜像的冃的地址是指向Flash存储的，则待完整的镜像下载完成以后再 一起写入 Flasho当然如果镜像的冃的存储地址在RAM 内存中，则不需暂存，直接写入对应的区 段内存地址即可。 OEMMapMemAddr 函数的具体实现必须要兼顾这两种可能的情况，以卜是 DeviceEmulator的 O

32、EMMapMemAddr 函数的实现源代码： LPBYTE OEMMapMemAddr(DWORD dwImageStart # DWORD dwAddr) UINT32 MappedAddr = dwAddr； OALMSG(OAL_FUNC / (TEXT( M +OEMMapMemAddr (Address=Ox%x)? rn M ), dwAddr)； / If it f s a flash address,translate it by H rebasing Hthe address into the file cache area?if (OEMIsFlashAddr(dwAddr

33、) return FALSE ； return TRUE ； 根据上面库函数源代码，结合DeviceEmulator的 BootLoader的具体实现，不难发现它的 OEMWriteFlash 函数不能适应多区段的操作系统镜像并且其中有超过一个区段需要写入Flash 的情 况。因为如果出现那种悄况的话，后面的写Flash操作会覆盖前面写入的数据。用户在为白己的 BootLoader实现 OEMWriteFlash 函数时应该要注意这个问题。 3.8时钟功能OEM函数 BootLoader的时钟功能 OEM 函数只有一个 OEMKitIGetSecs,它所实现的功能是记录从过去的 一个特定的时间

34、点到当前时刻经过的时间的秒数。BootLoader的源代码中所冇需要定时处理的操 作都需要依赖它，比如向用户显示的选项菜单如果在指定的时间内接收不到用户的选择输入则进 入默认选项处理，这个OEM 函数还要被 Eboot支持库函数调用以处理以A 网 协议的定时操作。此外，山于BootLoader以轮询的方式访问外设，对外设的定时轮询也要依靠这 个OEMKitlGetSecs 两数。DeviceEmulator 的OEMKitlGetSecs 函数在源文 件 %_WlNCEROOT%PLATFORMDEVlCEEMULATORSRCBOOTLOADEREBOOTether.c 中实 现如下： DW

35、ORD OEMKitlGetSecs(void) SYSTEMTIME sTime; OEMGetRealTime( WORD wDayOfWeek； WORD wDay; WORD wHour； WORD wMinute; WORD wSecond； WORD wMi11iseconds; SYSTEMTIME, *LPSYSTEMTIME; 通常 OEMKitlGetSecs 函数的调用者并不关心这个函数返冋的准确数值，而是先后两次调用 这个函数使用两个返回值的差值作为衡量一个时间段的时间秒数。 3.9 可选实现的OEM函数 以上各节讲述的都是Windows CE BootLoader的必

36、须实现的 OEM 函数，这些 OEM 函数 至少 在程序结构上是必须存在的，即使有少数像OEMShowProgress函数这样的无足轻重的OEM 函数， 开发者至少要为它定义一个空函数。但是可选实现的OEM 函数在形式上就已经不是必须的， BootLoader的源代码使用函数指针调用这些函数， 调用 Z前要先检查这些函数的指针是否为 NULL, 如果是空的畅数指针则不能调用。举例來看，以下是可选实现的OEM 函数 OEMVerifyMemory被 Downloadlmage两数调川的源代码： / give the OEM a chance to verify memory if (g_pOEM

37、VerifyMemory HALT BLERR_OEMVERIFY); return (FALSE) ； BootLoader的可选实现的OEM 函数有 4 个，它们的函数名和各自应该实现的功能描述见表 3-6。 实例解析 第 - 龍 开 发 Windows om 的 Boo 产 oader 工程实践 表 3-6 BootLoader 的可选实现的 OEM 函数 函数名功能描述 OEMCheckSignatur c 该函数负责检验.bin文件的数字签名 OEMMultiBINNotif y 当BootLoader要卜?载多区段的操作系统镜像时会调用此萌数向用户发出通知 OEMReportErr

38、or 该函数负责向用户报告BootUader的执行错课情况 OEM Veri fyMemory该函数负责检测某一段虚拟内存地址区域是否映射到用户实际可使用的物理存储，包扌舌 Flash 和RAM 由于这些可选实现的OEM 函数都是通过函数指针实现引用和调用的，所以Windows CE 的 BootLoader 并不强制要求使用表3-6 中的函数名，只耍用实现了相应功能的函数的函数名，即函 数的起始执行地址为4个在 BLCOMMON 库中预定义的函数指针赋值即可。这4个函数 指针在源 文件%_W1NCEROOT%PUBLICCOMMON OAKDRIVERSETHDBGBLCOMMON blco

39、mmon.c 中定义如下： 以上 4 个函数指针的类型定义在头文件%_WINCEROOT%PUBLICCOMMONOAKINC blcommon.h中，它们就是 4个可选实现的 OEM 函数的函数接口定义： / optional OEM functions typedef BOOL (* PFN_OEMVERIFYMEMORY) (DWORD dwStartAddr, DWORD dwLength); typedef BOOL (* PFN_OEMREPORTERROR) (DWORD dwReason, DWORD dwReserved)； typedef BOOL (* PFN_OEMCH

40、ECKSIGNATURE) (DWORD dwImageStart z DWORD dwROMOffset, DWORD dwLaunchAddrz BOOL bDownloaded) ； / Function pointer to OEM code for mutliple file and ? nbO file notifications? typedef void (* PFN_OEMMULTIBINNOTIFY) (PMultiBINInfo plnfo); 由于是可选实现，所以BootLoader的开发者完全可以根据自身需要來决定实现这4个 OEM 函数的全部、部分或者完全不实现。在

41、DeviceEmulator的 BSP屮，实现了 OEMVerify- Memory 和 OEMMultiBINNotify 两个。对函数指针g_pOEM Verify Memory 和 g_pOEMMulti- BINNotify赋值 的动作发生在 OEMDcbuglnit 函数中、 OEMInitDebugScrial 函数被执行 Z 前。 OEMVerifyMemory 函 数 的 实 现 源 代 码 在%_WINCEROOT%PLATFORMDEVICEEMULATORSRCBOOTLOADER EBOOTmain.c 文件 中实现，主要的功能代码如下： DWORD dwFlashEn

42、d = AMD_FLASH_START_CA + AMD_FLASH_SIZE; ? ? ? if( (Addrl = AMD_FLASH_START_CA) pBSPArgskitl ? devLoc ? IfcType = Internal； pBSPArgs-kitl ? devLoc.BusNumber = 0 ； pBSPArgskitl ? devLoc.LogicalLoc = BSP BASE REG PA CS8900A IOBASE; / 0x19000300 以上的赋值操作表明：DeviceEmulator 的虚拟硬件平台使用S3C2410 CPU 芯片直接连接 （Int

43、ernal）的 CS8900以太网端口作为外KITL 调试功能提供传输能力的端口外设；CS8900以 太 网 控 制 器 使 用 的I/O端 口 起 始 地 址 为0x19000300；kitl的flags 成 员 被 赋 值 为 OAL_KITL_FLAGS_ENABLED | OAL_KITL_FLAGS_VMINI,表示要求Windows CE 操作系 统支 持 KITL 调试并且启用VMINI 功能，这实际上是BootLoader通过用户选项菜单支持用户对 OAL 模块的 KITL 初始化方式作出选择。 DeviceEmulator对 KITL 设备的软件配置，包括它的名字字符 串和

44、IP 地址信息等，在 OEMPreDownload 函数中执行完成。 BSP_ARGS 结 构 体 的ScreenSignatures Screen Width ScreenHeight ScreenBitsPerPixel 和 ScreenOrientation 5个成员用于控制DeviceEmulator的 LCD 显示设备的显示 - 作模式，它 们各白 的含义分别是 Screen参数的签名、以像素点为单位显示的宽度和高度、每象素点所需的显示数据 的比特位数，以及显示的方向（横向或纵向）。 dwExtensionRAMFMDSize 和 pvExtensionRAMFMDBaseAddr

45、两个成员记录目标系统的扩展 内存的空问大小和起始地址。 EmulatorFlags成员用于记录本次系统启动的方式，分 Hard Reset 系统 上电启动和 Soft Reset 从省电模式下恢复。数组成员Pad用于 32位字对齐。 BSP_ARGS 结构体另 外还有两个成员fUpdateMode和 fStorageMounted, 但是在 DeviceEmulator 的 BSP中保留未使用。 3.11保存用户选项配置参数的数据结构 在 DeviceEmulator 的 Eboot 型 BootLoader 中 ， 有 一 个 起 着十 分 重 要 作 用 的 全局 变 量 g_BootCo

46、nfig,具体地说，这个全局变量所起的作用是为BootLoader保存用户选项配置参数。用户 选项配置参数，主要是用户可以在BootLoader向使用者显示的选项菜单中设置或者改变的选项参 数，比如 BootLoader应该使川静态 IP 地址还是通过 DHCP 协议动态获取 IP 地址、 用户选项菜单 进入默认选项的超时时间值等。与上一节的 BootLoader的启动参数保存在RAM 内存中不同， 用八 选项配置参数保存在非可易失的存储设备中，所以即使不是可在用户选项 pBSPArgs-header ? signature pBSPArgs-header ? oalVersion pBSPA

47、rgs-header ? bspVersion / *SGRA , 菜单中设置或者改变的选项参数，如呆需要进行掉电保存的BootLoader fli!置数据，也可以借 助这 个全局变量保存在Flash存储器或者其他类型的非可易失的存储设备小。 DeviceEmulator 的 g_BootConfig 全局变量在源文件 %_W1NCEROOT%PLATFORM DEVICEEMULATORSRC BOOTLOADEREBOOTmain.c 中定义如下： g_BootConfig 全局变量的类型BOOT_CFG 是一个在头文 OT%PLATFORM DEVICEEMULATORSRC INCar

48、gs.h 中定义的结构体。从BOOT_CFG 结构体的定义位置可以看 出，它和前一节的用丁 ?在BootLoader A/操作系统 Z 间共享信息的 BSP.ARGS结构体相似 , 都是 DeviceEmulator的独有设计，微软对于Windows CE BootLoader的需要掉电保存的配置参数没有 也不可能作出标准的定义。 / Bootloader configuration parameters (stored in NOR flash)? / #define CONFIG_SIGNATURE 0x12345678 #define CONFIG_AUTOBOOT_DEFAULT_CO

49、UNT 5 #define CONFIG_FLAGS_AUTOBOOT 1 Signature != CONFIG_SIGNATURE) “ 第 - 龍 开 发 Windows om 的 Boo 产 oader BOOT_CFG g_BootConfig ； 工程实践实例解析 / 对无效的BootLoader fit!置参数作出相应的处理 以上 CONFIG_SIGNATURE 是与 BOOT_CFG 结构体在同一头文件中定义的宏，它的实际数 值为 0x12345678,显然这也不是 Windows CE 的标准定义。在DeviceEmulator中, BOOT_CFG 结构 体数据存放在偏移地址为OxOOOFOOOO的 Nor Flash 存储设备中，系统为它保超了 64KB 的存 储空间。EBOOT_CONHG_OFFSET 是在头文件%_WINCEROOT%PLATFORM DEVICEEMULATORSRCINCimage_cfg.h 中定义的宏： #define