vxworks的移植

周看了小容儿的那篇《bootROM竟然被copy 到RAM_LOW_ADRS的地方去了！》文章，第一反应是－－不可能！结果自己一试果然是这样！可vxworks的各资料上明明说是bootrom被拷贝到RAM_HIGH_ADRS而vxworks映象是down到RAM_LOW_ADRS的呀！百思不得其解，只好自己来研究bootInit.c了，最后总算找到了答案。 先说说bootrom的类型。bootrom有三种类型：ROM_RESIDENT、UMCOMPRESS和COMPRESS。第一种是一直运行在rom中的映象，只把data段拷贝到ram里面；第二种是非压缩方式的映象，data段和text段都要拷贝到ram里面，并在ram里面运行；第三种是压缩方式的映象，生成的时候编译器会把除掉romInit.s和bootInit.c之外的目标文件压缩并“汇编”成一个bootrom.Z.s，最后和romInit.o,bootInit.o,version.o进行链接，生成bootrom映象。所以它也是要全部拷贝到ram中，且必须要进行压缩的工作。而这些工作基本上都是在bootInit.c中进行的。 bootInit.c里面主要就是romStart()这个函数，让我们来分析一下它。它的入口参数是startType，是一个启动类型标志，如BOOT＿CLEAR、BOOT＿NORMAL等，这在后面清内存时会用到。函数一开始定义了一个函数指针变量absEntry，它最后指向的就是ursInit()或compressedEntry()函数。接下来就是对三种bootrom映象类型进行不同的操作，下面我们以arm为例来分别说明。 1。ROM_RESIDENT：它要拷贝的只是data段。直接调用“ copyLongs ((UINT *)(etext + 4), (UINT *) RESIDENT_DATA, ((UINT) edata - (UINT) RESIDENT_DATA) / sizeof (long));”来实现。这时系统是运行在rom上的，链接器把所有的函数都定位在rom空间上，所以调用copyLongs时没有计算偏移，而拷贝的目标地址是RESIDENT_DATA，对于arm而言RESIDENT_DATA就是sdata，这是在romInit.s中定义的。通过objdumparm这个工具可以看到sdata定位在RAM_HIGH_ADRS＋0x4这个位置上。而etext + 4则是rom上data段的起始地址。这样，完成data段的拷贝。然后如果startType为冷启动，那么清零SYS_MEM_BOTTOM到栈底（RESIDENT_DATA - STACK_SAVE）以及data段结束之后（edata到SYS_MEM_TOP）的内存空间。然后将函数开始定义的指针absEntry指向usrInit（在rom中）：absEntry = (FUNCPTR)usrInit;并带上startType跳过去运行：(absEntry)(startType)，完成。 2。UMCOMPRESS：一开始它将text段和data段都拷贝到ram中：((FUNCPTR)ROM_OFFSET(copyLongs))(ROM_TEXT_ADRS, (UINT)romInit,　ROM_COPY_SIZE / sizeof (long))。这时的ROM_TEXT_ADRS就是代码段在rom上的开始位置，而romInit则是由链接器定位到了RAM_HIGH_ADRS的地址上，所以这时的确是按我们常规的思路拷贝的。并且由于copyLongs函数是定位到ram空间的，所以要计算它在rom上的偏移ROM_OFFSET(copyLongs)。然后象ROM_RESIDENT一样，它也要清零栈底（romInit - STACK_SAVE）以下和映象之上（SYS_MEM_TOP - (romInit + ROM_COPY_SIZE)）的内存空间。然后将函数开始定义的指针absEntry指向usrInit（在ram中）：absEntry = (FUNCPTR)usrInit;并带上startType跳过去运行：(absEntry)(startType)，完成。 3。COMPRESS：开始的时候把从ROM_TEXT_ADRS起始的长度为romInit到binArrayStart的内容拷贝到romInit位置上。注意，由于romInit被链接器定位到RAM_LOW_ADRS的位置上，这时相当于把romInit.o、bootInit.o和version.o的内容拷贝到了RAM_LOW_ADRS上。然后和UMCOMPRESS一样清零栈底（romInit - STACK_SAVE）以下的内存空间，不同之处是它接下来清除binArrayStart之上（SYS_MEM_TOP - binArrayStart）的内存空间：fillLongs ((UINT *)binArrayStart,　((UINT)SYS_MEM_TOP - (UINT)binArrayStart) / sizeof (long), 0)。然后调用解压程序inflate将在rom上的（binArrayEnd - binArrayStart）之间的内容解压到RAM_DST_ADRS（RAM_HIGH_ADRS）的位置上：binArrayStart(absUncompress) ((UCHAR *)ROM_OFFSET(binArrayStart),(UCHAR *)RAM_DST_ADRS, &binArrayEnd - binArrayStart)。这样，解完压后函数compressedEntry()刚好就在RAM_DST_ADRS（RAM_HIGH_ADRS）的位置上，所以接下来将指针absEntry指向它：absEntry = (FUNCPTR)RAM_DST_ADRS。最后带上startType跳过去运行：(absEntry)(startType)，完成。 所以我敢肯定小容儿的bootrom是COMPRESS类型的。有些细节地方我还没有仔细研究，欢迎各位大牛讨论！ 纠正一下：“romInit被编译器定位在RAM_LOW_ADRS处”这个说法是不对的。当映象为COMPRESS时的确是样，当为UMCOMPRESS时则是定位在RAM＿HIGH＿ADRS处，而当为ROM_RESIDENT时则定位在ROM_TEXT_ADRS处的。　　另外，当映象为压缩模式时解压到RAM_HIGH_ADRS处的是函数compressedEntry()的入口，由它调用usrInit(),而不usrRoot()。　　我没有仔细去研究Tornado的编译规则，只是采用了“笨”办法：用host/bin目录下的objdump工具来查看生成的bootrom、bootrom_uncmp和bootrom_res三个文件来分析的。这是一个非常有用的工具，它可以反汇编coff、elf之类的文件。你用“objdumpArm -t bootrom”就可以得到symbl表。另外，tornado在编译的时候也会以最后打印出类似“ldarm -X -N -e _romInit -Ttext 00001000”这样的信息，它就是将_romInit定位到x00001000。 但愿有所帮助。