|
引言 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系統開發打下基礎。 參考文獻 1. 李駒光 嵌入式Linux開發詳解--基于EP93XX 系列ARM 2006 2. 王京起.黃健.沈中杰 嵌入式可配置實時操作系統eCos技術及實現機制 2005 3. Massa Anthony J Embedded Software Development with eCos 2006 4. 查看詳情 作者：天合導航通信技術有限公司 李志訓 來源：《單片機與嵌入式系統應用》 2009 （7） |
