适于OMAP的多级启动Boot Loader

开放式多媒体应用平台（OMAP）是TI公司推出的，适用于下一代嵌入式终端设计的高集成度双核心处理器。它将一颗善于进行数据处理的DSP内核与一颗控制性能很强的ARM内核集成在一个芯片中，既改进了普通DSP处理器缺乏外部控制能力的缺点，也弥补了普通ARM处理器无法进行大运算量数据处理的不足。与单核心处理器相比，OMAP双核结构处理器能够完成以前需要两颗处理器才能完成的工作，可以得到更低的系统功耗与成本，因而广泛应用于嵌入式终端中。
    Boot Loader是嵌入式系统的重要组成部分，它是在操作系统启动之前运行的初始化加载程序，用于设置操作系统运行的硬件环境并将Flash中存储的操作系统加载到RAM中运行。
1 OMAP的启动方式
　OMAP多采用外部Flash启动方式。以OMAP5910为例，它包含一颗TMS320C55x DSP核心以及一颗ARM925核心,其中MPU（ARM925）为主控核心,它可以控制DSP内核的启动、复位等操作。OMAP5910上电时，MPU首先启动，从地址0x00000000开始读取指令，运行程序。一般应在0x00000000地址处放置一条跳转指令，令其指向Boot Loader启动程序的入口处，OMAP5910启动后跳转至Boot Loader程序处执行硬件环境设置及操作系统加载工作。根据OMAP5910的地址空间映射关系[1]，0x00000000地址属于EMIFS（慢速片外存储器接口）总线，CS0空间，用于连接外部Flash，因而OMAP5910的启动阶段的程序在外部Flash中进行取指操作。
　在实际应用中发现，如果操作系统占用空间比较大，使得Boot Loader需要从Flash中拷贝的代码量很大，那么系统的启动过程会耗费较长的时间。由于MPU需要在Flash中取指，又要将同一空间中其他部分的数据搬移到不同的RAM（DSP运行的内部SRAM以及MPU运行的SDRAM）中，从而使得程序取指错误的概率增加。经过测试发现，随着Flash擦写次数的增多，Flash性能下降，这种错误的概率会显著增加。这种错误体现到应用中，就会造成整个系统在启动过程中偶尔出现莫明其妙的死机，只能通过断电重新启动才能解决，因而这种启动方式存在较大的隐患。
2 多级启动Boot Loader
2.1 设计思想
   考虑到启动过程中MPU需要从Flash中取指，这种操作既有风险且取指周期又长，因而应尽量减少在Flash中的取指动作。而RAM作为高速存取设备，其读写周期比Flash要短得多，因而将代码拷贝过程中的指令放到RAM中进行取指操作，既能降低取指周期，又能降低载入系统时的风险。通过上述分析，可以设计一种多级载入的BOOT过程，首先用一段尽量短的程序将传统意义上的Boot Loader拷贝到一段空白（载入操作系统时不会占用）的RAM中，之后再跳转到RAM中的Boot Loader程序入口，执行真正的Boot Loader程序。与操作系统相比，Boot Loader程序代码要短得多，拷贝时间基本可以忽略，因而运行风险也小很多。这段程序在Flash中运行，任务是拷贝Boot Loader程序，可以称之为Mini Loader。
2.2 具体过程
   多级Boot Loader启动过程分为Mini Loader、System Loader以及Flasher 3个部分。
   (1) Mini Loader
   Mini Loader在Flash中运行，其目的是从Flash中将Boot Loader程序拷贝到RAM中。为了尽量减小Flash中运行程序的数量就需要Mini Loader尽量短小，故而Mini Loader在进行拷贝动作之前只需要配置与外部总线EMIFS、EMIFF相关的寄存器。具体流程如图1所示。同时还要注意需要设置MPU的中断向量表0x00000000的跳转地址为Mini Loader的程序入口。

    (2) System Loader
    该部分为传统意义上的Boot Loader过程，完成硬件环境相关设置及初始化，并将操作系统载入到RAM中运行。需要注意的是,MPU本身的中断向量表须载入到内部SRAM中，其他操作系统部分可以载入到外部SDRAM中。
　由于OMAP平台为双核心结构，因此 System Loader除了需要载入MPU系统本身之外，还需要配置DSP的载入及启动过程。DSP有3种启动方法:Flash引导方式与ARM载入方式，参考文献[2]对这两种方式进行了对比分析。本设计采用ARM载入方式，这样可以通过ARM动态配置DSP部分的代码，控制DSP核心的处理流程。与参考文献[2]所不同的是，本方法中DSP程序采用与MPU操作系统相同的方式存储，也存入Flash中，而不是作为常量数组编入Boot Loader程序中，这种方式较参考文献[2]中的方法更加便于管理，单独对DSP程序进行升级也更加方便，而且减小了System Loader的程序长度，更有利于多级启动方式。
　因为OMAP本身的GPIO（MUPIO）有限，所以大多设计都要采用FPGA作为外围扩展控制器，用来扩展更多的控制端口以及通信端口。一般FPGA本身无法存储程序，其程序存储在片外ROM中，FPGA上电之后可以通过多种方式自行加载到ROM中运行。本设计通过MPU加载FPGA程序，并将FPGA固件程序也存储于同一Flash中，这样省去了一片FPGA专用ROM，既方便代码管理，又降低了硬件成本和设计复杂度。以XILINX公司的XC2S系列FPGA为例，其加载程序时可采用串行加载模式，选择FPGA为从模式，将OMAP本身的MCBSP配置为SPI主模式，工作于时钟停止模式，包含一个时钟周期延时，输出时钟信号高有效，采用帧同步模式，每个数据帧8 bit。给FPGA载入程序时，要将存储于Flash中的FPGA程序代码读出，由于XILINX开发工具ISE输出的HEX文件以字节（8 bit）为单位，而Flash中存储的内容以双字（32 bit）为单位（由ARM指令长度而定），因而从Flash中读出32 bit的数据之后需要按照从高到低的字节顺序发送。而且，ISE的HEX文件每字节bit排列顺序与MCBSP的传输顺序正好相反，因此每个字节内部需要将bit反向重排。
　System Loader流程如图2所示，启动顺序与本小节所述顺序正好相反，这是因为FPGA一般多用于进行硬件设备的控制，所以需要最先启动；而DSP由于其自身特点，多用于数据处理工作，作为MPU的协处理器使用，因此需要在MPU操作系统启动之前做好准备。

  [!--empirenews.page--] (3)Flasher
　Flasher过程主要负责向Flash中烧写编译好的程序目标码，主要包括Boot Loader、MPU、DSP、FPGA等部分。采用RS232串行端口与主机相连，实现程序目标码的下载。传输协议采用大多数编译器都支持的Intel Hex格式[5]。Intel Hex格式采用ASCII字符表示方式，这样程序目标码的每个字节需要用2个ASCII字符来表示，包含冗余信息较大，而且Intel Hex格式仅含目标码的地址信息与具体内容，而无法区分目标码的类别,因而需要对Intel Hex进行扩展，以降低冗余并支持更多的操作。扩展的Hex不使用ASCII字符，而直接使用原数据格式，这样可以降低一半数据量。为了与Intel Hex格式有所区分，采用“；”作为前缀标识，格式如表1所示。同时对数据类型进一步扩展，用以区分各种目标码类别，如表2所示。

   可以看出，表2中仅包括擦除各种类型目标码的指令，而没有包含写入目标码时区分类别的具体指令，这是因为写入时各种不同类型的目标码可以直接通过地址来区分，每种类型目标码都有自己单独的地址段，相互之间没有交叉。Flasher流程如图3所示，通过解析Hex记录格式，来判断命令类型，从而进行相应的操作。其中校验模式用于验证Flash中所存储的程序代码是否与串行端口上收到的数据一致。所有程序更新结束之后，通过重新启动命令复位OMAP芯片，使整个系统重新启动。   

    　　
3 拷贝程序耗时对比测试
   采用Intel公司RD48F3000P0ZBQ0 Flash存储器以及三星K4M56163PG移动版SDRAM与OMAP5910相连，组成OMAP5910运行所需的最小系统，OMAP运行频率144 MHz。分别采用传统启动方式（程序在Flash中运行）以及本文所述的启动方式（程序在RAM中运行）从Flash中拷贝相同长度的数据到SDRAM中，测试其耗时。每次拷贝数据量选取64 KB～8 192 KB，每种数据量每种方式测试5次，具体时间如表3所示，其中表3（a）为程序在RAM中运行时的耗时，表3（b）为程序在Flash中运行时的耗时。由表中数据对比可以看出，拷贝数据量较大时，本文中所述的RAM拷贝方式优势比较明显，有大约20％的提高，对于目前的嵌入式操作系统来说，基本内核的代码量都比较大，因而采用本文所述的方式能够带来比较大的耗时改善。

　OMAP作为一种整合了ARM控制能力与DSP数据处理能力的双核心处理器已经广泛应用于各种嵌入式设备中，但大多数OMAP处理器通过外部Flash启动，既浪费时间又有较高风险。本文针对OMAP启动过程中的这一缺陷，设计的多级启动Boot Loader较之传统方式有较大的性能改善，目前已在数字集群手持终端、网络多媒体可视电话等项目中得到成功应用，并取得很好的效果。