关于eboot和binfs的一些问题请教大家！！！

jiafa

关于eboot和binfs的一些问题请教大家！！！ [复制链接]

这两天研究了一下eboot的烧写和加载镜像以及binfs。研究的不够深入，看了一下前辈们以前写的博客，但是依旧有很多疑问。因此特来向大家请教一下：
1.我按照网上前辈们的帖子按部就班的想实现multibin，最后生成了xip.bin文件，烧写进去之后，发现加载速度确实快了不少，但是一看打印信息，傻了眼了，发现还是加载了整个xip.bin文件，打印信息：
OEMPlatformInit: IMAGE_TYPE_RAMIMAGE
+=OEMVerifyMemory+ dwStartAddr:0x80200000  dwLength:0x4
RAM image 0xa 0x80200003
+=OEMVerifyMemory+ dwStartAddr:0x8029cd84  dwLength:0x4
RAM image 0xa 0x8029cd87
IsValidMBR: MBR sector = 0x1000
OpenPartition: Partition Exists=0x1 for part 0x21.
BP_SetDataPointer at 0x0
ReadData: Start = 0x0, Length = 0x139ba00.

我的xip.bin文件19.2M,按理说，在这里应该只是加载RAMIMAGE大小才对的，在实现multibin的过程中我并没有修改eboot的代码，不知道是不是要修改  BP_ReadData（）的代码让它只读RAMIMAGE大小。
我的config.bib相关配置如下：

MEMORY

    XIPKERNEL            80200000  00200000  RAMIMAGE
    CHAIN                    80400000  00001000  RESERVED
    NK                      80401000  02BFF000  NANDIMAGE
    RAM                        80401000  03BFF000  RAM
;   RAM                        8C340000  03CC0000  RAM
    pdwXIPLoc            00000000  80400000  FIXUPVAR
;   FLASH                  92000000  00100000  RESERVED

; Common RAM areas
        AUD_DMA                        80002000  00000800  RESERVED
        SDIO_DMA                80010000  00010000  RESERVED
        ARGS                        80020800  00000800  RESERVED
        DBGSER_DMA                80022000  00002000  RESERVED
        SER_DMA                        80024000  00002000  RESERVED
        ;IR_DMA                        80026000  00002000  RESERVED
        ;SLEEP                        80028000  00002000  RESERVED
        ;EDBG                        80030000  00020000  RESERVED
        DISPLAY                        80026000  00180000  RESERVED   

CONFIG
  AUTOSIZE=ON
  COMPRESSION=ON
  DLLADDR_AUTOSIZE=ON
  KERNELFIXUPS=ON
  PROFILE=OFF
  RAM_AUTOSIZE=OFF
  ROMFLAGS=0

  ROM_AUTOSIZE=OFF
  XIPSCHAIN=80400000  


2.我在看eboot加载镜像的代码时，在BootloaderMain的一开始，就是执行KernelRelocate (pTOC)，对eboot的全局变量进行重定位，当然原因是因为之前全局变量在ROM去不可写，因此把他们重定位到内存。按照我的理解，TOC是一个54字节的结构体，它记录的是镜像内的TOC条目的信息。而这个TOC条目是不是就是我们用viewbin工具看到的一个一个的record[]？TOCentry又是什么？ 我看KernelRelocate 的代码，好像就是把所有的COPYentry全部都拷贝到目标地址,这些0COPYentry应该是在内存中紧接着TOC的条目。如果COPYentry就是对应recourd[]的话，那意思就是说把镜像里的各个模块拷贝到程序内存，这样理解好像不对吧？

3.烧写镜像后，现在加载速度也不是很理想，网上大部分人说加载主要的时间都是花在从FLASH加载镜像到RAM比较花时间，但是我发现每次系统加载完成后，执行到下面的时候也会卡很久，不知道什么原因！！
OEMIoControl: Unsupported Code 0x10100b4 - device 0x0101 func 45
OEMIoControl: Unsupported Code 0x101008c - device 0x0101 func 35
FMD_OEMIoControl: unrecognized IOCTL (0x71c24).
OEMIoControl: Unsupported Code 0x1010104 - device 0x0101 func 65
BINFS: RegisterVolume - Mounted volume '\BINFS'
OEMIoControl: Unsupported Code 0x10100c4 - device 0x0101 func 49
OEMIoControl: Unsupported Code 0x10100c4 - device 0x0101 func 49

pcshow

在DownloadImage里面，它会先读镜像的前7个字节，也就是magic number来判断镜像的类型，如果是multibin镜像的话应该前七个字节是“N000FF\x0A”，但是我发现我生成的XIP。bin文件的前七个字节是"B000FF\x0A"，然后就直接把整个。bin文件通过USB接口读到dwImageStart的地址。

zms9439

XIP的最主要目的是在系统启动后镜像占用的RAM空间变小了，留给用户的内存空间增大，而对于启动速度还是要看具体驱动加载的实现方法，烧录的时候烧录整个XIP.BIN也没问题。
你可以看下进入WINCE后你的内存空间与之前的NK会有较大变化。

zx0083q

韦伯，是的，现在可用明显增加了，但是如果按照multi bin的原理，应该能够实现按需加载，也就是说启动的时候只需要加载RAMIMAGE就可以了，但是为什么现在我每次从flash读的时候都是读整个镜像大小，而不是读RAMIMAGE?

xiukiss

按需加载的意思是说在WINCE运行过程中，只根据需要加载相应的模块到RAM，不需要再释放，这样可以达到节省内存的效果，比如，某个进程需要调用XX.DLL，则从BINFS中读取XX.DLL到RAM中，否则内存中并不存在这个XX.DLL，而不像NK的形式，所有的东西都已经在RAM中。

不过mul-bin的另一方面是把之前的镜像分成了几块，更新的时候似乎可以分别更新各BIN文件，这点不确定，我也没这么用过，一直都是烧录XIP.BIN，反正我的目的仅仅是节省内存，至于启动速度，用了MUL-BIN在我的板子上并没有提高，因为驱动太多，且启动的时候就需要加载。

kendy630314511

如果想在启动的时候只从NAND读取需要的内容可以尝试一下烧录chain.lst文件。

happybean

听veabol一介绍
通俗讲不就是 overlay 么？

zjl2050

试着用PB下载

songguoda

veabol正解，呵呵

yanfang2003

有个新的疑问，在我的eboot代码中，第一次烧写镜像的时候，先把USB发送过来的镜像cashe到预先分配的一个区域，在OEMlaunch函数里面再把cashe的镜像创建分区然后写到分区里面，写完之后又把cashe的内存memcpy到dwLoadAddress的内存，这是为什么？为什么不直接LAUNCH到cashe的内存 而要拷贝两次呢？

hailangties

正常启动时EBOOT将NAND中的OS数据读取到dwLoadAddress再launch。
在我的EBOOT中，整个烧录过程是
1、USB下载数据到DMA区。（BIN文件）
2、DMA区的数据解压缩到cashe区。
3、将cashe区的数据写到NAND区。
4、从NAND读数据到dwLoadAddress。
5、launch。

与你的不同是，我的不是直接将cashe数据读到dwLoadAddress。
但是其根本目的应该是OEMlaunch函数的通用性，任何情况下4、5步骤都是要做的。

你再细分析分析你的代码，看看是不是也是这样的目的。

cyllouis

谢谢韦伯，我明白了~ 但是究竟如何提高启动速度，还是得根据自己的系统来分析，看在哪一块花了比较多的时间，我感觉其实从flash加载镜像到sdram并没有花多少时间，大概6-7S，还能接受，但是在打印完下面信息之后就卡了N久，不知道什么原因,卡在这里到底是什么原因？
OEMIoControl: Unsupported Code 0x10100b4 - device 0x0101 func 45
OEMIoControl: Unsupported Code 0x101008c - device 0x0101 func 35
FMD_OEMIoControl: unrecognized IOCTL (0x71c24).
OEMIoControl: Unsupported Code 0x1010104 - device 0x0101 func 65
BINFS: RegisterVolume - Mounted volume '\BINFS'
OEMIoControl: Unsupported Code 0x10100c4 - device 0x0101 func 49
OEMIoControl: Unsupported Code 0x10100c4 - device 0x0101 func 4
/////卡了。。。。。。//////

samhesam

我的在提示某个OEMIoControl不支持以后也会卡一会，大概一两秒，后来在BSP中加了那个OEMIoControl仍然如此，所以应该不是不支持哪个OEMIoControl才导致的卡，但是到底为什么卡我也不清楚，这部分是内核在执行，又没有输出信息，不好追踪。