苗　軍　倪奇志

摘 要：在基于TI DSP的嵌入式應(yīng)用系統(tǒng)中，升級(jí)文件提取方法的效率和易用性對(duì)于DSP升級(jí)來說特別重要，傳統(tǒng)的提取方法耗時(shí)且容易出錯(cuò)，為此迫切需要一種快速且可靠的方法。由于DSP編譯器最終輸出的可執(zhí)行代碼是一種COFF格式的文件，具有結(jié)構(gòu)化、分層次的特點(diǎn)，可以剔除其中與最終下載代碼無關(guān)的大量冗余信息。為此提出一種基于可執(zhí)行文件本身結(jié)構(gòu)特點(diǎn)的方法，只提取出與下載相關(guān)的數(shù)據(jù)。實(shí)踐證明這種方法高效、可靠、靈活易用。此提取器摒棄傳統(tǒng)方法的缺陷，為DSP在研發(fā)生產(chǎn)中的快速自動(dòng)升級(jí)提供了可靠保證。

關(guān)鍵詞：COFF；段；DSP；冗余信息

中圖分類號(hào)：TP311文獻(xiàn)標(biāo)識(shí)碼：B

文章編號(hào)：1004 373X(2009)02 042 03

Realization and Applicotion of COFF File Extraction Equipment

MIAO Jun,NI Qizhi

(ZTE Corp.Ltd.,Shenzhen,518057,China)

Abstract：In the embedded system based on TI DSP,it is very important to improve the efficiency and usability of updating file extraction.More time is needed and mistakes are always made in traditional way.So an efficient and reliable method is needed.TI DSP compiler outputs executable file which is a file of COFF format.The file is structured and hierarchical,with much redundant information that is not useful for downloading.A method based on the structure of executable file that only the useful data can be extracted.It is proved that this method is efficient,flexible and easy to use.This file extraction resolves the disadvantages of the traditional way,and ensures that DSP can be updated quickly and automatically for R&D; and production.

Keywords：COFF;section;DSP;redundant information

在基于DSP的嵌入式系統(tǒng)中，軟件更新通常需要借助仿真器將最新的可執(zhí)行程序下載到目標(biāo)板上，然后提取出可執(zhí)行二進(jìn)制程序并寫入非易失存儲(chǔ)器中?；蛘唠x線進(jìn)行二進(jìn)制文件的提取，然后再由DSP自己或主機(jī)芯片完成文件的燒結(jié)。在此，有必要簡(jiǎn)單介紹一下TI DSP可執(zhí)行程序(目標(biāo)文件)的結(jié)構(gòu)。TI代碼產(chǎn)生工具CCS在經(jīng)過編譯、鏈接之后，產(chǎn)生的目標(biāo)文件是一種模塊化的文件格式——COFF格式。程序中的代碼和數(shù)據(jù)在COFF文件中是以段的形式組織。在此基礎(chǔ)上，再來討論上面兩種方法的弊端。前者只要程序有變化，就會(huì)造成新生成目標(biāo)文件各段的大小和運(yùn)行地址的變化，其系統(tǒng)引導(dǎo)程序也需要作相應(yīng)的改動(dòng)。如果需要對(duì)大量的DSP系統(tǒng)進(jìn)行軟件更新或經(jīng)常需要軟件更新的情況下，這種方法的效率非常低下，缺乏靈活性。后者的通常做法是先用工具軟件hex6x先將編譯器生成的目標(biāo)文件轉(zhuǎn)換成多個(gè)TI格式的.hex文件，再逐一分析.hex文件，手工去掉其中的一些標(biāo)志信息，并根據(jù)需要對(duì)文件進(jìn)行必要的分割合并，最后調(diào)用TI提供的工具軟件hexbin將各個(gè).hex文件轉(zhuǎn)換成二進(jìn)制文件，生成文件的數(shù)目隨應(yīng)用而變化。這種方法因?yàn)樯婕暗绞止げ僮髻M(fèi)時(shí)費(fèi)力不說且很容易出錯(cuò)。同樣也存在著靈活性差的弊端，遇到有大量增減以及配置文件有修改的時(shí)候就會(huì)導(dǎo)致生成文件數(shù)目的增減，需要修改DSP或主機(jī)boot程序以適應(yīng)這種改變。通過對(duì)目

標(biāo)文件結(jié)構(gòu)的分析，可以直接提取可供下載的二進(jìn)制文件。

1 目標(biāo)文件結(jié)構(gòu)分析

DSP的源程序——C代碼或匯編代碼在編譯后生成的COFF文件包含多個(gè)段，默認(rèn)的情況下，COFF文件包含3個(gè)段：.text: 通常包含可執(zhí)行代碼；.data: 通常包含已初始化的數(shù)據(jù)；.bss: 通常為未初始化的數(shù)據(jù)保留空間。

當(dāng)然匯編器和鏈接器允許自己建立和鏈接自定義的塊，這些塊與以上的3個(gè)段類似。所有的段分為兩大類：已初始化段和未初始化段。這兩類段的最大區(qū)別就在于是否出現(xiàn)在加載文件中。

下面來分析COFF文件的結(jié)構(gòu)，COFF文件從上到下中依次是文件頭、可選的文件頭、段頭信息表、段頭信息表對(duì)應(yīng)的段數(shù)據(jù)、重定位信息、行號(hào)入口表、符號(hào)表、字符串表，如圖1所示。其中第3~6項(xiàng)包含多個(gè)數(shù)據(jù)區(qū)，前4項(xiàng)與加載文件密切相關(guān)。

由于前4項(xiàng)與加載文件相關(guān)，下面對(duì)這4項(xiàng)逐一分析一下：

(1) 文件頭：顧名思義，就是COFF文件的頭，用來保存COFF文件的基本信息，如段數(shù)目、時(shí)間戳、符號(hào)表位置等。從文件的0偏移處開始，用C的結(jié)構(gòu)描述如下：

typedef struct{

unsigned short usMagicNumber;// 魔法數(shù)，標(biāo)識(shí)COFF文件的版本也即平臺(tái)標(biāo)識(shí)

unsigned short usSectionCounter;// 段頭數(shù)目

unsigned intuiTimeStamp;// 時(shí)間戳，COFF文件生成時(shí)間

unsigned intuiSymbolPointer; // 符號(hào)表入口基地址，采用絕對(duì)地址

unsigned intuiSymbol; // 符號(hào)表入口數(shù)目

unsigned short usOptHdrSize;// 可選文件頭長(zhǎng)度。如果有此值為28，否則為0

unsigned short usFlags; // 文件標(biāo)記

unsigned short usTargitID; // 目標(biāo)文件標(biāo)記。若為0x0099，目標(biāo)文件能在C6x平臺(tái)上運(yùn)行

} FileHeader;

文件頭中的標(biāo)記包含了諸如大小端模式、COFF是否為可執(zhí)行文件等信息，具體解釋見參考文獻(xiàn)［1］。

(2) 可選頭：

可選頭接在文件頭的后面，也就是從COFF文件的0x0014偏移處開始。長(zhǎng)度可以為0。不同平臺(tái)的可選頭，長(zhǎng)度和結(jié)構(gòu)都不相同，TI DSP采用的可選頭長(zhǎng)度為28 B，用C的結(jié)構(gòu)描述如下：

typedef struct {

unsigned shortusMagicNumber; // 魔法數(shù)，標(biāo)識(shí)文件類型

unsigned shortusVersion; // 版本標(biāo)識(shí)

unsigned int uiTextSize; // 代碼段大小，以byte計(jì)

unsigned int uiInitDataSize;// 已初始化數(shù)據(jù)段大小，以byte計(jì)

unsigned int uiUninitDataSize; // 未初始化數(shù)據(jù)段大小，以byte計(jì)

unsigned int uiEntry; // 入口點(diǎn)

unsigned int uiTextBase;// 代碼段(.text)基址

unsigned int uiDataBase;// 已初始化數(shù)據(jù)段基址

} OptinalHeader;

(3) 段頭：

段頭緊跟在可選文件頭的后面（如果可選文件頭的長(zhǎng)度為0，它緊跟在文件頭后），一般COFF包含多個(gè)段頭，數(shù)目就是文件頭中的usSectionCounter。它的長(zhǎng)度為48 B，用C的結(jié)構(gòu)描述如下：

typedef struct {

charcName［8］; // 段名，長(zhǎng)度大于8則為指向符號(hào)表的指針

unsigned int uiPhyAddr; // 段的物理地址

unsigned int uiVirtAddr; // 段的虛擬地址，目標(biāo)運(yùn)行地址

unsigned int uiSecSize; // 段長(zhǎng)度，以byte計(jì)

unsigned int uiSecPointer;// 段數(shù)據(jù)指針

unsigned int uiRelPointer;// 段重定位表指針

unsigned int uiLNOffset; // 行號(hào)表指針

unsigned intuiRelSize; // 重定位表長(zhǎng)度

unsigned intuiLNSize; // 行號(hào)表長(zhǎng)度

unsigned intuiFlags;// 段標(biāo)識(shí)

unsigned short usReserved; // 保留字段

unsigned short usMmPageNum; // 內(nèi)存頁號(hào)

} SectionHeader;

段頭可以說是最重要的頭，文件分析提取器的核心就是用它來描述它的。一個(gè)COFF文件可以不要其它的節(jié)，但文件頭和段頭這兩節(jié)是必不可少的。有必要詳述一下它的成員：

cName用來保存段名，常用的段名有.text，.data，.bss等。對(duì)于用戶自定義長(zhǎng)度超過8 B的段名，則為指向符號(hào)表的指針。

uiVirtAddr是段數(shù)據(jù)載入或連接時(shí)的虛擬地址。對(duì)于可執(zhí)行文件，這個(gè)地址是相對(duì)于它的地址空間而言。當(dāng)可執(zhí)行文件被載入內(nèi)存時(shí)，這個(gè)地址就是段中數(shù)據(jù)的第一個(gè)字節(jié)的位置。大多數(shù)情況下與uiPhyAddr相同。

uiSecSize是段中數(shù)據(jù)的實(shí)際長(zhǎng)度，在讀取段數(shù)據(jù)時(shí)就由它來確定要讀多少字節(jié)。

uiSecPointer是段數(shù)據(jù)在COFF文件中的偏移量，以絕對(duì)地址標(biāo)識(shí)。

uiRelPointer是該段重定位信息的絕對(duì)地址，它指向了重定位表的1個(gè)記錄。

uiLNOffset是該段行號(hào)表的絕對(duì)地址，它指向的是行號(hào)表中的1個(gè)記錄。

uiRelSize是重定位信息的記錄數(shù)，從uiRelPointer指向的記錄開始，到第ulNumRel個(gè)記錄為止，都是該段的重定位信息。

uiLNSize和uiRelSize相似，不過它是行號(hào)信息的記錄數(shù)。

uiFlags是該段的屬性標(biāo)識(shí)，與下載相關(guān)的標(biāo)識(shí)如表1所示。

其余定義請(qǐng)見參考文獻(xiàn)［1］。

(4) 段數(shù)據(jù)：

保存各個(gè)段的數(shù)據(jù)，在目標(biāo)文件中這些數(shù)據(jù)都以原始數(shù)據(jù)(Raw Data)形式存在，只有需要下載的數(shù)據(jù)段才存在該區(qū)域。

2 COFF文件分析提取器的工作流程

首先讀入目標(biāo)文件，該文件擴(kuò)展名為out，以二進(jìn)制形式讀入。分析.out文件的文件頭以確定有多少個(gè)段，然后逐段分析段信息頭，根據(jù)段屬性標(biāo)識(shí)以確定是否需要下載，段頭中的絕對(duì)地址、段數(shù)據(jù)長(zhǎng)度等信息作為升級(jí)文件的一部分。與需下載的段數(shù)據(jù)合并成最終的下載文件，為了適應(yīng)自動(dòng)化升級(jí)的需要，下載文件頭部還保留了COFF文件的時(shí)戳。值得注意的是因?yàn)門MS320C6000 DSP為32位處理器，需要對(duì)段落頭中段數(shù)據(jù)長(zhǎng)度信息進(jìn)行32位整型對(duì)齊，在此采用Ceil對(duì)齊不足的字節(jié)以0補(bǔ)齊。具體流程如圖2所示。

而COFF文件中的重定位信息、行號(hào)入口表、符號(hào)表、字符串表等數(shù)據(jù)區(qū)，對(duì)于下載文件的制作沒有直接聯(lián)系，可以不做分析。當(dāng)然，如果在PC上制作可視化工具的話，另當(dāng)別論，限于篇幅在此不做討論。

3 COFF文件分析提取器的應(yīng)用

開發(fā)的DSP應(yīng)用系統(tǒng)一般采用HOST－SLAVE模式，即DSP是作為系統(tǒng)的信號(hào)處理協(xié)處理單元，HOST保存有所有處理器的下載文件。COFF文件分析提取器在做離線使用時(shí)，提取出的下載文件由HOST負(fù)責(zé)保存、上電加載。HOST的引導(dǎo)程序在上電時(shí)讀取已經(jīng)構(gòu)建好的二進(jìn)制文件，根據(jù)段數(shù)目、每段大小以及目標(biāo)數(shù)據(jù)的下載地址等相關(guān)信息即可完成對(duì)目標(biāo)代碼的自動(dòng)下載。COFF文件分析提取器在線使用時(shí)，時(shí)間戳就作為版本是否更新的依據(jù)，HOST一旦偵測(cè)到版本服務(wù)器有新版本的COFF文件并得到用戶升級(jí)確認(rèn)后，就可啟動(dòng)文件提取器。

目前，這種利用COFF文件分析提取器生成DSP下載文件的方式，已經(jīng)在中興通訊多個(gè)產(chǎn)品線廣泛應(yīng)用，大大提高了產(chǎn)品的可測(cè)試性和易維護(hù)性。

4 結(jié) 語

在此討論的方法基于對(duì)COFF文件結(jié)構(gòu)的分析，讀取DSP編譯器生成的.out文件，根據(jù)文件本身攜帶的信息，直接提取生成可供下載的二進(jìn)制文件。最終生成的二進(jìn)制文件中包含有與.out文件相同的信息，在下載時(shí)利用這些信息即可完成對(duì)DSP芯片的加載。

參考文獻(xiàn)

［1］Texas Instruments.TMS320C6000 Assembly Language Tools User′s Guide［Z］.2003.

［2］Texas Instruments.TMS320C6455，F(xiàn)ixed－Point Digital Signal Processor［Z］.2006.

［3］Texas Instruments.TMS320DM642 Video/Imaging Fixed－Point Digital Signal Processor Data Manual［Z］.2004.

［4］Texas Instruments.TMS320C645x DSP Host Port Interface(HPI) User′s Guide［Z］.2007.

［5］Texas Instruments.TMS320C645x Bootloader User′s Guide［Z］.2007.

［6］Texas Instruments.Extracting Equivalent Hex Values from a COFF File［Z］.1999.

［7］Texas Instruments.Using OFD Utility to Create a DSP Boot Image［Z］.2004.

［8］Texas Instruments.TMS320C6000 Host Port to MPC860 Interface［Z］.2001.

［9］Texas Instruments.Using the TMS320C672x Bootloader［Z］.2005.

［10］Texas Instruments.TMS320C6000 Tools:Vector Table and Boot ROM Creation［Z］.2002.

［11］Texas Instruments.Creating a Second－level Bootloader for FLASH Bootloading on TMS320C6000 Platform with Code Composer Studio［Z］.2004.

作者簡(jiǎn)介 苗 軍 男，1971年出生，四川綿陽人，高級(jí)工程師，現(xiàn)在中興通訊股份有限公司從事DSP軟件系統(tǒng)設(shè)計(jì)。

倪奇志 男，1974年出生，漢族，安徽桐城人，碩士，現(xiàn)在中興通訊股份有限公司從事會(huì)議電視硬件系統(tǒng)設(shè)計(jì)。