基于VxWorks的bootrom代码改进

unzip_obj.o sysALib.o $(BSP_DIR)/unzip.o $(LIBS)flex.z.o

其中，unzip.c中包含构造的壳函数usrInit（）。SysInit()为解压软件入口函数。上述语句的功能：第一行完成壳文件的编译，第二、三行完成壳目标代码与第二份bootrom代码的链接。这样，一个具有解压功能的壳函数就被链接到第二份bootrom映像中了。
javascript:window.open(this.src);" style="cursor:pointer;"/>
    图1、图2是修改前的系统运行方式与修改后系统运行方式比较。

通过这两种方式的比较可以看出，修改前系统运行式与修改后的运行方式有下面两点差异；①第一份bootrom启动后，前者存在解压缩自射映像的操作，而后者没有；②对于第二份bootrom，前者没有壳代码，而后者有。

2.3 缩减文件长度

通常第一份bootrom代码只有两个文件，一个是包含CPU和SDRAM初始化文件romInit.s，另外就是包含romStart()函数的bootInit.c文件。另外，根据需要还可以添加提供串口轮询显示功能的文件。对于第一份bootrom代码，通常只有10KB左右（这是针对系统修改后的方式），而对于包含壳函数代码的，通过建立工程并编译而生成的第二份bootrom比较大，通常为570KB左右。（注意：这几个数值是通过特定的产品来得出的结论，并不应用于所有产品，但遇到类似的情况可以借鉴处理。）而其后面的一部分完全是0，可以考虑去掉这些0，但不能影响软件的功能。经过测试得出结论：去掉后面的0对系统功能和性能没有任何影响。

通过文件的操作来实现两份bootrom合并，合并后的大小要求小于或等于512KB。如果不采用任何措施，直接将两个文件合并起来要在580KB左右，大于512KB，这是很多系统不能满足的。第二份bootrom映像的后面部分的内容类似表1所列的信息。

表1 bootrom映像部分二进制内容

从表1可以看出，在地址0x00078233处就是0值了。这样可以通过对文件内容的操作将0x00078240后面的内容全部剔除，从而可将合并后的bootrom代码控制在512KB以内。当然，我们通常会选择一个整数值进行操作，即将0x0007824后的所有值去掉即可。

这样处理，可以减少维护和开发的工作量。如果按照以往的做法，bootrom软件对外将有第一份和第二份的区别，无论是生产、上层软件调试还是开发，都需要分别对待，这样维护量和开发量将会加大。而经过修改后，可把区别只控制在开发阶段，在线升级时，可以按照一个软件来通过串口或网口来进行升级。通过对bootrom最后生成文件大小的控制，可以简化生产流程，加快生产进度。

3 小结

在嵌入式操作系统中进行程序开发，需要经常开辟新的思路，以一些简单的实现方式代替复杂易错的方式。在本次产品开发过程中，将bootrom映像生成方式由惯用的GNU make命令行实现，修改为按照新建工程的方式来实现，是一个相对好的方法，对整个产品的后续批量生产、用户维护和后续开发都奠定了一个良好的基础。

上一页  [1] [2]