大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是飛思卡爾i.MX RT系列MCU的Bootable image格式與載入過程。
在i.MXRT啟動系列第三篇文章 Serial Downloader模式(sdphost, mfgtool) 裡痞子衡在介紹使用sdphost引導啟動Flashloader時使用過一個名叫ivt_flashloader.bin的image檔案，其實這個image檔案就是Bootable image的一種，雖然痞子衡簡單分析過ivt_flashloader的組成，但介紹得並不詳盡，今天痞子衡會為大家系統地講解i.MXRT Bootable image。
一、什麼是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裡是如何組織的，痞子衡在後面會繼續聊。
二、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的使用，痞子衡會在後面文章裡介紹。
三、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的作用。
四、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組成，主要用於對安全要求較高的產品中。
五、使用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）。
六、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 RT系列MCU的Bootable image格式與載入過程痞子衡便介紹完畢了，掌聲在哪裡~~~