WINCE6.0+S3C2451基于FMD的BSP移植---编译生成eboot.bin的问题和boot.bib中RAM入口项注意事项
1. 生成eboot.bin在下载时解析出来的长度为0
虽然把原来PM架构的BSP包中eboot的内容逐渐移植到FMD架构的BSP包中，eboot.bin也越来越大，后来发现在一次下载中无法下载eboot.bin，eboot在下载eboot.bin中解析到它的长度是0x00000000，可是这时候我看到eboot.bin的大小是271KB，怎么会是0呢？我们先来看eboot\boot.bib中的部分定义：
MEMORY
; Name Start Size Type
; ------- -------- -------- ----
ARGS 80020800 00000800 RESERVED
RAM 80021000 0000B000 RAM
STACK 8002c000 0000A000 RESERVED
EBOOT 80038000 00080000 RAMIMAGE
BINFS 800C0000 00021000 RESERVED
………………………
为什么随着生成的eboot.bin大小的变大会出现上面的现象呢？后来发现把上面的
RAM 80021000 0000B000 RAM
的大小0x0000B000调大了就解决了这问题，而这次使eboot.bin的改变就是把充电指示logo的头文件包含进来，比如eboot\main.c中增加了#include "battery1.h"，而battery1.h中一部分内容如下所示：
图1
也就是说增加了无符号型全局数组battery1[36608]之后就出现了上面的情况，通过viewbin –r eboot.bin先看可以正常下载的eboot.bin的record信息
ViewBin... eboot.bin
Image Start = 0x80038000, length = 0x00042948
Record [ 0] : Start = 0x80038000, Length = 0x00000004, Chksum = 0x00000288
Record [ 1] : Start = 0x80038040, Length = 0x00000008, Chksum = 0x00000260
Record [ 2] : Start = 0x80038048, Length = 0x00000004, Chksum = 0x0000004D
Record [ 3] : Start = 0x80039000, Length = 0x0003FFF8, Chksum = 0x01F90406
Record [ 4] : Start = 0x80079000, Length = 0x00000930, Chksum = 0x000240A1
Record [ 5] : Start = 0x80079930, Length = 0x00000054, Chksum = 0x00000C10
Record [ 6] : Start = 0x80079984, Length = 0x00000030, Chksum = 0x00000EC8
Record [ 7] : Start = 0x8007A000, Length = 0x00000948, Chksum = 0x00010A81
Record [ 8] : Start = 0x00000000, Length = 0x800623E0, Chksum = 0x00000000
⑶
Checking record #5 for potential TOC (ROMOFFSET = 0x00000000)
Found pTOC = 0x80079930
ROMOFFSET = 0x00000000
Done.
不能正常下载的eboot.bin的record信息如下：
ViewBin... eboot.bin
Image Start = 0x80038000, length = 0x00000000
Record [ 0] : Start = 0x80079984, Length = 0x00000020, Chksum = 0x00000B5E
Record [ 1] : Start = 0x80039000, Length = 0x0003FFA8, Chksum = 0x01F92096
Record [ 2] : Start = 0x8007A000, Length = 0x00002ED0, Chksum = 0x00020A26
Record [ 3] : Start = 0x80079000, Length = 0x000008C0, Chksum = 0x00023918
Record [ 4] : Start = 0x80078FA8, Length = 0x00000048, Chksum = 0x00000CA1
Record [ 5] : Start = 0x800798C0, Length = 0x00000070, Chksum = 0x000007B9
Record [ 6] : Start = 0x80078FF0, Length = 0x00000008, Chksum = 0x00000249
Record [ 7] : Start = 0x80038040, Length = 0x00000008, Chksum = 0x00000260
Record [ 8] : Start = 0x80038048, Length = 0x00000004, Chksum = 0x0000004D
Record [ 9] : Start = 0x800799A4, Length = 0x00000010, Chksum = 0x000003D4
Done.
仔细比较可以发现有下面几点的差别：
⑴记录eboot.bin长度的length由 0x00042948变为0x00000000，也就是这个原因导致在下载eboot.bin的时候导致下载不成功的。
⑵ Record [ 0]的开始低脂Start由0x80038000变为0x80079984。
⑶不能下载的eboot.bin没有输出eboot.bin在内存中开始运行的起始地址，比如Start address = 0x800623E0
如果要彻底搞清楚这些问题，需要去研究romimage.exe的源代码了，在此只重点关于为什么增加了RAM 80021000 0000B000 RAM的大小就可以解决此问题。所以下面就先来重新看看这一项的意义。
2. Boot.bib中RAM的意义
MEMORY
; Name Start Size Type
; ------- -------- -------- ----
…………………
RAM 80021000 0000B000 RAM
………………
boot.bib中MEMORY指定了eboot镜像中有效且可用的内存的分配情况，而上面名为RAM这一项的属性类型为RAM，romimage就是根据这些内存段的type来决定内存段的用途的，上面这一项表示起始地址为0x80021000，大小为0x0000B000这段内存是作为eboot镜像运行时可用于分配空间的RAM空间，我在WINCE帮助文档关于config.bib中看到对名称为RAM这一项的描述“The RAM entry tells the ROM Image Tool (Romimage.exe) to place any executables, modules, data files, and compressed sections in this region.”，但对于eboot.bin来说不会包含可执行文件和数据文件(比如向platform.bib中可以指定包含一些文件)，moudle就是指eboot.exe本身，那么对于eboot.bin来说，就是compressed sections(压缩部分)会放在这个内存区域中，而类似图1中的全局数据battery1就是可以压缩的数据部分，这应该就可以解释为什么增加编译此数组所在的头文件后会导致上面的问题了。
另外需要注意入口为RAM的内存必须是物理上连续的，这与与我们的板上有几片SDRAM没有直接的关系，最主要是看硬件上的设计和对应的处理器的RAM地址的分配，我们采用的是S3C2451，所以先看此处理器memory map部分的描述
图2
从内存映射图可以看出S3C2451支持2个bank，每个bank的地址空间最大为128MB，接下来我们来看硬件原理图上的设计：
图3
图3为S3C2451处理器nSCS0片选信号引脚和DDR2 SDRAM内存芯片中第一片的部分连接图
图4
图4为S3C2451处理器nSCS1片选信号引脚和DDR2 SDRAM内存芯片中第二片的部分连接图。
截图图2、图3和图4可知道，第一片映射到S3C2451物理内存地址0x30000000到0x33FFFFFF这64MB的内存区域中，第二片映射到S3C2451物理内存地址0x38000000到0x3BFFFFFF这64MB的内存区域中，这样的设计就决定了我们物理地址到虚拟地址映射表g_oalAddressTable对内存区域的映射如下所示了：
DCD 0x80000000, 0x30000000, 64 ; 64 MB DRAM BANK 6
DCD 0x84000000, 0x38000000, 64 ; 64 MB DRAM BANK 7
也就是说虚地址0x80000000~0x83FFFFFF映射到物理地址0x30000000~0x33FFFFFF中，而0x84000000~0x87FFFFFF映射到物理地址0x38000000~0x3BFFFFFF中，所以可以看出这128MB虚拟内存和物理内存的映射图如下所示；
图5
现在我们回过头来看boot.bib中RAM入口项的值
RAM 80021000 0000B000 RAM
可以看出0x80021000~0x8002C000对应的物理内存0x30021000~0x3002C000是落在第一片内存芯片的地址空间中，我们再来看看config.bib中RAM入口项的值
RAM 80500000 03400000 RAM
由此也可以看出是落在第一片内存芯片的地址空间中，RAM项所在的内存区域满足物理地址连续的要求。