|
理解BinFS, Multi-XIP, Multi-bin<br /><br />欢迎访问: www.chenyq2008.spaces.live.com<br /><br />----------------------------------<br /><br />[bin文件的格式]<br />Bin文件格式比较简单.前面7个字节是标志, 固定的{‘B’, ‘0’, ‘0’, ‘0’, ‘F’, ‘F’, ‘a’}. 接下来4个字节是Image Start表示image的开始地址, 这个地址,按我想其实就是加载地址了. 然后4个字节是Image Length,表示image的长度. 下面这个结构体说明了bin文件的格式. <br /><br />struct BinFile { <br /><br />BYTE signature[7]; <br /><br />DWORD ImageStart; <br /><br />DWORD ImageLength; <br /><br />Record ImageRecords[ImageLength]; <br /><br />} <br /><br />其中Record的结构是 <br /><br />struct Record{ <br /><br />DWORD address; <br /><br />DWORD length; <br /><br />DWORD chksum; <br /><br />} <br /><br />[BinFS]<br />bin文件则是由romimage.exe产生的文件,包含image,是image的载体形式. 我们的nk.bin就是由romimage产生的image文件了. Binfs是Binary Rom Image File System. 是一个文件系统. Binfs和bin文件什么关系? <br /><br />下面的描述是我的猜测: 因为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. <br /><br />Eboot能识别bin文件格式,在写image的时候, 把bin文件里面image写入到flash 加载的时候, 把image读出到内存正确地址. bin也许会用到压缩image. eboot并没有解压image, 只是忠实的按照地址执行拷贝过程. <br /><br />[Multi-XIP] <br />XIP : Excute-in-place.本地执行. 意思是可以直接执行而不需要拷贝到内存执行. 比如nor flash 和 masked ROM设备, 上面的代码都可以XIP, 而nand不行. Multi-XIP的意思是在把一个image分成多个XIP regions. 从而可以分布在ROM的不同地址. <br /><br />那么Multi-XIP什么意思? 本来image是一个连续分布的整体,需要install在一块连续的ROM 区域或者nor区域. 而Multi-XIP技术可以将这个整体打散成几个. 这就是我最简单的理解了.基于Multi-XIP, 就可以将image分散分布在各个ROM了. <br /><br />[Multi-bin] <br />在文档也会看到Multi-bin的字眼. 那么Multi-XIP和Multi-bin什么联系和区别?下面又是我的猜测: <br /><br />字面上Multi-bin是很多个bin的意思了. Bin只是image的一种载体形式. 对image也许会有许多格式, 比如hex, nb0…所以,我想, Multi-bin是Multi-XIP的一种. <br /><br />[加快启动速度和节省ram]<br />这部分描述的特性一定强烈吸引人. Multi-XIP 只是把一个image分成几个regions, 并不会加快启动速度和节省ram. 怎么才会呢? 要知道一个WinCE的image里面很多的文件并不是启动时候需要加载到ram的. 设想我们如果能够把必须的部分加载到内存, 其余的部分仍然留在nand中, 等到需要的时再从nand磁盘加载. 这一方面使得加载到内存的image大幅减小, 从而加快了从nand拷贝到ram的速度. 另外, 也减少了对ram的占用. <br /><br />所以, 达到这个目的有2个要求, <br /><br />(A) 能够把一个image打散, 至少打成2个,一个是关键性的启动必要文件, 另外一个是在启动后动态加载. 这不就是Multi-XIP技术了吗? <br /><br />(B) 为了能作内核启动后动态加载, 需要把image做成文件系统. 这不就是binfs了吗 <br /><br />[分析]<br />在WinCE5.0 +arm920t + 64M SDRAM + 64M nand的系统, 我成功的实现了multi-xip和binfs. 上电到桌面跳出时间缩短到5秒内. 可用内存也大幅增加到60M多. <br /><br />实现这项特性的关键还是要对系统的启动非常熟悉. 简单描述下启动过程如下: <br /><br />还是那张图(到之前的**可以找到), 这次我们关注的是KernelInit部分. 其中ProcInit()把nk.exe作为当前进程,准备好了, SchedInit()把nk.exe的启动函数地址设置为SystemStartupFunc, 所以FirstSchedule()之后, nk.exe开始运行了, 从SystemStartupFunc开始了 <br /><br />SystemStartupFunc() <br /><br />{ <br /><br />KernelInit2(); <br /><br />加载coredll.dll, 并取得几个api函数地址 <br /><br />如果定义了START_KERNEL_MONITOR_THREAD宏,则启动线程Monitor1内核线程 <br /><br />创建并启动PowerHandlerGuardThrd内核线程. <br /><br />加载shimeng.dll <br /><br />创建并启动CleanDirtyPagesThread内核线程. <br /><br />创建并启动RunApps内核线程. <br /><br />While(1) <br /><br />{ <br /><br />无限等待hAlarmThreadWakeup.并处理. <br /><br />} <br /><br />} <br /><br />在KernelInit2()函数中, 会加载kd.dll(kernel debug), hd.dll, osaxst0.dll, osaxst1.dll, kcover <br /><br />.dll, celog.dll. 但这些dll包括后面的shimeng.dll都不是必须的.至少不是这个阶段必须的. <br /><br />关键在RunApps这个线程里面, 它启动了filesys.exe <br /><br />RunApps() <br /><br />{ <br /><br />CreateProcess(filesys.exe…)并等待注册表准备好事件. <br /><br />InitMUILanguages(); <br /><br />} <br /><br />这个InitMUILanguages是多国语言的初始化. 这里需要使用wince.nls这个文件.否则, 在我的平台会出现3个data abort.导致启动失败. 我的测试平台是英文locale. <br /><br />这阶段总结下, 需要的有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 <br /><br />.dll, celog.dll和shimeng.dll经实践都不是必须的. 酌情加入. <br /><br />[Filesys.exe的启动过程]<br />Filesys.exe被创建启动, 先执行Init()函数, 在Init()里面调用InitStorageManager()初始化StorageManager. <br /><br />InitStorageManager() <br /><br />{ <br /><br />创建并注册相关api. <br /><br />创建消息队列 <br /><br />创建PNPThread线程 <br /><br />AutoLoadFileSystems() <br /><br />} <br /><br />在我们正常的逻辑里面, 磁盘设备, 块设备等都是需要先经由device.exe初始化后, 然后交给filesys.exe来Mount. 所以PNPThread会在运行期等待device.exe发出事件,获知pnp设备插入. 但InitStorageManager()函数的最后一个函数调用提供了重要机制. 使得启动时候也会有机会Mount磁盘. <br /><br />至此, 注册表可访问了, 磁盘也Mount上了. 剩下的事情就是根据注册表的启动项来进行后面的事了. 注册表的启动项在HKLMinit下面的launch, 在这里设置后续加载device.exe, gwes.exe, explorer.exe, service.exe. <br /><br />总结这个阶段要用到的文件, <br /><br />filesys.exe和fsdmgr.dll: StorageManager的实现在fsdmgr.dll <br /><br />注册表boot.hv, nand flash的驱动即块驱动smflash.dll, 分区驱动mspart.dll, 2个fsd文件系统驱动fatfsd.dll和binfs.dll, 还有一个disk cache模块 diskcache.dll和fatutil.dll <br /><br />实现的具体工作还包括修改bib和reg. 最重要的是config.bib的修改.还有storagemanager怎么使用注册表的配置, 这些比较容易从网络搜索获得, 先埋个坑,以后有时间在补充了.<br /><br /> 相关链接:<a href='http://chenyq2008.spaces.live.com/blog/cns!F73164AC8D0D8D50!218.entry'>http://chenyq2008.spaces.live.com/blog/cns!F73164AC8D0D8D50!218.entry</a> |
楼主
