Boot Args与Driver Globals—WinCE EBOOT

　　EBoot是WinCE一种默认的Bootloader，用来引导WinCE，升级WinCE，及各种调试工具。在EBoot中打开一些全局变量从而控制WinCE中的功能，比如USB的模式等（就是与WinCE约定了一个内存区域存放这种标志），还有在

EBOOT中包含的一个重要的缓冲区叫Driver Globals，它用于在设备驱动和WinCE OS之间共享数据。而在EBOOT中会用到的启动参数结构被称为Boot Args，是指用于EBOOT和WinCE OS之间共享一些参数信息。一般来说Boot Args会

在EBOOT运行的时候被赋值或者更新，常用的就是网络设备的相关信息设置，比如IP地址，MAC地址，中断等信息。

　　Driver Globals包含了Boot Args，也就是说Driver Globals是一块内存缓冲区，其中里面也包含了Boot Args的内存缓冲区。这里要说明的是Driver Globals是一个可选用的功能，无非就是一块内存，在EBOOT和WinCE OS之

间进行数据共享。如果你想用，你就用，不想用，也可以不用。我们在使用Driver Globals的时候，一般会在eboot.bib和config.bib文件定义一块预留的内存区域，在这两个文件中定义的这块内存区域的起始地址和大小必须一致，相

信这个大家都能理解，至于类型肯定是RESERVED。这样一来，在EBOOT和WinCE运行的时候，这块共享内存就被预留出来了。当然，我们还需要在BSP中通过宏定义来定义这块内存的起始地址和大小，这样就可以在BSP中访问这块内存了。

   首先在eboot.bib和config.bib都要有下面的定义：

　　MEMORY

　　;   Name     Start     Size      Type

　　;   -------  --------  --------  ----

　　ARGS     80020800  00000800  RESERVED

　　上面的描述表示Driver Globals的共享内存的起始地址是0x80020800，大小是0x800。

　　然后还要在BSP中对其起始地址和大小进行宏定义，如下：

　　#define IMAGE_SHARE_ARGS_UA_START       0xA0020000

　　#define IMAGE_SHARE_ARGS_CA_START       0x80020800

　　#define IMAGE_SHARE_ARGS_SIZE           0x00000800

　　这样，EBOOT就可以通过上面的宏定义的地址来访问共享内存了。这块共享区域是用Driver Globals结构来描述的，具体定义如下：

　　typedef struct _DRIVER_GLOBALS

　　{

　　//

　　// 之后，可以定义用于驱动程序和WinCE OS之间的共享信息

　　//

　　BOOT_ARGS        bootargs;

　　} DRIVER_GLOBALS, *PDRIVER_GLOBALS;

　　可以看出里面包含了用于描述Boot Args的BOOT_ARGS结构，当然用户也可以在结构中添加用于驱动和WinCE OS之间共享的数据类型。

　　下面介绍一下Boot Args的BOOT_ARGS结构，定义如下：

　　#define BOOTARG_SIG  0x544F4F42 // "BOOT"

　　typedef struct BOOT_ARGS

　　{

　　DWORD   dwSig;

　　DWORD   dwLen;                // BOOT_ARGS的结构长度

　　UCHAR   ucLoaderFlags;        // Boot loader设定的标志

　　UCHAR   ucEshellFlags;        // EShell标志

　　DWORD   dwEdbgDebugZone;      // 调试域Debug Zone的定义

　　EDBG_ADDR EshellHostAddr;     // Host端的IP地址和EShell的UDP端口号

　　EDBG_ADDR DbgHostAddr;        // IP地址和接收Debug信息的UDP端口号

　　EDBG_ADDR CeshHostAddr;       // IP地址和以太网cesh的UDP端口号

　　EDBG_ADDR KdbgHostAddr;       // IP地址和Kenel Debugger的UDP端口号

　　ETH_HARDWARE_SETTINGS   Edbg; // 调试以太网卡的硬件设置信息

　　} BOOT_ARGS, *PBOOT_ARGS;

　　其中Boot loader的设置标志定义如下：

　　#define    LDRFL_USE_EDBG     0x0001  // 设置尝试使用调试以太网

　　//如果设置了LDRFL_USE_EDBG，下面两个标志才会被看到

　　#define    LDRFL_ADDR_VALID  0x0002  // 当EdbgAddr有效时设置

　　#define    LDRFL_JUMPIMG      0x0004  // 不使用与Eshell通信

　　在上面的BOOT_ARGS结构中的ETH_HARDWARE_SETTINGS结构定义如下：

　　typedef struct _ETH_HARDWARE_SETTINGS

　　{

　　EDBG_ADAPTER    Adapter;             // 与Platform Builder通信的网卡

　　UCHAR           ucEdbgAdapterType;   // 调试以太网卡的类型

　　UCHAR           ucEdbgIRQ;           // 调试以太网卡的IRQ

　　DWORD           dwEdbgBaseAddr;      // 调试以太网卡的基地址

　　DWORD           dwEdbgDebugZone;     // 调试以太网卡的调试域

　　char szPlatformString[EDBG_MAX_DEV_NAMELEN];   //一个的目标板设备名

　　UCHAR           ucCpuId;             // 处理器类型

　　} ETH_HARDWARE_SETTINGS, *PETH_HARDWARE_SETTINGS;

　　我的是2440 5.0采用的是三星08年的BSP,系统可以启动但是 pBSPArgs->nfsblk = -1 ，跟踪了一下了是：pBSPArgs = （（BSP_ARGS *） IMAGE_SHARE_ARGS_UA_START）；这个参数可以该其他的吗？I

　　你是指pBSPArgs么？改是可以改，它实际上是一个共享内存的起始地址。至于为什么pBSPArgs->nfsblk = -1，我想根本原因是该变量对应的内存没有被初始化，我想你首先要确定该变量是在哪里被初始化的。

　　大侠小弟有个关于EP9315WINCE里面PHYSICAL_EQUAL_VIRTUAL的问题 PHYSICAL_EQUAL_VIRTUAL在oempreinit.c置了1，memorymap.h里用它来使sdram/flash/sram等虚拟地址和对应的物理地址等同起来，就拿sdram来说，片选物理地址0X00000000,

如果虚拟地址也等于0X00000000，是否与用户进程冲突？为什么要这样做？而不是把虚拟地址映射从0X80000000开始？还有就是OEMAddressTable和config.bib里的MEMORY设置虚拟地址是否有关？

　　在oempreinit.c中确实将PHYSICAL_EQUAL_VIRTUAL设置为1，但是它对OEMAddressTable没有影响。OEMAddressTable会受memorymap.h中#define的影响，而memorymap.h应该包含了memorymap-9315.h。

　　我目前手上没有EP93系列的BSP，不过我记得应该是这样的。也就是说oempreinit.c中的定义是没有意义的，不会对OEMAddressTable产生影响。这属于历史遗留问题。

　　关于OEMAddressTable和config.bib是否有关。我想应该说OEMAddressTable是一个物理地址/虚拟地址的映射表，我专门有一篇blog介绍OEMAddressTable，你可以看看。而config.bib实际上是确定了在WinCE系统中RAM的分配。

　　明白大侠，还有另外一个问题，现在在板上加了一个512k的可掉电sram，选通用cs2（主要是参考了原来BSP上OEMAddressTable也有sram的配置，不用再添加），想让它作为硬盘用，并在系统中以盘符形式显示，并可以实现读写存储，

我拷了wince自带的ramdisk驱动过来进行了修改，作为驱动来添加，并在注册表添加了sram的起始地址来定位（\\builtin\\ramdisk\\address），现在烧进去后可以在存储属性里看到ramdisk的信息，问题是无法装入分区，也就无法看到盘符，请问这种思路是否正确，

是否由于地址定位错误引起的呢？请大侠抽空帮小弟看看。

　　还有我的config.bib也reserved了一个ramdisk，是从0x8c000000开始的1m空间这种问题，我建议先看看WinCE的ramdisk的代码，理解了然后进行调试。

　　Windows CE作业系统是Windows家族中的成员，专门设计给掌上型电脑（HPCs）所使用的电脑环境。这样的作业系统可使完整的可携式技术与现有的Windows桌面技术整合工作。 Windows CE 被设计成针对小型设备（它是典型的拥有有限内存的无磁盘系统）的通用操作系统，

　　Windows CE 可以通过设计一层位于内核和硬件之间代码来用设定硬件平台，这即是众所周知的硬件抽象层（HAL）（在以前解释时，这被称为 OEMC （原始设备制造）适应层，即 OAL； 内核压缩层，即 KAL。 以免与微软的 Windows NT 操作系统 HAL 混淆） 。

　　WinCE 是微软推出的面向移动和手持设备的嵌入式实时操作系统，为了适应嵌入式系

　　统多变、灵活的硬件构成，WinCE 也采用可定制的组件模型。

　　总的说来，WinCE 的开发分为以下几个层次

　　1.驱动程序编写

　　在操作系统底层，响应硬件事件及读写硬件的工作由OEM 适配层（OAL）完成，设备

　　驱动程序属于OAL。

　　2.内核定制及裁减

　　定制系统组件的工作在Platform Builder 中完成，配套光盘中提供了针对PB 5.0 的BSP。

　　需要注意的是，我们并不提供正版的Platform Builder，如果需要，请到微软网站上试用

　　版。

　　3.应用程序开发

　　系统建立起来以后，经过编译生成名为NK.Bin 的操作系统镜像，将此镜像到ARM9

　　开发板上，就可以在平台上运行Windows CE。此时也可以在此系统上运行相关的应用程序。

　　开发应用程序有几种工具可供选择，其中包括EVC（with SP4 ）和VS2005 。配合由PB 导

　　出的SDK，我们就可以编译出针对特定平台的应用程序。

　　Platform Builder：定制WinCE 操作系统的工具，借助此工具的帮助，我们可以定制出

　　满足自己需要的WinCE 操作系统。一般来讲，Platform Builder 的版本号和由它定制出的

　　WinCE 操作系统的版本号是一致的。例如，Platform Builder 5.0 定制出Windows CE.NET 5.0；

　　Platform Builder 5.0 定制出Windows CE 5.0；Platform Builder 6.0 定制出Windows Embedded

　　CE 6.0。

　　WinCE 5.0：Windows CE.NET 5.0 的简写，由PB 编译出来。是针对嵌入式平台的实时

　　操作系统，提供了与桌面Windows 类似的图形界面以及几乎相同的应用程序接口。

　　BSP 针对特定的硬件平台对WinCE 操作系统提供支持。一个BSP 只能针对特定版本的Platform Builder。

　　SDK：Software Development Kit，软件开发包。是编写基于WinCE 的应用程序的必备

　　工具，可以在Platform Builder 中导出。SDK 针对特定的操作系统对WinCE 应用程序提供支

　　持。一般来讲，在PB 中定制的操作系统针对特定的BSP，针对此特定操作系统的应用程序

　　需要特定的 SDK 支持。需要指出，基于。NET Framework 的应用程序不需要SDK 支持。

　　PB，WinCE，BSP 和 SDK 是不同层面的不同含义的名词。