痞子衡嵌入式：飛思卡爾i.MX RTyyyy系列MCU啓動那些事（6）- Bootable image格式與加載(elftosb/.bd)

---

　　你們好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給你們介紹的是飛思卡爾i.MX RTyyyy系列MCU的Bootable image格式與加載過程。

　　在i.MXRTyyyy啓動系列第三篇文章 Serial Downloader模式(sdphost, mfgtool) 裏痞子衡在介紹使用sdphost引導啓動Flashloader時使用過一個名叫ivt_flashloader.bin的image文件，其實這個image文件就是Bootable image的一種，雖然痞子衡簡單分析過ivt_flashloader的組成，但介紹得並不詳盡，今天痞子衡會爲你們系統地講解i.MXRT Bootable image。

1、什麼是Bootable image？

　　若是你是一個有經驗的嵌入式開發者，確定對image格式有所瞭解，咱們一般開發的Application都是針對含內部FLASH的MCU而言的，好比Kinetis、LPC、STM32等MCU，其內部集成了一塊Parallel NOR FLASH，且FLASH地址是映射在ARM 4GB system address內的（通常從0x0地址開始），FLASH裏存儲的直接就是咱們編譯連接後生成的原始Application binary(.bin)，沒有任何多餘的數據組成。或許你會說還有.hex, .srec等其餘image格式，是的，但這些帶地址信息的image格式是爲編程器或下載器服務的，這些image格式通過編程器或者下載器解析後真正下載進MCU內部FLASH的數據仍是原始Application binary。這類MCU上電後CPU能直接從內部FLASH獲取Application代碼並原地執行（XIP），因此對這類MCU而言，Bootable image就是存儲在內部FLASH的Application binary(.bin)。
　　可是以上經驗在開發i.MXRT時遇到了問題，i.MXRT沒有內部FLASH，須要外接FLASH存儲器以存儲image。衆所周知，FLASH從結構上分爲NOR和NAND，i.MXRT啓動同時支持這兩種FLASH，NOR FLASH能夠實現XIP，NAND FLASH不能夠XIP，爲了兼容全部FLASH，在設計i.MXRT bootable image格式時必須以非XIP這種狀況爲基準。既然是非XIP執行，即意味着i.MXRT上電時會將image從外接FLASH拷貝到內部SRAM中去執行，在拷貝時必不可免要知道兩個重要的數據：image連接起始地址（決定image被拷貝到SRAM哪一個地址）、image總長度（決定要從外部FLASH拷貝多長的image數據進SRAM），實際上除了這兩個最基本的數據外還有其餘更高級的數據（配置、安全等特性），所以存儲在外接FLASH的i.MXRT Bootable image除了含有Application binary數據以外還必須含有額外的信息，這些額外的信息數據與Application binary共同組成i.MXRT Bootable image。至於這些額外的信息在Bootable image裏是如何組織的，痞子衡在後面會繼續聊。

2、Bootable image連接空間

　　一個image的連接空間分兩種，一種是隻讀段（readonly code,data）的連接空間，另外一種是讀寫段（readwrite data, STACK）的連接空間，這兩種連接空間要求的存儲介質特性不同，痞子衡逐一講解：
　　前面講了i.MXRT同時支持外接NOR和NAND FLASH，其中NAND FLASH沒法XIP，那麼存儲在NAND FLASH中的image只讀段必需要連接在SRAM裏。i.MXRT內部有三種SRAM，分別是ITCM, DTCM, OCRAM，是否是這三種SRAM均可以被隨意連接呢？答案並非！由於在Boot期間，BootROM也須要佔用SRAM，用於存放BootROM的讀寫段，因此被BootROM佔用的SRAM沒法用於連接image的只讀段，若是強行連接，會致使BootROM在拷貝image只讀段時破壞自身讀寫段，從而發生不可預料的行爲。下圖是RT1050 BootROM的memory map，從圖中能夠得知BootROM佔用的是0x20200000開始的OCRAM，而且看起來是整塊OCRAM都被佔用了，因此不推薦使用OCRAM去連接image只讀段。
　　黑科技：若是有朋友表示不服，RT1060/RT1050/RT1020的OCRAM是1MB/512KB/256KB，BootROM讀寫段不可能有這麼大，是的，痞子衡告訴你，其實BootROM數據段只要32KB（0x20200000 - 0x20207FFF），另外還須要4KB用加載initial non-XIP image（0x20208000 - 0x20208FFF），因此對於存儲在non-XIP FLASH的image你能夠從0x20209000以後的空間裏連接image只讀段，而對於存儲在XIP FLASH的image你能夠從0x20208000以後的空間裏連接image只讀段，這個祕密通常人痞子衡是不會告訴他的。

　　前面講了存儲在NAND FLASH中的image只讀段連接注意事項，而對於能夠XIP的NOR FLASH，除了跟NAND同樣能夠將只讀段連接在SRAM外，還能夠連接在i.MXRT分配給外接存儲器的XIP映射空間裏，下表給出了Serial NOR（QSPI）和Parallel NOR（SEMC）各自的映射起始地址，須要注意的是Serial NOR支持的最大XIP空間爲504MB，可是Parallel NOR支持的最大XIP空間只有16MB，別問痞子衡是怎麼知道的，痞子衡無所不知。

　　至於image的讀寫段，在連接時就不用區別Non-XIP/XIP FLASH了，都只能放在SRAM裏，而且不用考慮BootROM對SRAM的佔用問題（由於不在一個時間域裏被使用），只要注意不和image自身只讀段衝突就行。
　　黑科技：有朋友注意到了SDRAM，是的i.MXRT也支持SDRAM，經過SEMC接口去實現SDRAM讀寫，因此若是外接了SDRAM而且使能的話，也能夠將image只讀段/讀寫段放入SDRAM，關於SDRAM的使用，痞子衡會在後面文章裏介紹。

3、Bootable image七大組成

　　Bootable image是由一些額外的信息數據與Application binary共同組成的，那些額外的信息數據按功能分有6類，但這6類信息數據並不都是必須的，其中有4類是可選的，所以一個Bootable image最多由7部分組成，最少由3部分組成。下面痞子衡按在FLASH裏存儲位置從低到高的順序逐一介紹組成Bootable image的7大部分：

3.1 偏移0x0000: FDCB（Flash Device Configuration Block）

　　第一個組成部分叫FDCB，是個可選組成，目前只用於Serial/Parallel NOR FLASH，FDCB是從FLASH的起始地址處開始存放的，也是Bootable image最開始部分。FDCB最大4KB，其自己沒有統一的與FLASH無關的structure，具體structure根據啓動FLASH的接口類型（Serial/Parallel）而定，其通常是用來存儲當前鏈接的FLASH的具體特性參數，BootROM上電會使用通用且可靠的FLASH接口控制器配置（即BootROM中默認參數配置，通常是比較低速的配置）去訪問外接FLASH並獲取FDCB，而後根據FDCB存儲的參數去從新配置FLASH接口控制器再去進一步訪問FLASH。下面的結構體是Serial NOR的FDCB原型，此處痞子衡不會展開介紹這個結構體，留到後續介紹Serial NOR啓動再詳細介紹。

typedef struct _flexspi_nor_config
{
    flexspi_mem_config_t memConfig; //!< Common memory configuration info via FlexSPI
    uint32_t pageSize;              //!< Page size of Serial NOR
    uint32_t sectorSize;            //!< Sector size of Serial NOR
    uint8_t ipcmdSerialClkFreq;     //!< Clock frequency for IP command
    uint8_t isUniformBlockSize;     //!< Sector/Block size is the same
    uint8_t reserved0[2];           //!< Reserved for future use
    uint8_t serialNorType;          //!< Serial NOR Flash type: 0/1/2/3
    uint8_t needExitNoCmdMode;      //!< Need to exit NoCmd mode before other IP command
    uint8_t halfClkForNonReadCmd;   //!< Half the Serial Clock for non-read command: true/false
    uint8_t needRestoreNoCmdMode;   //!< Need to Restore NoCmd mode after IP commmand execution
    uint32_t blockSize;             //!< Block size
    uint32_t reserve2[11];          //!< Reserved for future use
} flexspi_nor_config_t;

3.2 偏移0x0400/0x1000: IVT（Image Vector Table）

　　第二個組成部分叫IVT，是個必備組成，也是6類信息數據裏的最核心數據，IVT是一個統一的與FLASH無關的structure，其原型以下面結構體所示，從結構體定義咱們得知，IVT中記錄了Application、DCD、BD、CSF的位置信息，這些信息對BootROM加載啓動相當重要。IVT大小固定爲32byte，其在Bootable image中的偏移位置也是固定的（對於XIP FLASH而言偏移是0x1000，對於Non-XIP FLASH而言偏移是0x400）。有朋友會疑問爲什麼IVT偏移地址是固定的？其實答案很簡單，由於BootROM必需要首先獲取IVT才能進一步找到其餘信息數據，而IVT自己的位置信息沒有在其餘地方被標明，因此只能在BootROM裏用一個常量來記錄。

#define HAB_TAG_IVT0 0xd1     /**< Image Vector Table V0 */

/** @ref hab_header structure */
typedef struct hab_hdr {
    uint8_t tag;              /**< Tag field */
    uint8_t len[2];           /**< Length field in bytes (big-endian) */
    uint8_t par;              /**< Parameters field */
} hab_hdr_t;

/** @ref ivt structure */
struct hab_ivt_v0 {
    /** @ref hdr with tag #HAB_TAG_IVT0, length and HAB version fields */
    hab_hdr_t hdr;
    /** Absolute address of the first instruction to execute from the image */
    uint32_t entry;
    /** Reserved in this version of HAB: should be NULL. */
    uint32_t reserved1;
    /** Absolute address of the image DCD: may be NULL. */
    uint32_t dcd;
    /** Absolute address of the Boot Data: may be NULL, but not interpreted any further by HAB */
    uint32_t boot_data;
    /** Absolute address of the IVT.*/
    uint32_t self;
    /** Absolute address of the image CSF.*/
    uint32_t csf;
    /** Reserved in this version of HAB: should be zero. */
    uint32_t reserved2;
};

3.3 偏移0x0420/0x1020: BD（Boot Data）

　　第三個組成部分叫BD，是個必備組成，是僅次於IVT的核心數據，BD也是一個統一的與FLASH無關的structure，其原型以下面結構體所示，BD中記錄了Bootable image的起始地址與總長度。BD大小固定爲16byte，BD信息雖然記錄在了IVT中，但其在Bootable image中的偏移位置並非任意的，BD是緊挨着IVT的。

/** @ref boot_data structure */
typedef struct boot_data{
    uint32_t start;           /* Start address of the image */
    uint32_t size;            /* Size of the image */
    uint32_t plugin;          /* Plugin flag */
    uint32_t placeholder;     /* placehoder to make even 0x10 size */
} BOOT_DATA_T;

3.4 DCD（Device Configuration Data）

　　第四個組成部分叫DCD，是個可選組成，目前主要用於SDRAM接口控制器（SEMC）的配置。因爲i.MXRT內部SRAM size一般是夠用的，且訪問速度也很快，因此SDRAM並不必定要被使能，Bootable image經常不會包含DCD，因此痞子衡在這裏先不作展開，後續有必要會再介紹。下面是SDK_2.3.1_EVKB-IMXRT1050包裏hello_world工程（flexspi_nor）所使用DCD示例：

#define DCD_TAG_HEADER (0xD2)

const uint8_t dcd_data[] = {
    /*0000*/ DCD_TAG_HEADER,
    0x04,0x30,0x41,0xCC,0x03,0xAC,0x04,0x40,0x0F,0xC0,0x68,0xFF,0xFF,0xFF,0xFF,
    /*0010*/ 0x40,
    0x0F,0xC0,0x6C,0xFF,0xFF,0xFF,0xFF,0x40,0x0F,0xC0,0x70,0xFF,0xFF,0xFF,0xFF,

    ...

    /*0420*/ 0x00,
    0x00,0x00,0x01,0xCC,0x00,0x0C,0x04,0x40,0x2F,0x00,0x4C,0x50,0x21,0x0A,0x09,
};

3.5 偏移0x2000: Application Binary

　　第五個組成部分是你最熟悉的Application binary，固然是個必備組成，其在Bootable image中的偏移位置是固定的（0x2000），關於Application自己這裏就再也不贅述了。只特別提一點，那就是i.MXRT的Application只讀段（主要指ARM中斷向量表）並不能夠從任意地址開始連接，有一個小小的限制，必須從選定的存儲器地址空間偏移0x2000以後開始連接（如選中ITCM，則必需要連接在0x00002000以後；如選中DTCM，則必須連接在0x20002000以後...），由於要預留至少8KB空間給IVT、BD、DCD等數據，這個限制是BootROM自身決定的，務必要注意。

3.6 CSF（Command Sequence File）

　　第六個組成部分叫CSF，是個特性組成，主要用於安全啓動的認證相關特性，痞子衡會在安全啓動裏進一步介紹。

3.7 KeyBlob

　　第七個組成部分叫KeyBlob，是個特性組成，主要用於安全啓動的加密相關特性，痞子衡會在安全啓動裏進一步介紹。

　　上圖是包含IVT、BD、DCD、Application、CSF的Bootable image的layout，這張圖很好地詮釋了IVT的做用。

4、Bootable image三種分類

　　前面介紹了Bootable image最多有7大組成，有些是必備，有些是可選，有的是特性。而在實際應用中，主要是必備+特性的組合造成以下三種經常使用分類：

• Unsigned Image: 這是最簡單的image類型，由IVT+BD+Application組成，主要用於產品開發階段。
• Signed Image: 這是較複雜的image類型，由IVT+BD+Application+CSF組成，通常用於產品發佈階段。
• Encrypted Image: 這是最複雜的image類型，由IVT+BD+Application+CSF+KeyBlob組成，主要用於對安全要求較高的產品中。

5、使用elftosb生成Bootable image

　　恩智浦官方提供了一個用於生成Bootable image的工具，名叫elftosb，這個工具就在\Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb目錄下，這個工具能夠用來生成全部類型的Bootable image，命令格式固定以下：

elftosb.exe -f imx -V -c config_application.bd -o ivt_application.bin application.out

　　其中ivt_application.bin就是最終生成的Bootable image，命令所須要的2個輸入文件分別是application.out、config_application.bd，application.out就是你的Application工程編譯連接生成的ELF文件，config_application.bd是用戶配置文件，這個.bd文件主要是指示elftosb工具如何在Application binary基礎上添加IVT、BD等其餘信息數據從而造成Bootable image，因此編寫.bd文件是關鍵步驟，bd文件有專門語法格式，但\Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\bd_file\imx10xx目錄下給了不少bd文件示例，咱們只須要在某一個bd文件基礎上修改便可

　　若是你追過痞子衡博客文章，你應該知道痞子衡曾經實測過RT1052的coremark性能，coremark工程已經上傳到痞子衡的github https://github.com/JayHeng/cortex-m_app，工程路徑在\cortex-m_app\apps\coremark_imxrt1052\bsp\build\coremark.eww，編譯此工程可獲得coremark_a000.out和coremark_a000.bin文件，coremark程序只讀段連接在ITCM地址（0x0000a000），咱們來試着使用elftosb將coremark程序轉換成bootable image，bd文件可參考imx-itcm-unsigned.bd，打開這個參考bd文件：

options {
    flags = 0x00;
    # Note: This is an example address, it can be any non-zero address in ITCM region
    startAddress = 0x8000;
    ivtOffset = 0x400;
    initialLoadSize = 0x2000;
    # Note: This is required if the default entrypoint is not the Reset_Handler 
    #       Please set the entryPointAddress to Reset_Handler address 
    // entryPointAddress = 0x60002411;
}

sources {
    elfFile = extern(0);
}

section (0)
{
}

　　ivtOffset和initialLoadSize不用改，分別表明IVT和Application在Bootable image中的偏移地址，startAddress即BOOT_DATA_T.start，這個是能夠修改的，牢記下面公式：

startAddress + initialLoadSize = Application只讀段起始連接地址

　　coremark_a000.out是連接在0xa000地址處的，0x8000 + 0x2000 = 0xa000，因此此處startAddress也無需改，惟一須要確認的是entryPointAddress，保險起見統一將entryPointAddress設成Application的復位中斷地址，即entryPointAddress = 0x0000ecd1。bd文件修改完成以後另存爲config_coremark_a000.bd，讓咱們試着執行下面命令：

elftosb.exe -f imx -V -c config_coremark_a000.bd -o ivt_coremark_a000.bin coremark_a000.out

　　分別打開coremark_a000.bin和ivt_coremark_a000.bin，能夠看到ivt_coremark_a000.bin比coremark_a000.bin多了前8KB的數據，這前8KB裏包含了有效的IVT（偏移0x400）和BD（偏移0x420）。

6、Bootable image的加載過程

　　知道了Bootable image的構成，痞子衡最後再簡要爲你們介紹一下i.MXRT BootROM是如何從外部存儲器中加載Bootable image進SRAM內存的。以non-XIP image加載爲例（image連接在ITCM裏），下圖顯示了i.MXRT加載image的四個階段：

• 第一個階段即加載前，此時Bootable image徹底存儲在外部Flash中，SRAM中沒有任何image數據；
• 第二階段即初始加載，BootROM首先會從外部Flash讀取Bootable image前4KB數據進SRAM臨時緩存區（OCRAM：0x20208000 - 0x20208FFF），咱們知道這4KB數據裏包含了IVT和BD，BootROM從IVT和BD裏獲取到Bootable image的目標地址（BOOT_DATA_T.start）以及總長度（BOOT_DATA_T.size），此時即可以開始作進一步加載；
• 第三階段即內部轉移，因爲BootROM已經從外部Flash讀取了4KB進SRAM臨時緩存區，爲了不重複讀取，BootROM會把這4KB數據首先複製到Bootable image的目標地址（ITCM）；
• 第四階段即加載完成，BootROM會接着將剩下的Bootable image（BOOT_DATA_T.size - 4KB）從外部Flash中所有讀取出來存到目標區域（ITCM）完成所有加載。

　　至此，飛思卡爾i.MX RTyyyy系列MCU的Bootable image格式與加載過程痞子衡便介紹完畢了，掌聲在哪裏~~~