S3C2410下WinCE6.0的启动过程详解

通过前两篇文章的介绍，我们已经知道NBOOT用来引导EBOOT，继而EBOOT加载并引导WinCE操作系统(NK)。那么，WinCE6.0的启动过程又是怎样的呢？本文基于S3C2410的平台做一个详细的分析。需要说明的是，WinCE6.0的整个启动过程对于同一类型的MCU来说大同小异，如S3C2410和PXA270同属ARM平台的MCU，所以他们的启动过程是类似的，可以说唯一的不同就在OAL处，而WinCE操作系统的启动正是从OAL开始的。
     OAL（OEM Adaptation Layer）即OEM适配层，它的主要作用是在移植WinCE到新的硬件平台时减少操作系统的修改，通俗的说就是为WinCE操作系统抹平MCU的差异，使其能很方便的在不同MCU上运行。所以，OAL包括了和系统硬件通讯的最底层代码。内核则通过OAL跟硬件进行交互。逻辑上，OAL是介于CE内核和设备硬件之间的一个代码层，是一个抽象的概念。物理上，OAL和其他一些库一起链接成可执行文件，在WinCE6.0中对应的文件是OAL.exe，这是OAL的客观存在。WinCE6.0中的OAL跟先前的OAL比，是有一些变化的，它从内核中分离出来成为OAL.exe，而内核则变成了Kernel.dll。这样做的好处是可以单独升级OAL。但整体的OAL结构并没有改变，OEM函数保持一致，OAL和Kernel的接口由共享结构NKGLOBAL实现。这一部分的具体内容下一篇再做介绍。下图所示为WinCE6.0的OAL设计。
      

在移植WinCE到新的硬件平台时，创建OAL是最复杂的任务之一。一般来说，最简单的方法是拷贝一个跟新的硬件平台类似的且成熟的OAL，然后根据硬件的不同进行修改，使其满足目标硬件的特定要求。这里不展开说明，回头再单独整理。
     从EBOOT到OAL.exe的跳转是从OEMLaunch（）开始的，函数OEMLaunch（）中调用Launch（dwPhysLaunchAddr），它的实现代码如下：

Code

    函数Launch（）的参数为物理地址，因为在跳转之前已将MMU关闭。该地址可通过VIEWBIN来查看，如下图所示：
     
     如何确定这个地址对应的是NK.bin中的哪一个文件呢，先前说是OAL.exe，证据何在。在PB6.0中增加了浏览NK.bin的功能，我们可以利用此功能查看NK.bin的详细情况，如下图所示：     

     从上图中可以看出0x80205394处对应的是NK.exe，而这里的NK.exe即为OAL.exe。
     至此，我们已经知道EBOOT是如何跳转到OAL.exe中的了。接下来继续看OAL.exe的执行过程。
     OAL的启动代码如下：

LEAF_ENTRY StartUp

        ; Compute the OEMAddressTable ' s physical address and 
        ; load it into r0. KernelStart expects r0 to contain
        ; the physical address of  this table. The MMU isn ' t 
        ; turned on until well into KernelStart.  

        add     r0, pc, #g_oalAddressTable - (. +  8)
        bl      KernelStart

OAL的启动代码和EBOOT的启动代码经常复用，但为了代码的简洁，最好还是分开实现，而且在EBOOT中如果已经初始化了相关硬件，那么OAL的启动代码就可以省去那部分工作，可以很简练，如上面的代码所示。

可以看出，OAL的启动代码又调用了函数KernelStart()，而这个函数是在文件C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\LDR\ARM\armstart.s中实现的，代码如下：

Code

从上面的代码可以看出，KernelStart()通过OEMAddressTable初始化了MMU，然后通过调用函数ARMInit()获得kernel.dll的入口点，最后跳转到kernel.dll的入口点处。

为了找到Kernel.dll的入口点，用IDA反汇编kernel.dll文件，可以看到，Kernel.dll的入口点为NKStartup。

NKStartup()的实现在文件C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\ mdarm.c中，代码如下： 

Code

NKStartup（）的代码就不多解释了，注释已经很详细。该函数的最后又调用了KernelStart ()函数。注意这里的KernelStart()跟上面曾提到的KernelStart()是不一样的。这里KernelStart()的实现在文件C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\armtrap.s中，代码和反汇编的对比如下图所示。          
     可以看到，这里调用了KernelInit()和FirstSchedule()这两个函数。先说FirstSchedule()，它开始了WinCE6.0的第一个调度。它的实现跟KernelStart()在同一文件中，而实现代码跟WinCE5.0中完全一样。接下来，我们继续跟踪KernelInit()函数，其实现在文件C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\nkinit.c中，代码如下： 

Code

     这段代码跟WinCE5.0中的结构基本一致，但实际上有很大的不同。跟WinCE6.0启动最紧密的函数是THRDInit ()，这之前都是做相应的初始化。THRDInit ()的实现在文件C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\thread.c中，代码如下：     

Code

    可以看到，这里开始了一个线程，线程处理函数为SystemStartupFunc()，其实现在文件C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\schedule.c，实现代码如下：     

Code

     这里创建了一个内核线程，处理函数为RunApps，继续跟踪RunApps，其实现在文件C:\WINCE600\PRIVATE\WINCEOS\COREOS\NK\KERNEL\kmisc.c中，代码如下：

Code

      终于启动filesys.dll了。这个过程简单说明一下，启动filesys.dll后等待其执行的情况，在完成了文件系统的相应的初始化之后，这里继续初始化MUI和系统设置，完成后再通知filesys这边的工作已经完成，filesys继续启动。这一部分的具体内容请参考MSDN，File System Boot Process： http://msdn.microsoft.com/en-us/library/aa912276.aspx。总之，filesys会完成WinCE的最后启动过程，包括gwes.dll和explorer.exe等。至此，WinCE6.0启动完成，如果有LCD且驱动能正常工作，现在就应该能看见可爱的WinCE6.0的界面了。

呵，没想到WinCE6.0的启动过程竟然这么繁长。不过，弄清楚这个启动流程对于移植BSP相当有好处。总结一下整个过程，如下图所示。    

     本文通过跟踪代码的方式，介绍了WinCE6.0的启动流程。流于表面了一点，很多细节应该进一步研究，以后再慢慢看吧。文中有不确切的地方，也请您不吝赐教.