WINCE的内存（包括SDRAM及FLASH）的配置包含两个方面：源代码(包括C和汇编)中的定义,及系统配置文件CONFIG.BIB中的定义。源代码中需要定义内存的物理及虚拟地址，大小，并初始化名为OEMAddressTable的结构数组，以告知系统物理地址与虚拟地址的对应关系，系统根据其设置生成MMU页表。而CONFIG.BIB中一般会将内存定义成不同的段，各段用作不同的用途。
CONFIG.BIB文件
CONFIG.BIB文件分两个部分，我们且称之为段，MEMORY段和CONFIG段。MEMORY段定义内存的分片方法，CONFIG段定义系统其它的一些属性。以下是一个CONFIG.BIB文件MEMORY段的例子：
MEMORY
；
名称
起始地址
大小 属性
RESERVED 80000000 00008000 RESERVED
DRV_GLB 80008000 00001000 RESERVED
CS8900 80010000 00030000 RESERVED
EDBG 80040000 00080000 RESERVED
NK 800C0000 00740000 RAMIMAGE
RAM 81000000 00800000 RAM
名称原则上可以取任意字符串，ROMIMAGE通过一个内存片的属性来判断它的用途。RESERVE属性表明该片内存是BSP自己使用的，系统不必关心其用途；RAMIMAGE说明它是一片存放OS
IMAGE的内存；而RAM则表示些片内存为RAM，系统可以在其中分配空间，运行程序。
但存放 ROM的这片内存的名称，即NK一般不要改动。因为BIB文件中定义将一个文件加入到哪个ROM片（WINCE支持将ROM IMAGE存放在不连续的几个内存片中）中时会用到这个名称，如下现这行BIB文件项就定义将touch.dll放在名称为NK这片ROM中，
touch.dll $(_FLATRELEASEDIR)/touch.dll NK SH
因而，如果将NK改为其它名称，则系统中所有的BIB文件中的这个NK串都需要改动。
注意：保证各片内存不要重叠；而且中间不要留空洞，以节约内存；两种设备如果不能同时被加载，就应该只为其保留一片从而节约内存，例如，本例中的 CS8950是为网卡驱动程序保留的，EDBG是为网卡作调试（KITL）用时保留的，而系统设计成这两个程序不会同时加载（CS8950在启动时判断如果EDBG在运行就会自动退出），这样为这两个驱动程序各保留一片内存实在浪费而且也没有必要。
RAM片必须在物理上是连续的，如果系统的物理内存被分成了几片，则在RAM片只能声明一片，其它的内存在启动阶段由OEMGetExtensionDRAM报告给系统，如果有多于一个的内存片，应该用
OEMEnumExtensionDRAM报告。NK片则没有此限制，只是NK跨越两个以上物理内存片时，系统启动时会显示这个OS包跨越了多个物理内存片，认为是个错误，但并不影响系统的执行与稳定性，因为系统启动之时便会打开MMU而使用虚拟地址，从而看到连续的内存空间。当然，如果内核自己都被放在了两个内存片上，那系统应该就无法启动了。而其它保留起来的内存片是一般是给驱动程序DMA用，应该保证它们在物理上的连续性，因为DMA是直接用物理地址的。
CONFIG段中以下几个需要格外注意：
ROMSTART，它定义ROM的起始位置，应该和NK片的起始位置相同。
ROMSIZE，定义ROM的大小，应该和NK片的大小相同。
如果不需要NK。BIN文件，则可以不设这两个值。
ROMWIDTH，它只是定义ROMIMAG生成ROM包时如何组织文件，而非其字面含义：ROM的宽度，所以一般都应该为32
COMPRESSION，一般定义为ON，以打开压缩功能，从而减小BIN文件的尺寸。
AUTOSIZE，一般应该设为ON，以使系统将定义给ROM但没有用掉的内存当做RAM使用，而提高RAM的使用率。注意，如果ROM是FLASH，则不能设为ON，因为FLASH不能当作RAM使用。
ROMOFFSET，它定义OS起始位置（即ROMSTART）的物理地址和虚拟地址的差值，有些BSP中并没有使用这个定义。
OEMAddressTable及其它
OEMAddressTable用来初始化系统中各种设备的虚拟地址与物理地址的对映关系。在我使用的BSP中，它是这样定义并初始化的：
typedef struct
{
ULONG ulVirtualAddress;
ULONG ulPhysicalAddress;
ULONG ulSizeInMegs;
} AddressTableStruct;
#define MEG(A) (((A - 1)>>20) + 1)
const AddressTableStruct OEMAddressTable[] =
{
{ SDRAM_VIRTUAL_MEMORY, //虚拟地址
PHYSICAL_ADDR_SDRAM_MAIN, //物理地址
MEG(SDRAM_MAIN_BLOCK_SIZE) //这段空间的大小，以M计
},
………………………
{
0,
0,
0
}
}；
如例子所示，OEMAddressTable为一个结构数组，每项的第一个成员为虚拟地址，第二个成员为对应的物理地址，最后一个成员为该段空间的大小。这个数组的最后一项必须全部为0，以示整个数组的结束。内核启动时会读取这个数组的内容以初始化MMU页表，启用MMU，从尔使程序可以用虚拟地址来访问设备。当然，OEMAddressTable中所用到的每个物理地址及虚拟地址都需要在头文件中定义，每个BSP中定义这些值的文件不尽相同，所以，在此不能说明具体在哪个文件，读者朋友可以参考具体BSP的文档及代码。
不连续内存的处理
如果内存在物理上是连续的，则 OEMAddressTable中只需要一项就可以完成对内存的地址映射。但如果BSP运行在SDRAM物理上不连续的系统上时，
OEMAddressTable中需要更多的项来将SDRAM映射到连续的虚拟地址上，当然也可以将它们映射到不连续的虚拟地址上，但似乎没有理由那么做。而且，当其物理地址不连续时系统需要做更多的工作。例如，我有这样一个系统：32M
SDRAM，16M FLASH，SDRAM在物理上不连续，被分成了4个8M的内存块，我的SDRAM的使用情况如下图所示：
CONFIG。BIB文件的MEMORY段如下所示：
MEMORY
RESERVED 80000000 00008000 RESERVED
DRV_GLB 80008000 00001000 RESERVED
CS8900 80010000 00030000 RESERVED
EDBG 80040000 00080000 RESERVED
NK 800C0000 00940000 RAMIMAGE
RAM 81800000 00800000 RAM
在这32M的空间中，BSP保留了前0x80000字节，接下来是NK，它占用了0x940000字节，而且它跨越了两个内存片,这些和其它BSP的设置都没有多大差别,接下来看RAM片,它只占用了最后的8M空间,前面说过，在这种物理内存不连续的系统中，RAM片不能跨越两个物理内存块，所以它被设计成只占用该系统中的最后一个物理内存片，而其它两片则由OEMEnumExtensionDRAM在运行时刻报告给系统，该函数的内容如下:
pMemSections[0].dwFlags=0;
pMemSections[0].dwStart=(SDRAM_VIRTUAL_MEMORY + 0x1000000);
pMemSections[0].dwLen=0x800000;
pMemSections[1].dwFlags=0;
pMemSections[1].dwStart=(SDRAM_VIRTUAL_MEMORY + 0x0A00000);
pMemSections[1].dwLen=0x600000;
return 2;
这样,系统所有的内存都被激活,系统可用内存就变成了8+8+6=24M，可以将RAM定义为这三片中的任意一片，而在
OEMEnumExtensionDRAM中报告其它两片。但把RAM放在最后一片物理内存上有一个很大的好处，即如果NK变大，例如编译一个DEBUG
版的系统时，这时，只需要将OEMEnumExtensionDRAM中的内容注释掉，CONFIG.BIB文件不用做任何改动，系统就可运行，只是在
MAKEIMG时会有一个警告说系统包太大，可能无法运行，但实际不会影响系统的执行与稳定性，因为NK之后的那段内存并没有被使用，正好被涨大的系统占用，这在调试时极其方便。
而如果系统物理内存是连续的，那将变得简单的多，还以上面的设置为例，如果这32M的SDRAM是物理上连续的，内存的使用情况就可以表示如下图：
所有者系统可用内存都可以定义在RAM片中。
对硬件知识了解不多的朋友请注意：SDRAM是否在物理上连续，与我们的板上有几片SDRAM没有关系，应该向硬件工程师了解SDRAM的地址分布情况。
Understanding Memory Sections in config.bib, boot.bib, and OEMAddressTable in Windows CE 5.0 and 6.0
Windows CE uses .bib (binary image builder) files to track, among other things, the memory layout of bootloaders as well as OS images. If you’re writing a new BSP, you’ll definitely need a config.bib file for your OS, and you’ll likely need a boot.bib file for your bootloader.
Let’s take a few minutes to understand how .bib files relate to memory usage. It’s going to be muddy at the beginning, but I promise if you stick with me through the end you’ll be glad that you did. Well, maybe you won’t be glad but you’ll know more about .bib files. Let’s get to it!
OEMAddressTable
Before we look at the .bib files themselves, it’s important to understand the OEMAddressTable. This table defines the mappings between physical and virtual addresses. For MIPS and SH processors, this table is hard coded into the processor. For x86 and ARM, the mapping is defined in a variable called OEMAddressTable. Since .bib files operate largely on virtual addresses, we need to remember to reference the OEMAddressTable to address any confusion about what is happening at a particular physical address.
The table’s layout is quite simple. Each line creates a mapping of virtual addresses to physical addresses. The syntax is: Base virtual address, base physical address, size. Let’s take an example from the Mainstone BSP:
DCD 0x80000000, 0xA0000000, 64 ; MAINSTONEII: SDRAM (64MB).
DCD 0x88000000, 0x5C000000, 1 ; BULVERDE: Internal SRAM (64KB bank 0).
DCD 0x88100000, 0x58000000, 1 ; BULVERDE: Internal memory PM registers.
DCD 0x88200000, 0x4C000000, 1 ; BULVERDE: USB host controller.
So in the first line, we are mapping the 64MB of RAM at physical address 0xA0000000 to the virtual address 0x80000000. Since 64MB = 0x04000000 this means that the physical addresses 0xA000000-0xA4000000 are now mapped to virtual addresses 0x80000000-0x84000000. Likewise, we’ve mapped the USB host controller which resides at physical addresses 0x4C000000-0x4C100000 to virtual addresses 0x88200000-0x88300000.
Inside Windows CE, memory access is virtual by default. So when we access memory at 0x81005000, we’ll be accessing some physical memory in the Mainstone’s 64MB SDRAM bank. If we access memory at 0x88201000, we’ll be accessing the USB host controller, physically. If we access memory at 0x86001000, we’ll get a page fault because this virtual address has no corresponding physical address.
Now that we understand the OEMAddressTable, let’s talk about the .bib files.
Config.bib – this contains a lot of configuration info for a CE OS image. The MEMORY section is what we’ll focus on – it defines the memory blueprint for the CE image. Here are the important terms:
RAMIMAGE – This is the virtual address region that the kernel and any other components you select for your image will be placed in. This can be RAM or linearly addressable flash. Your config.bib file should have exactly one RAMIMAGE section. It needs to be virtually contiguous, and it needs to be large enough to hold whatever components you’ve selected.
RAM – This is the virtual address region of RAM that the kernel can allocate to applications and RAM-based file systems. It needs to be virtually contiguous. (If you need a non-contiguous section, you can allocate another, non-virtually-contiguous section at run-time by implementing the OEMGetExtensionDRAM function, but that’s outside our scope)
RESERVED – These are virtual address regions that are set aside – the kernel won’t allocate memory in these addresses and components won’t be placed in these addresses.
AUTOSIZE - In the CONFIG section, we have the AUTOSIZE=ON (or OFF) variable. If this variable is on, it will treat the RAMIMAGE and RAM regions as a single region, allocating just enough space to hold all of the components to the RAMIMAGE section and making the rest of the space available as RAM. This is a pretty convenient and easy way to make sure you’re getting maximal use out of your RAM. One thing autosize won’t do is interfere with reserved or unallocated regions.
Eboot.bib (sometimes known as boot.bib) – this works identically to config.bib, except we’re building a bootloader image as opposed to one with a full kernel. All of the terminology is exactly the same. The only difference is, in the case where we’re not using an MMU in the bootloader (CEPC is an example of these), the addresses will be physical as opposed to virtual. Otherwise, the layout is identical.
Bringing it together
In almost all cases, the bootloader and OS use the same OEMAddressTable. Thus, they have the same virtual address space.
This is especially useful when it comes to RESERVED regions. Since nothing will be allocated or placed in these addresses, only components that refer directly to the address will have access. That means we can use these regions for special buffers (say, DMA) or passing arguments passed in from the bootloader to the OS. It also means that, if you want, you can leave the bootloader in RAM.
Keep in mind that while RESERVED means that we won’t allocate/place components in those virtual addresses, by default if an area isn’t specified in a .bib file then we won’t allocate/place in it. This means RESERVED is really more of a comment then anything. However, it is useful in our .bib files because it helps us identify the location of special buffers and arguments so that we know not to overwrite them in other modules.
An Example
Let’s take a look at a simplified example in the CEPC BSP:
Here’s our OEMAddressTable (platform/common/src/x86/common/startup/startup.asm):
_OEMAddressTable:
dd 80000000h, 0, 04000000h
This means that we’re mapping physical addresses 0x00000000-0x04000000 to virtual addresses 0x80000000-0x84000000. That’s 64MB of RAM.
Here’s our boot.bib (platform/CEPC/src/bootloader/eboot/boot.bib):
MEMORY
; Name Start Size Type
; ------- -------- -------- ----
EBOOT 00130000 00020000 RAMIMAGE
RAM 00150000 00070000 RAM
ETHDMA 00200000 00020000 RESERVED
Remember the CEPC bootloader uses physical addresses. So in virtual address terms, our bootloader code is living at 0x80130000-0x80150000, with RAM available from 0x80150000-0x801C0000. We’re reserving a buffer for our Ethernet card from 0x80200000-0x80220000.
And a condensed version of config.bib (platform/CEPC/files/config.bib):
MEMORY
; Name Start Size Type
; ------- -------- -------- ----
; 64 MB of RAM (note: AUTOSIZE will adjust boundary)
NK 80220000 009E0000 RAMIMAGE
RAM 80C00000 03400000 RAM
DMA 80100000 00030000 RESERVED ; Native DMA reserved.
BOOTARGS 801FFF00 00000100 RESERVED ; Boot arguments
EDBG_DMA 80200000 00020000 RESERVED ; EDBG DMA buffer
There are several interesting things going on here:
First, our OS image (NK) starts at 0x80220000, and RAM resides directly above it. That means we’re not allowing any components or allocation to write below 0x80220000, and thus our bootloader code is protected.
Second, note that we have also reserved some regions. The EDBG_DMA corresponds to the same addresses that the bootloader reserved. This way we can make a smooth transition from bootloader to kernel without worrying about the contents of this memory being tampered with.
Another region has been reserved from 0x80100000-0x80130000. This is very close to the start of our bootloader. If we reserved even a byte more, we would not expect our bootloader to continue to be executable after we boot the OS. However, since the bootloader’s address space isn’t referenced by any region in config.bib, we know that it will remain untouched by the OS. This way we can jump back to the bootloader code during a warm reset, if desired.
We’re not required to keep our bootloader in memory, though. We could easily place the bootloader (in boot.bib) at the end of the RAM space (in config.bib). This way after the image was successfully downloaded we could allocate memory over the top of the bootloader and make full use of all of our system RAM. What you don’t want to do is intersect the bootloader with the RAMIMAGE part of config.bib – this means you’ll overwrite the code you’re running to download, during download!
Finally, notice we have a special reserved region called “boot arguments”. If we at the CEPC’s bootloader we will see that it writes explicitly to the (physical) 0x001FFF00-0x002000000. You’ll also notice this isn’t used anywhere in the boot.bib layout. That means we can be assured it will be untouched (unless, of course, something else in the bootloader writes explicitly to that address range).
This is how we pass arguments from the bootloader to the OS – the OS can read directly from 0x801FFF00 and be assured that the kernel won’t tamper with it because it is RESERVED. Technically, we could have indicated that area as RESERVED in the bootloader as well.
Hopefully this has given you some insight into .bib memory layouts.
update: In response to a comment generated by this entry I'd like to point out that the virtual addresses used in both OEMAddressTable and config.bib must fall between 0x80000000 and 0xA0000000 - the kernel virtual memory space reserved for cachable access.