关于BinFS，Multi-XIP，Multi-Bin的理解

1、【Bin文件格式】

      Bin文件格式比较简单，前面7个字节是标志，固定的{'B','0','0','0','F','F','/a'}，接下来4个字节是Image Start表示image的开始地址，然后4个字节是Image Length,表示image的长度。下面这个结构体说明了bin文件的格式：

struct BinFile

{

     BYTE signature[7];

     DWORD ImageStart;

     DWORD ImageLength;

     Record ImageRecords[ImageLength];

}

其中Record的结构是

struct Record

{

     DWORD address;

     DWORD length;

     DWORD chksum;

}

 

2、【BinFS】

     Bin文件则是由romimage.exe产生的文件,包含image,是image的载体形式. 我们的nk.bin就是由romimage产生的image文件了. BinFS是Binary Rom Image File System. 是一个文件系统. BinFS和bin文件什么关系?

     下面的描述是我的猜测: 因为binfs是基于bin的一种文件格式.(A)bin是一个简单的,线性分布的记录的集合(B).大部分的Bin,其中的record是压缩后的数据. 所以使用binfs时候, 驱动处理record包含一个解压过程, 继而再呈现为磁盘文件. 这是文件系统驱动在binfs读文件的情况, 反过来写就十分困难.如果期望在binfs上创建或者修改, 设想下, 先需要把文件处理成为record, 为了替换原来的record, 更可怕的是, binfs是一个简陋之极的filesystem, 它的所有的record是线性连续分布的, 它甚至都不是一个链表…所以对其任意修改都是伤筋动骨的. 因此在binfs.dll的fsd驱动里面, FSD_WriteFile, FSD_SetFileTime…这样的需要修改binfs等函数接口全部都是设置一个错误:SetLastError( ERROR_ACCESS_DENIED);然后返回. 因此直接替换一个或者几个record是困难的.最好重新整体打包一个bin, 然后替换掉binfs, 那么另外一个问题, 如果打包后的binfs超过原来的大小了, 还得修改磁盘分区表…… 话说回来, binfs设计的目的也就是一个只读的filesystem, 是image载体.再次体会下binfs的名称:Binary Rom Image File System. 如果你非得打入敌人内部, 可以仔细看看romimage的源代码, 它提供了一些有意义的工具来帮助你, catbin, compress, sortbin, viewbin, cvrtbin, stampbin, checksymbols.

     Eboot能识别bin文件格式,在写image的时候, 把bin文件里面image写入到flash 加载的时候, 把image读出到内存正确地址. bin也许会用到压缩image. eboot并没有解压image, 只是忠实的按照地址执行拷贝过程.

 

3、【Multi-XIP】 

     XIP : Excute-in-place.本地执行. 意思是可以直接执行而不需要拷贝到内存执行. 比如nor flash 和 masked ROM设备, 上面的代码都可以XIP, 而nand不行. Multi-XIP的意思是在把一个image分成多个XIP regions. 从而可以分布在ROM的不同地址.

     那么Multi-XIP什么意思? 本来image是一个连续分布的整体,需要install在一块连续的ROM 区域或者nor区域. 而Multi-XIP技术可以将这个整体打散成几个. 这就是我最简单的理解了.基于Multi-XIP, 就可以将image分散分布在各个ROM了.

 

4、【Multi-bin】

     在文档也会看到Multi-bin的字眼. 那么Multi-XIP和Multi-bin什么联系和区别?

     下面又是我的猜测: 字面上Multi-bin是很多个bin的意思了. Bin只是image的一种载体形式. 对image也许会有许多格式, 比如hex, nb0…所以,我想, Multi-bin是Multi-XIP的一种.

 

5、【加快启动速度和节省RAM】

     这部分描述的特性一定强烈吸引人. Multi-XIP 只是把一个image分成几个regions, 并不会加快启动速度和节省ram. 怎么才会呢? 要知道一个WinCE的image里面很多的文件并不是启动时候需要加载到RAM的. 设想我们如果能够把必须的部分加载到内存, 其余的部分仍然留在nand中, 等到需要的时再从nand磁盘加载. 这一方面使得加载到内存的image大幅减小, 从而加快了从nand拷贝到ram的速度. 另外, 也减少了对ram的占用.

     所以, 达到这个目的有2个要求,

(A) 能够把一个image打散, 至少打成2个,一个是关键性的启动必要文件, 另外一个是在启动后动态加载. 这不就是Multi-XIP技术了吗？

(B) 为了能作内核启动后动态加载, 需要把image做成文件系统. 这不就是binfs了吗？

 

6、【分析】

     在WinCE5.0 +arm920t + 64M SDRAM + 64M nand的系统, 我成功的实现了multi-xip和binfs. 上电到桌面跳出时间缩短到5秒内. 可用内存也大幅增加到60M多.

     实现这项特性的关键还是要对系统的启动非常熟悉. 简单描述下启动过程如下：

     这次我们关注的是KernelInit部分. 其中ProcInit()把nk.exe作为当前进程,准备好了, SchedInit()把nk.exe的启动函数地址设置为SystemStartupFunc, 所以FirstSchedule()之后, nk.exe开始运行了, 从SystemStartupFunc开始了

SystemStartupFunc()

{

     KernelInit2();

     加载coredll.dll, 并取得几个api函数地址

     如果定义了START_KERNEL_MONITOR_THREAD宏,则启动线程Monitor1内核线程

     创建并启动PowerHandlerGuardThrd内核线程.

     加载shimeng.dll

     创建并启动CleanDirtyPagesThread内核线程.

     创建并启动RunApps内核线程.

     While(1)

   {

     无限等待hAlarmThreadWakeup.并处理.

   }

}

     在KernelInit2()函数中, 会加载kd.dll(kernel debug), hd.dll, osaxst0.dll, osaxst1.dll, kcover.dll, celog.dll. 但这些dll包括后面的shimeng.dll都不是必须的.至少不是这个阶段必须的. 关键在RunApps这个线程里面, 它启动了filesys.exe

RunApps()

{

     CreateProcess(filesys.exe…)并等待注册表准备好事件.

     InitMUILanguages();

}

这个InitMUILanguages是多国语言的初始化. 这里需要使用wince.nls这个文件.否则, 在我的平台会出现3个data abort.导致启动失败. 我的测试平台是英文locale.

      这阶段总结下, 需要的有nk.exe(也就是kern.exe, kernkitl.exe, kernprof.exe之一), coredll.dll, wince.nls.filesys.exe. 其他的kd.dll(kernel debug), hd.dll, osaxst0.dll, osaxst1.dll, kcover.dll, celog.dll和shimeng.dll经实践都不是必须的. 酌情加入.

 

【Filesys.exe的启动过程】 

     Filesys.exe被创建启动, 先执行Init()函数, 在Init()里面调用InitStorageManager()初始化StorageManager.

InitStorageManager()

{

     创建并注册相关api.

     创建消息队列

     创建PNPThread线程

    AutoLoadFileSystems()

}

     在我们正常的逻辑里面, 磁盘设备, 块设备等都是需要先经由device.exe初始化后, 然后交给filesys.exe来Mount. 所以PNPThread会在运行期等待device.exe发出事件,获知pnp设备插入. 但InitStorageManager()函数的最后一个函数调用提供了重要机制. 使得启动时候也会有机会Mount磁盘. 至此, 注册表可访问了, 磁盘也Mount上了. 剩下的事情就是根据注册表的启动项来进行后面的事了. 注册表的启动项在HKLM/init下面的launch, 在这里设置后续加载device.exe, gwes.exe, explorer.exe, service.exe.

     总结这个阶段要用到的文件, filesys.exe和fsdmgr.dll: StorageManager的实现在fsdmgr.dll 注册表boot.hv, nand flash的驱动即块驱动smflash.dll, 分区驱动mspart.dll, 2个fsd文件系统驱动fatfsd.dll和binfs.dll, 还有一个disk cache模块 diskcache.dll和fatutil.dll

     实现的具体工作还包括修改bib和reg. 最重要的是config.bib的修改.还有storagemanager怎么使用注册表的配置, 这些比较容易从网络搜索获得, 先埋个坑,以后有时间在补充了。