|
- UID
- 872238
|
首先通常都是汇编代码：启动时由系统复位导致PC为0为触发条件：以2440代码为例直接进入fw.s文件。主要执行的操作为设置处理器频率（PLL），设置内存参数，须注意的是在该部分代码虽然在形式上实现了诸多中断向量，但是这些代码根本上不会得到执行。（参考“Eboot 编译编译器决定中断向量及其实现单一性的原因”）而在后面会有一些其他手段用于实现中断向量的功能。由于和hal复用该部分文件，所以调用的函数名称会与内核启动函数的相同（如：KernelStart），但是实现内容却是完全不同的。在该部分的最后还将保存一个OEMAddressTable的地址指针到下一格函数，进行应有的内存影射。下面还是以2440bsp为例说明。根据windowsCE系统的要求，需要把将会操作到的内存空间影射到0x8000 0000后的512M空间中，其中低256M为带缓冲的，高256M则是不带缓冲的。不带缓冲的区域通常是驱动访问设备必须的，这样可以保障对硬件的操作不受到缓冲的干扰。除了按照OEMAddressTable进行内存空间影射外，还可以要根据程序需求进行其他一系列影射，通常的做法都是将目前所有的设备/内存在原地址空间上再影射一次，以方便使用。另外就是在将0x0位置影射到内存，这样，就可以通过这个部分来进行中短向量的安装了，以实现中断服务程序。（以上内存影射并不是必须的，仅仅是为了方便程序的编写而已，使用和系统相同的影射表可以使得不必重新另外建一套头文件，同时如果需要的话可以一直在内存中保存eboot，这样内存空间的规划也会相对容易做一些）。
以上的这些工作做完，就进入windowsCE提供的eboot入口函数了。 也就是BootloaderMain.这个函数位于WINCE420\PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON\blcommon.c文件中。该目录的文件就是微软提供的eboot框架，尽管这不是实现的部分，也一并分析了吧。这部分的内容一开始就很有意思，第一个执行的语句如下if （！KernelRelocate （pTOC）） { HALT （BLERR_KERNELRELOCATE）； }而这个传入的参数却这样定义：ROMHDR * volatile const pTOC = （ROMHDR *）-1； 按照程序的内容来说，这个函数到这里一定是死循环了，可是事实上这个死循环不会得到执行，也就是pTOC = （ROMHDR *）-1并没有真正的起到作用。：） 在pTOC第一次使用前检查了一下pTOC的值，结果如下：pTOC=0x8C04D694.也就是说pTOC在没有被改变之前就已经不再是-1了，而且pTOC是被定义成const的，也没有办法去改变，看样子就只能是编译器的过程中这个指针就已经被动了手脚。而查看eboot.map中该地址所对应的内容居然是bootpart.obj的内容。感觉是无从下手了，这样子让人太费解了。仔细比较eboot.exe和eboot.nb0后发现，eboot.exe通过romimage处理后长度增加了，而且结构上改变了许多，在原。eboot.exe后增加了一系列原来没有内容，pTOC的内容就是属于这部分内容中的一部分。由于牵涉到windowsCE的Image Chain结构，所以无法继续往下分析，这部分的内容就先跳过。以后再回头来看。
随后在 BootloaderMain中对调试界面进行初始化，由OEMDebugInit完成这个函数的实现是由具体的硬件决定的通常来说为串口的初始化，再次以后就通过该调试界面进行调试信息的发布。
然后在OEMPlatformInit（）中对eboot所要用到的硬件资源进行初始化设备，通常这些会包含：存储设备（FLASH、硬盘等）、传输界面（以太网卡、USB-RNDIS、无线网卡、CF—LAN等等）、系统时钟，为下面将会进行的os镜像传输、os镜像存储、读取等等一系列动作做好准备。 |
|
