编译生成eboot.bin的问题和boot.bib中RAM入口项注意事项

 

http://cky0612.blog.163.com/blog/static/2747891620128169238323/

 

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项所在的内存区域满足物理地址连续的要求。