引 言
eCos(embedded Configurable operating system)最初是由Cygnus Solutions公司为面向嵌入式领域而开发的实时操作系统,源码公开,具有很强的可移植性和可配置性,适合于嵌入式开发。现在eCos主要由 eCosCentric公司和eCos开源社区共同开发维护。eCos的特性,特别是它的可配置性,能有效缩短嵌入式产品的开发周期并降低成本。
RedBoot(Red Hat Embedded Debug and Bootstrap)是一个由Red Hat公司开发的可以在嵌入式系统上独立运行的引导程序。它是目前嵌入式领域功能最强大、可移植性最好的BootLoader之一,采用eCos环境开发,并以eCos的硬件抽象层作为基础,但完全可以脱离eCos环境运行,可以用来引导任何嵌入式操作系统,如Linux、WinCE等。
SmartARM2200开发板使用NXP公司的LPC2210微处理器。LPC2210基于ARM7TDMI-S内核,系统时钟频率达60 MHz,总线对外开放,宽度可配置为8/16/32位。同时开发板还扩展了RTL8019AS(10 Mb/s)以太网控制器。本文将介绍SmartARM2200的移植方法,给其他以ARM为内核的eCos底层移植开发提供参考。
1 硬件抽象层HAL介绍
硬件抽象层HAL对处理器结构和系统硬件平台进行抽象,当要在一个新的目标平台上运行RedBoot或eCos时,只需对硬件抽象层进行相应修改,便可迅速地将RedBoot及整个eCos系统移植到新的平台上。硬件抽象层主要包括三大模块——体系结构抽象层(Architecture HAL)、变体抽象层(VarJant HAL)和平台抽象层(Plat-form HAL)。体系结构抽象层主要是指eCos所支持的具有不同体系结构的处理器系列,如ARM系列、PowerPC系列、MIPS系列等等。变体抽象层指的是处理器系列中某款处理器在Cache、MMU和FPU等方面具有的特殊性。平台抽象层则是对当前系统硬件平台的抽象,包括了平台的启动、芯片选择与配置、定时设备、I/O寄存器访问以及中断寄存器等等。平台抽象层代码的编写是Red-Boot及eCos移植工作的重点。
2 HAL移植的主要步骤
建立适当的文件目录或从eCos的硬件配置包中选择1个与准备移植的目标平台(本文中即SmartARM2200)类似的硬件平台的HAL实现,然后根据自己目标系统的硬件特征,进行相应的修改。选择的硬件平台与目标系统硬件的相似程度决定了移植工作量的大小,相似程度越高,所需的修改也就越小。
本例拷贝了olpce2294的模板(可以在NXP网站获得相关的补丁,是eCos-1.0下的),以此为基础修改,主要区别如表1所列。
移植工作的重点也就放在表中所列的这几部分。
eCos本身有一个完整的文件目录,只有把新建的底层文件放在适当的文件目录下面,才能确保配置和编译工作的成功,也有助于利用eCos本身已有的源代码,如结构体系层和变体层中的许多成熟可用的代码。由于本系统中SmartARM2200处理器的内核是ARM7,因而可以把SmartARM2200的目录建立在eCos库路径paekages/hal/arm/lpc2 XXX/下。
(1)修改SmartARM2200的cdl文件
根据SmartARM2200开发板的硬件特征对复制的HAL实现文件作相应修改,涉及的修改主要是对各配置包内文件名的修改和对配置包内.cdl文件修改。cdl文件是用组件描述语言(Component Description Language,CDL)编写的脚本文件,eCos的每一个配置包中,都至少存在一个CDL脚本文件来对该配置包进行描述,配置工具也是通过该文件与配置包联系起来。因此,对cdl文件的修改也主要是对配置包的名称和文件名进行修改,使之与目标系统硬件相联系。
以下是SmartARM2200的cdl文件中关键的修改:
(2)在eCos数据库中添加SmartARM2200目标平台
需要在/opt/ecos/ecos_2.0/packages目录的数据库文件ecos.db中添加SmartARM2200目标平台,Smart- ARM2200平台才能被添加到配置工具中,并进行配置和编译处理。数据库文件ecos.db也是使用CDL语言编写的,在ecos.db中需要添加两部分内容,可以根据相似硬件平台在ecos.db的内容进行修改。
在ecos.db添加基于SmartARM2200硬件平台的示例代码见本刊网站。
(3)修改平台抽象层的有关代码
硬件平台层所需编写的代码文件的一般功能如下:include/plf_io.h,I/O定义和系统寄存器的宏定义。include/hal_platform_setup.h,平台启动代码。本文件主要用ARM汇编指令编写,实现平台上电后程序的启动和执行。
src/smartarm2200_misc.C,HAL的底层扩展函数,包括LCD的相关函数及控制台初始化函数。
var/v2_0/include/包括hal_cache.h、hal_diag.h、hal_var_ints.h、lpc2xxx_misc.h、 plf_stub.h、var_arch.h、var_io.h等头文件,定义了标准函数接口及通用I/O和寄存器。
var/v2_0/src/lpc2xxx_misc.C,HAL的底层标准函数,包括时钟平台初始化、时钟延时函数、中断使能、中断屏蔽、中断响应等。
var/v2_O/src/hal_diag.c,硬件抽象层诊断输出函数,包含eCos系统中printf打印的硬件设备驱动程序。
misc/redboot_RAM.ecru,基于RAM启动方式的RedBoot最小配置文件。
misc/redboot_ROM.ecm,基于ROM启动方式的RedBoot最小配置文件。
3 硬件启动过程
编写硬件启动的初始化过程是HAL移植的一个难点。当硬件重新上电后,系统的程序指针会自动指向地址0(通常地址0存放着bootloader代码段,本例中从外部Flash 0x80000000地址引导)。在eCos操作系统中,程序首先会运行vectors.S文件(该文件存在于hal/arm/arch/src/目录下),它定义了reset_vector、start等各种启动标号。接着调用SmartARM2200平台层的hal_platform_setup. h文件中的宏platform_setupl。
haLplatform_setup.h定义了宏platform_setupl以供vectors.S调用。该宏定义了目标板上SRAM和Flash的初始化启动,其中包括了它们的总线宽度、读写速度、内存大小。然后根据不同的启动方式执行程序。对于RAM启动方式,无需进行程序段与数据段的搬移,系统已认为SRAM的起始地址即为程序的起始地址;对于ROM启动方式,需要拷贝数据段,而程序段无需拷贝。
在程序拷贝完成后,系统会进行其他硬件的初始化过程,包括系统时钟、监控串口等基本硬件设备。
4 内存布局文件编写
平台的内存布局文件在include/pkgconf目录下。通常,每个平台包括了RAM、ROM两种不同启动方式的内存布局文件集。每种启动方式的内存布局文件集都由3个类型的描述文件组成:.h文件包含内存域的C宏定义;.ldi文件定义内存域和内存段位置的链接脚本文件;.mlt文件包括由MLT工具产生的对内存布局的描述。当需要手动修改内存布局时,只有.h和.ldi文件可以被修改,.mlt文件只能由MLT工具生成。
下面以SmartARM2200的RAM启动方式内存布局为例,说明mlt_arm_lpc2xxx_smartarm2200_ram.h和mlt_arm_lpc2xxx_smartarm2200_ram.ldi的程序结构。
由于SmartARM2200的开发板有1个16 KB的内部RAM和1个16 MB的外部SRAM,因而要定义两个内存域ram0和ram。系统设置寄存器在初始化时已经把内存段重新映射,因而两个SRAM的基地址就是 0x40000000和0x81000000,分配方式都是可读写的内存段。
在mlt_arm_lpc2xxx_smartarm2200_ram.ldi中分为两大部分。首先是MEMORY部分,它定义了在RAM启动方式下所需要的内存域,以及该内存域的起始地址和长度。MEMORY部分的内容必须与mlt_arm_lpc2xxx_smartarm2200_ram.h中定义的宏相一致。其次,是SECTIONS部分,它定义了RAM启动方式下所规定的内存段,这些内存段的定义与系统内存管理功能有关。在 SECTION_XXX后带有相应的参数,这些参数包括了内存段所属的内存域、起始地址(或者是对齐方式)、虚拟内存地址(VMA)和加载内存地址 (LMA)。
以SECTION_fixed_vectors(ram,0x81000000,LMA_EQ_VMA)为例,它表示fixed_vectors段属于 ram内存域,起始地址为0x81000000,加载内存地址等于虚拟内存地址。LMA_EQ_VMA同时也可以解释为该内存段不需要在程序运行后重新分配加载。
5 驱动程序的移植
SST39VF1601的驱动是在SST39VF400的拷贝的基础上修改的,主要改动部分如下:
RTL8019AS的驱动是在NS的DP89302A(都兼容NE2000)的拷贝基础上修改的,应该重点注意的是寄存器地址应该乘以2(因为地址线是从 A1开始的),由于该地址总线上还有LCD模块,为了两者能同时工作,总线宽度设置为16位,RTL8019AS的寄存器是8位的,写入和读取函数定义为 8位的,数据的读写视工作在8位DMA或16位DMA而定。
6 调试结果
SmartARM2200开发板上带有1块2 MB的Flash和1块16 MB的SRAM。
利用eCos的自带编译工具configtool对新建的SmartARM2200目标板进行编译,生成RedBoot的目标文件。然后通过AXD下载到目标板的SRAM中运行。此时的RedBoot应为RAM启动方式。刚开始调试的难度有点大,因为AXD不支持elf文件的下载,有些目标文件可以通过 objdump反汇编对照调试。
通过对RedBoot的常用命令的测试结果可以看出,本文提供的SmartARM2200的移植方案是成功的,ping命令正常,tftp下载正常。
结 语
RedBoot和U-boot都是优秀的bootloader程序,但RedBoot比U-boot的可移植性好。通过对RedBoot的移植可以熟悉 eCos系统的开发环境、configtool图形化配置工具、硬件抽象层HAL及驱动的移植,为进一步eCos系统开发打下基础。