3.4 VxWorks BSP文件組成

BSP是Board Support Packet的簡稱，即板級支持包，主要由平臺初始化代碼文件、外設驅動文件構成。當然，這主要是從BSP開發人員實際所需工作的角度而言的。實際上，BSP開發人員真正要完成的是VxWorks操作系統向特定平臺的移植工作。這些工作除了包含平臺初始化代碼和外設驅動代碼的編寫外，還需要關心其他一系列文件并理解這些文件的功能，如此當出現相關問題時，可以快速定位問題的所在。本節從VxWorks操作系統移植的角度詳細介紹一個典型BSP的文件構成以及文件具體的功能。

一個典型BSP的文件組成有如下類型：

● 源文件。

● 頭文件。

● Makefile文件。

● 擴展文件（編譯過程中生成的文件，如.o文件）。

● 說明文件（可選）。

其中，源文件和頭文件主要存在于target/config目錄下，這是源文件和頭文件包括內核提供的以及由BSP開發人員提供的文件；Makefile文件指target/config/<bspName>以及target/h/make目錄下的文件，<bspName>下的Makefile是屬于某個特定BSP工程的文件，而target/h/make目錄下的相關文件被所有的BSP工程使用；擴展文件指編譯過程中生成的文件，這部分文件主要存在于<bspName>目錄下；說明文件指存在于<bspName>目錄下說明BSP信息的相關文件。

對于源文件和頭文件，需要另外說明的一點是，除了target/config目錄下的文件，內核提供（安裝Tornado開發環境時安裝的文件）的源文件主要存在于target/src目錄下，而內核頭文件則存在于target/h目錄下。BSP開發人員在進行相關代碼的查看時，可以到這些目錄下去尋找。注意：禁止對內核源文件和頭文件進行修改。BSP開發主要是修改和完善target/config目錄下相關的源文件和頭文件。

安裝Tornado開發環境時，BSP是作為一個產品獨立進行安裝的，這是由Wind River公司針對一些平臺提供的官方BSP，如integrator946es，前文中<bspName>就表示一個特定BSP的目錄名稱，可以使用任何對用戶有意義的名稱作為<bspName>。

3.4.1 源文件

Tornado開發環境安裝完成后，在target/config目錄下就包含由官方提供的一些BSP以及共用目錄All，BSP開發人員一般復制一個近似平臺的BSP，對其中的文件進行修改以及添加一些文件來開始BSP的開發過程，不要從零開始創建BSP，如此可以大大縮短BSP的開發時間，降低開發難度。target/config/all目錄被config目錄下所有的BSP使用，這個目錄下的文件被所有的BSP使用，所以不要直接修改其中的文件。下文將介紹在修改all目錄中的文件時如何進行處理。target/config/all目錄下定義有如下源文件，所有這些都是BSP的一個組成部分。

① bootConfig.c。只被bootrom使用，VxWorks內核則使用usrConfig.c文件。

② usrConfig.c。只被VxWorks內核使用，bootrom則使用bootConfig.c文件。

③ bootInit.c。其中包含romStart函數定義，該函數（romStart）將被romInit函數調用，負責將代碼從ROM復制到RAM中。對于壓縮映像，在復制過程中，其還將完成解壓縮的工作。

④ version.c。版本信息文件。使用_DATA_和_TIME_宏來表示映像的創建時間，這些信息將在內核啟動過程中被顯示。

⑤ dataSegPad.c。當使用vxVMI組件時，該文件中的代碼確保數據段和代碼段使用不同的物理頁面，避免共享同一個頁面。該文件實現的功能在操作系統運行過程中起作用，在啟動過程中不會用到該功能。

⑥ configAll.h。該頭文件定義了一系列系統默認組件和系統常量。用戶可以打開configAll.h文件查看，即可明白該文件的意義。注意：禁止修改該頭文件，用戶可以在BSP目錄下的config.h文件中對configAll.h文件中的一些默認設置進行修改。

⑦ console.c和usrShell.c。終端交互功能支持文件。

再次提醒注意：all目錄下定義的以上這些文件被所有的BSP共享，且每個文件都是不可缺少的，該目錄下所有的文件都是由開發環境提供的，無須用戶編寫，但是在某些條件下，用戶可能需要修改這些文件中的某些代碼，以顯示針對某個特定BSP的某種機制或功能。VxWorks提供了這種修改機制，而同時又不影響其他BSP。如用戶需要修改usrConfig.c文件中的代碼，此時可從all目錄下復制一份usrConfig.c到BSP目錄下（如integrator946es），并在BSP的Makefile文件中，添加宏定義語句：BOOTCONFIG=./usrConfig.c，此時Tornado編譯環境將使用當前BSP目錄下的usrConfig.c文件作為all目錄下usrConfig.c文件的替代，即all目錄下的usrConfig.c文件將不再被這個BSP使用。當然用戶可以在復制過程中修改文件名，如將usrConfig.c改為myUsrConfig.c，則相應的宏定義就為BOOTCONFIG= ./myUsrConfig.c，只要維持BOOTCONFIG宏名稱不變，至于指定的文件名稱則不做要求，即不一定非要命名為“usrConfig.c”。

對于all目錄下的其他文件的修改類似，如對應bootConfig.c文件的BOOTCONFIG宏定義，對應bootInit.c文件的BOOTINIT宏定義。一般而言，只需要對這三個文件進行修改。

除了all目錄下的共用文件外，Tornado編譯環境還對BSP目錄下的文件提出了要求，即對于某些文件包括文件名以及文件中定義的函數都做了要求，這些文件有以下三個。

① romInit.s。

該文件定義romInit函數，該函數是整個系統啟動的入口函數，系統上電時，執行的第一行代碼就是romInit函數實現的第一條語句。基于處理器的特殊需求，一般在romInit函數實現的開始處放置一個系統異常表。可以參考arm平臺下BSP的romInit函數實現。該文件完全使用匯編代碼編寫，文件實現的功能主要完成平臺的初始化（如RAM控制器初始化、屏蔽系統中斷等），此后初始化C函數調用環境（主要指棧寄存器的初始化），調用romStart函數。romInit.s文件中一般只定義一個romInit函數，基于romInit函數特殊的執行環境（即在ROM中執行），該函數的代碼編寫必須始終保持PIC，即位置無關。實現PIC的根本原因請參考本書前文中“深入理解bootrom”章節。該文件被bootrom和ROM型VxWorks內核映像使用。

② sysALib.s。

該文件中定義了sysInit函數，該函數完成的功能類似于romInit，且sysALib.s文件只被下載型VxWorks內核映像使用。此時bootrom完成VxWorks內核映像的下載，所以romInit函數已在bootrom中被執行，故諸如RAM控制器初始化工作無須再在sysInit函數中進行，這應該可以說是sysInit函數與romInit函數實現上的一個區別，且sysInit函數是直接運行在RAM中的，所以其實現上不需要做到PIC。這兩點區別可以說是二者的不同之處，實際上可以將romInit函數實現完全復制到sysInit函數實現中，當然要刪除RAM控制器初始化的一段代碼，對于PIC，則無須關心。

③ sysLib.c。

該文件名稱必須定義為sysLib.c。換句話說，Tornado編譯環境要求BSP目錄下必須有一個文件命名為sysLib.c，且對該文件中定義的函數進一步做出了要求，即該文件必須實現一些具有指定函數名和指定功能的函數。這些函數如下。

● sysBspRev( ) - return the BSP version and revision number：返回BSP版本號和子版本號。

● sysClkConnect( ) - connect a routine to the system clock interrupt：注冊系統時鐘中斷處理函數。

● sysClkDisable( ) - turn off system clock interrupts：禁止系統時鐘中斷。

● sysClkEnable( ) - turn on system clock interrupts：使能系統時鐘中斷。

● sysClkInt( ) - handle system clock interrupts (internal)：系統時鐘中斷處理函數。

● sysClkRateGet( ) - get the system clock rate：返回系統時鐘中斷間隔時間。

● sysClkRateSet( ) - set the system clock rate：設置系統時鐘中斷間隔時間。

● sysHwInit( ) - initialize the system hardware：外圍設備初始化函數。在該函數中必須完成所有外圍設備的基本初始化工作，使得設備處于待工作狀態。注意：此階段不可進行中斷相關的任何工作，因為VxWorks內核尚未準備好中斷相關的內核管理組件。

● sysHwInit2( ) - initialize additional system hardware：所有需要中斷配合的外圍設備二次初始化函數。該函數中必須完成所有涉及中斷的初始化工作。

● sysMemTop( ) - get the address of the top of logical memory：返回VxWorks內核可用內存的最大地址值。

● sysModel( ) - return the model name of the CPU board：返回平臺CPU標識符。

● sysNvRamGet( ) - get the contents of non-volatile RAM：獲取指定NVRAM地址處的內容。

● sysNvRamSet( ) - write to non-volatile RAM：向指定NVRAM地址處寫入內容。

● sysSerialHwInit( ) - initialize the BSP serial devices to a quiescent state：串口設備初始化。該函數在sysHwInit調用期間被調用，要求如同sysHwInit函數。

● sysSerialHwInit2( ) - connect BSP serial device interrupts：串口設備二次初始化。該函數在sysHwInit2函數調用期間被調用，要求如同sysHwInit2函數。

● sysSerialChanGet( ) - get the SIO_CHAN device associated with a serial channel：獲取串口通道對應SIO_CHAN結構。

● sysToMonitor( ) - transfer control to the ROM monitor：重新熱啟動。

除了以上必需的函數外，還有一些函數是可選的，但一旦要在sysLib.c中包含這些函數，函數名和實現功能依然是固定的。這些可選函數如下。

● sysAbortInt( ) - handle the ABORT button interrupt：Abort按鍵中斷處理函數。

sysAuxClkConnect( ) - connect a routine to the auxiliary clock interrupt：輔助時鐘中斷注冊函數。輔助時鐘是指區別于系統時鐘的另一種時鐘，專用于某些特殊情況，一般無須使用。除了系統時鐘外，在硬件上必須另有一個對應的時鐘定時器對應。

● sysAuxClkDisable( ) - turn off auxiliary clock interrupts、sysAuxClkEnable( ) - turn on auxiliary clock interrupts、sysAuxClkInt( ) - handle auxiliary clock interrupts、sysAuxClkRateGet( ) - get the auxiliary clock rate、sysAuxClkRateSet( ) - set the auxiliary clock rate：函數的意義同系統時鐘，不過這些函數是針對輔助時鐘的。

● sysPhysMemTop( ) - get the address of the top of physical memory：返回物理內存的最大地址。

除了romInit.s、sysALib.s、sysLib.c三個文件必須按這些名稱命名外，還包括其他可選文件，這些文件的文件名并沒有固定的要求，但一般都有約定的名稱，故也建議用戶按約定名稱進行命名。這些可選文件如下。

● sysSerial.c：串口驅動相關代碼。

● sysScsi.c：SCSI驅動相關代碼。

● sysNet.c：局域網LAN驅動相關代碼。

以上三個文件中的代碼主要在sysHwInit和sysHwInit2函數執行期間被調用。這些文件中的代碼通過在sysLib.c文件中包括到內核映像中。例如，針對以上三個文件，可以在sysLib.c文件的某個位置中添加如下語句：

        #include "sysSerial.c"
        #include "ysScsi.c"
        #include "sysNet.c"

用戶也可從此處看出為何不對這些文件的命名加入硬性限制。

除了以上文件外，對于BSP，當然還需要特定平臺上一些外設的驅動文件，這些文件也包含了BSP目錄下，如網口驅動文件可以命名為myEndDriver.c，SPI口驅動文件可命名為mySPIDriver.c，那么此時在sysLib.c文件中加入如下語句，即可將這些驅動代碼加入內核映像中。

        #include myEndDriver.c
        #include mySPIDriver.c

除了直接在sysLib.c文件中加入以上include語句外，還可以通過Makefile中MACH_EXTRA宏定義來將某個文件代碼包含到內核映像中。如以上的例子中，還可以通過如下方式將myEndDriver.c、mySPIDriver.c文件代碼包含到內核映像中。

        MACH_EXTRA=myEndDriver.o mySPIDriver.o

3.4.2 頭文件

頭文件主要有三個：all/configAll.h、<bspName>/config.h和<bspName>/<bsp>.h，當然一些驅動文件還配有各自的相關寄存器的頭文件。

configAll.h文件是Tornado開發環境提供的，禁止對其進行修改。這個頭文件定義內核構成的所有默認選項和系統常量。如果需要修改一些默認選項，則通過config.h文件進行修改。<bsp>.h文件則是針對特定平臺寄存器地址和結構的相關定義。configAll.h和<bsp>.h文件都被config.h文件使用：configAll.h文件被config.h包含在最開始處，這一點是必需的，因為只有如此，才能通過config.h文件的后續定義改變某些選項的定義，<bsp>.h文件一般被config.h文件包含在最尾處。

上述三個頭文件中，configAll.h文件被禁止修改，<bsp>.h文件與平臺相關，只有config.h文件具有操作的靈活性。config.h文件必須包括以下功能或者定義。

① BSP版本號以及子版本ID號。

可以使用BSP_VERSION宏定義BSP版本號，如下所示。

        #define BSP_VERSION “1.2”

子版本號通過BSP_REV宏進行定義，如下所示。

        #define BSP_REV “/0”

                  char ＊ sysBspRev (void)
                        {
                        return (BSP_VERSION BSP_REV);
                        }

根據以上定義，其返回“1.2/0”字符串，這正是我們想要的結果。

② configAll.h文件。

configAll.h文件定義內核所需的一系列默認組件，特定BSP所屬的config.h文件必須以此為基礎構建VxWorks內核，故包含configAll.h文件是必需的，而且應該放在config.h文件的開始處，緊接著，版本號定義之后，因為我們需要對一些默認行為進行重新定義，故必須將組建功能的修改宏定義放在configAll.h文件之后。

③ 內存cache和MMU策略（即是否使能系統cache以及是否使能MMU）。

此處所指內存cache策略是整個系統的cache策略，是由CPU相關寄存器對所有的cache的一種全局控制。我們知道，MMU使能后具有面向頁面的cache策略控制，但是這個控制必須是在全局cache使能的情況下，如果全局cache不使能，那么無論MMU頁表項中的屬性為何，都無法達到cache的目的。內存cache策略對指令和數據分別進行控制，由USER_I_CACHE_MODE、USER_D_CACHE_MODE進行控制，如下所示。

        #undef  USER_I_CACHE_MODE
        #define USER_I_CACHE_MODE       CACHE_WRITETHROUGH
        #undef  USER_D_CACHE_MODE
        #define USER_D_CACHE_MODE       CACHE_COPYBACK

由于configAll.h文件中已經定義了默認的cache行為，故此處為了修改這個默認的行為，首先必須取消默認行為（undef語句），此后重新定義cache行為（define語句），這是config.h文件對configAll.h文件中默認行為進行修改的通用方式。

MMU機制的控制通過INCLUDE_MMU_FULL和INCLUDE_MMU_BASIC兩個宏進行控制。值得注意的是，不同版本的VxWorks內核用以控制相關行為的宏名稱并不相同。這一點在開發BSP時特別要注意，要弄清楚BSP移植所基于的VxWorks內核版本。

④ 平臺RAM基地址和大小。

涉及平臺RAM的宏定義如下。

● LOCAL_MEM_LOCAL_ADRS：平臺RAM基地址。

● LOCAL_MEM_SIZE：平臺RAM總大小。

● USER_RESERVED_MEM：在RAM頂部用戶預留的內存大小，這部分內存將排除在VxWorks內核的管理之外，即VxWorks內核將“看不到”這部分內存空間。

● RAM_HIGH_ADRS：bootrom壓縮代碼復制到RAM中的目的地址。當為非壓縮形式時，bootrom映像所有的代碼將復制到RAM_HIGH_ADRS指定的地址。

● RAM_LOW_ADRS：VxWorks壓縮代碼復制到RAM中的目的地址。當為非壓縮形式時，VxWorks映像的所有代碼（包括romInit、romStart函數）都將被復制到RAM_LOW_ADRS指定的RAM地址處。

另外一個宏用以支持RAM容量的動態改變，我們一般不使用這種工作方式，這個宏為LOCAL_MEM_AUTOSIZE。感興趣的用戶可以參考文獻“VxWorks bsp programmer’s guide”。

⑤ 平臺ROM基地址和大小。

當采取bootrom + VxWorks下載啟動方式時，bootrom將被燒錄到ROM中；或者采用ROM型VxWorks內核直接啟動方式時，VxWorks內核映像本身（一般為壓縮版本）將被直接燒錄到ROM中。可以說，ROM是系統上電后跳轉的目的地址，其中存儲著上電后運行的第一條指令。基本上所有的平臺都必須存在某種形式的ROM存儲介質。ROM是“Read Only Memory”，即只讀存儲器的簡稱，但是現今平臺上幾乎都在使用Flash替代ROM，一方面由于Flash的存儲容量大，另一方面，成本也比較低。當然Flash從工作方式上主要分為兩大類：Nor Flash和Nand Flash。為了能在其中在線執行EIP（Execute In Place），都是用Nor Flash作為啟動介質（雖然現在有號稱直接從Nand Flash啟動，但是都必須借助中間bootloader代碼，并非完全意義上的EIP，事實上，Nand Flash不可能達到真正意義上的EIP）。Nor Flash支持重新擦除后編程，編程次數可達10萬次。故使用Nor Flash作為啟動介質較為普遍，反而真正意義上的ROM基本上已經退出開發階段，可能在產品發布時，為了進一步降低成本，會使用ROM。雖然使用的是Flash，但是在定義上還是被看做是ROM，涉及相關的宏如下。

● ROM_BASE_ADRS：ROM基地址。

● ROM_TEXT_ADRS：存放啟動代碼的首地址。一般ROM_TEXT_ADRS會相對ROM_BASE_ADRS做一個偏移，以存放一些參數（如Bootline）。但是很多平臺直接將ROM_TEXT_ADRS定義為ROM_BASE_ADRS的值。

● ROM_SIZE：ROM大小。

● ROM_COPY_SIZE：當代碼非壓縮時，所有的代碼將被一次性復制到RAM中，ROM_COPY_SIZE即指定復制代碼的大小。一般將這個值直接設置為ROM_SIZE，雖然在復制時會多做一些無用功，但是較為方便，而且對于復制代碼的大小會隨著代碼的改變而改變，經常性修改這個參數也比較麻煩，而且一旦忘記時，如果實際代碼的大小大于此處定義的副本大小時，還會出一些異常的錯誤，故還是建議用戶將其直接設置為ROM_SIZE。

如下給出了以上宏定義的簡單示例。

        #define ROM_BASE_ADRS     0x02000000     /＊ base of Flash/EPROM ＊/
        #define ROM_TEXT_ADRS     ROM_BASE_ADRS  /＊ code start addr in ROM ＊/
        #define ROM_SIZE             0x00200000     /＊ size of ROM holding VxWorks＊/
        #define ROM_COPY_SIZE      ROM_SIZE

⑥ 非易失性RAM（NVRAM）大小。NVRAM一般容量較小或者直接從存儲啟動代碼的Flash中預留一段空間，用以存儲諸如Bootline之類的參數。VxWorks啟動過程中，有一個倒計時的過程，在這個過程中，用戶如按下鍵盤上任何一個按鍵，就會進入bootline修改模式，用戶可以動態地修改bootline的參數值，如可以修改啟動方式，在下載啟動中，可以修改下載文件名、主機IP、目標機IP等。修改后的參數一般被寫入NVRAM中，這樣就可以保存本次修改，而當下次啟動時，將使用修改后的參數進行啟動。涉及NVRAM的相關宏如下。

● NV_RAM_SIZE：NVRAM大小。如果平臺不包括NVRAM，則將這個宏定義為NONE。

● BOOT_LINE_SIZE：NVRAM中預留給Bootline參數的存儲空間，這個預留值不可以大于NVRAM本身的大小NV_RAM_SIZE。這個參數在configAll.h中的默認值被設置為255B。

● NV_BOOT_OFFSET：這個常量定義了Bootline參數存儲在NVRAM中相對于NVRAM基地址的偏移量。這個參數將被sysNvRamGet和sysNvRamSet函數使用用以獲取和修改Bootline參數。

⑦ 默認Bootline參數定義。

Bootline定義了VxWorks啟動過程中的一些參數，如目標板的IP地址。如果使用下載啟動方式，則定義了下載源、下載文件名等。當然，在Bootline中還可以定義一些平臺特定參數，用戶可以在bootConfig.c或者usrConfig.c文件中對Bootline中自定義的參數進行解析，用以決定啟動過程中的某些自定義行為。內核提供了bootStringToStruct函數將Bootline以特定格式進行解析并返回解析后的數據結構，這個結構中的字段將決定內核啟動行為。

一個實際應用中的BSP Bootline定義如下所示。

        #define  DEFAULT_BOOT_LINE       "atemac(0,0)  vxw:VxWorks  h=192.168.1.6  e=192.168.
    1.254:ffffff00 g=192.168.1.1 u=www pw=www tn=AT91RM9200 o=00:00:0a:0b:0d:00"

其中定義了啟動方式是通過EMAC網口啟動，VxWorks內核映像名為VxWorks，映像所在主機IP地址為192.168.1.6，要求目標機IP地址設置為192.168.1.254，子網掩碼設置為255.255.255.0，網關IP地址為192.168.1.1，用戶名和密碼都是www，要求目標機網卡MAC地址設置為00：00：0a：0b：0d：00。

⑧ 其他對默認組件的宏定義以修改configAll.h文件中定義的默認選項。

默認行為的修改由兩條語句完成：undef和define。undef取消組件默認行為，define重新定義組件行為。

⑨ bspname.h文件，即特定平臺外設寄存器結構和地址定義、外設中斷號分配等平臺特定常量定義。

3.4.3 Makefile文件

BSP目錄下的Makefile文件決定了VxWorks和Bootrom的映像類型以及對一些參數的定義，這個Makefile是一個上層封裝文件，其底層將調用Tornado開發環境提供的Makefile文件，這些文件存在于h/make目錄下，主要有兩個：rules.bsp和defs.bsp。rules.bsp文件定義了針對各種不同映像類型的編譯規則，以及BSP中模塊的編譯規則；defs.bsp文件定義了控制編譯行為的一些標志位和常量的定義。h/make目錄下其他一些文件定義了針對不同特定平臺的編譯時參數和標志位。如下給出了一個實際的BSP的Makefile文件，這個BSP已經完成移植且運行穩定。

        CPU = ARMARCH5
        TOOL = gnu
        EXTRA_DEFINE = -Wcomment -DCPU_926E \
                -DARMMMU=ARMMMU_926E -DARMCACHE=ARMCACHE_926E
        TGT_DIR = $(WIND_BASE)/target
        include $(TGT_DIR)/h/make/defs.bsp
        include $(TGT_DIR)/h/make/make.$(CPU)$(TOOL)
        include $(TGT_DIR)/h/make/defs.$(WIND_HOST_TYPE)
        ## Only redefine make definitions below this point, or your definitions will
        ## be overwritten by the makefile stubs above.
        TARGET_DIR= arm926ejs_bsp
        VENDOR= HFei
        BOARD= seed dm6446
        MACH_EXTRA = Dm644x.o
        #BOOT_EXTRA=
        RELEASE+=  bootrom.bin
        #
        # The constants ROM_TEXT_ADRS, ROM_SIZE, and RAM_HIGH_ADRS are defined
        # in config.h and Makefile.
        # All definitions for these constants must be identical.
        #
        ROM_TEXT_ADRS= 0x02000000 # ROM entry address
        ROM_SIZE = 0x00200000 # 16M number of bytes of ROM space
        RAM_LOW_ADRS= 0x80004000 # 32M RAM text/data address
        RAM_HIGH_ADRS= 0x86000000 # RAM text/data address
        VMA_START     = 0x$(ROM_TEXT_ADRS)
        # Binary version of VxWorks ROM images, suitable for programming
        # into Flash using tools provided by ARM.  If other ROM images need to
        # be put into Flash, add similar rules here.
        bootrom.bin: bootrom
            - @ $(RM) $@
            $(EXTRACT_BIN) -O binary bootrom $@
        bootrom_res.bin: bootrom_res
            - @ $(RM) $@
            $(EXTRACT_BIN) -O binary bootrom_res $@
        bootrom_uncmp.bin: bootrom_uncmp
              - @ $(RM) $@
              $(EXTRACT_BIN) -O binary bootrom_uncmp $@
        VxWorks_rom.bin: VxWorks_rom
            - @ $(RM) $@
            $(EXTRACT_BIN) -O binary VxWorks_rom $@
        VxWorks.st_rom.bin: VxWorks.st_rom
            - @ $(RM) $@
            $(EXTRACT_BIN) -O binary VxWorks.st_rom $@
        VxWorks.res_rom.bin: VxWorks.res_rom
            - @ $(RM) $@
            $(EXTRACT_BIN) -O binary VxWorks.res_rom $@
        VxWorks.res_rom_nosym.bin: VxWorks.res_rom_nosym
            - @ $(RM) $@
            $(EXTRACT_BIN) -O binary VxWorks.res_rom_nosym $@
        ## Only redefine make definitions above this point, or the expansion of
        ## makefile target dependencies may be incorrect.
        include $(TGT_DIR)/h/make/rules.bsp
        include $(TGT_DIR)/h/make/rules.$(WIND_HOST_TYPE)

Makefile文件中必須定義如下宏。

● CPU：平臺CPU架構，如上定義為ARMARCH5，即ARM V5。

● TOOL：主機編譯工具鏈。

● TARGET_DIR：BSP目錄名。

● VENDOR：生產商。

● BOARD：平臺代號。

● ROM_TEXT_ADRS：啟動代碼存儲介質基地址。

● ROM_WARM_ADRS：熱啟動基地址，這個地址相對于ROM_TEXT_ADRS將存在一個小的偏移。熱啟動時將保留當前RAM中的所有內容。

● ROM_SIZE：ROM容量。

● RAM_LOW_ADRS、RAM_HIGH_ADRS：RAM_LOW_ADRS和RAM_HIGH_ADRS兩個常量定義啟動過程中，從ROM向RAM復制時的RAM目的地址，具體含義參考本書前文中的“映像類型”章節。

3.4.4 擴展文件

擴展文件主要存在于BSP目錄下，如果使用Tornado開發環境，則存在于工程目錄default子目錄下。擴展文件主要是在編譯過程中生成的一些中間目標文件（如bootInit.o之類）、動態創建的文件（如符號表文件symTbl.c），以及最終編譯得到的鏈接文件，如bootrom、VxWorks映像。用戶一般不用關心具體的擴展文件，本書前文“深入理解bootrom”一節較為詳細地介紹了bootrom的生成過程，用戶可以借此對這些文件進行理解，感興趣的用戶也可以參見文獻“VxWorks bsp developer’s guide”2.2.2節的內容了解擴展文件方面的內容，此處不再討論。

3.4.5 說明文件

說明文件位于BSP目錄下，對一個BSP的相關信息進行介紹，主要有兩個文件：README和target.nr。其中README文件包含BSP的發行記錄、每次發行的版本號；target.nr文件包含運行VxWorks內核映像的平臺特定信息，這些信息包括：平臺名稱、平臺簡要介紹、平臺支持的功能、平臺可用硬件資源、平臺布局（如跳線器等信息）、參考資源信息等。

說明文件在將一個BSP作為產品發布時是必要的。然而，大多數情況下，底層開發人員開發某個平臺的BSP，只是作為平臺上層應用軟件開發的操作系統基礎，在產品進行發布時，一般只發布應用層軟件和平臺本身，底層操作系統包括BSP作為二進制代碼固化在平臺硬件中（通常為Flash），不作為產品進行發布。BSP只是作為公司內部資料對相關開發人員開放，故對于說明文件的格式，在官方（Wind River公司）沒有約定的情況下，各開發公司的要求各異，此處只做簡單說明。