大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是 i.MXRTxxx 系列 ROM API 設計細節。

痞子衡之前寫過兩篇文章 《利用 i.MXRT1xxx 系列 ROM 提供的 FlexSPI driver API 可輕松 IAP》、《其實 i.MXRT1050,1020,1015 系列 ROM 也提供了 FlexSPI driver API》 基本把 i.MXRT1xxx 全系列的 ROM API 及其 FlexSPI NOR 驅動設計都講清楚了，其實 i.MXRTxxx 系列的 ROM API 設計跟 i.MXRT1xxx 系列的設計思路差不多（其實本就是同一個恩智浦研發小組負責的），僅有一些微小區別，本文痞子衡主要就是點出那些區別。

一、ROM 基址差異

ROM API 代碼首先是在 BootROM 里，BootROM 代碼是出廠前固化在 ROM 區域的。因為架構設計的關系，i.MXRTxxx 系列和 i.MXRT1xxx 系列的 ROM 區域在系統內存里的映射地址不同。

下表是 i.MXRTxxx 系列代表型號 i.MXRT500 的部分系統內存映射，可以看到 ROM 區域起始地址是 0x03000000（非安全域）。目前 i.MXRTxxx 都是 Cortex-M33 內核，支持 TrustZone 特性，所以 0x13000000 也是 ROM 起始地址（安全域），為了通用性，我們認 0x03000000 就可以了，這個地址在安全狀態和非安全狀態下都能被訪問。

下表是 i.MXRT1xxx 系列代表型號 i.MXRT1060 的部分系統內存映射，可以看到 ROM 區域起始地址是 0x00200000。i.MXRT1xxx 系列都是 Cortex-M7 內核，沒有 TrustZone 特性，不存在 i.MXRTxxx 上那樣的兩種狀態域下的地址。

二、API 基址備份位置差異

在 i.MXRT1xxx 系列 ROM API 介紹的文章里，痞子衡介紹過 g_bootloaderTree 地址值被復制了一份放在了 BootROM 中斷向量表第 8 個向量的位置處（該向量為 ARMv7-M 架構下未定義的系統向量），因此讀取 0x0020001c 處開始的 4bytes 便能找到 i.MXRT1xxx 系列的 g_bootloaderTree。

但是由于 i.MXRTxxx 是 Cortex-M33 內核，屬于 ARMv8-M 架構，從下圖中可以看出 ARMv8-M 架構下中斷向量表第 8 個向量是 SecureFault，已經被定義了，因此 BootROM 把 g_bootloaderTree 地址值放到了第 9 個向量的位置處（該向量為 ARMv8-M 架構下未定義的系統向量），故讀取 0x03000020 處開始的 4bytes 才能找到 i.MXRTxxx 系列的 g_bootloaderTree（這種方式在實際 API 調用中并不可取，至于原因嘛，先賣個關子）。

下面是 i.MXRT500 BootROM 工程的 startup 文件（IAR 版），g_bootloaderTree 確實在第 9 個向量處：

MODULE ?cstartup

;; Forward declaration of sections.
SECTION CSTACK:DATA:NOROOT(3)
SECTION .intvec:CODE:NOROOT(2)

EXTERN __iar_program_start
EXTERN g_bootloaderTree
PUBLIC __vector_table
PUBLIC __vector_table_0x1c

DATA

__vector_table
DCD sfe(CSTACK)
DCD Reset_Handler
DCD DefaultISR
DCD HardFault_Handler
DCD DefaultISR
DCD DefaultISR
DCD UsageFault_Handler
__vector_table_0x1c
DCD SecureFault_Handler
DCD g_bootloaderTree
DCD 0
DCD 0
DCD SVC_Handler
DCD DefaultISR
DCD 0
DCD DefaultISR
DCD SysTick_Handler
;; ...

三、API 原型定義差異

下面是 i.MXRTxxx 系列 ROM API 原型定義及其實例（適用 i.MXRT500/600），基本形式跟 i.MXRT1xxx 差不多，但是 API 功能更豐富，除了 FlexSPI NOR 驅動，還有 iap api、USB low-level driver、otp driver 等（我們知道，i.MXRTxxx 與 LPC 系列同根同源，LPC 系列 ROM 里一般都會集成很多經典 SDK 驅動，比如內部 flash、low power 驅動，有了這些穩定的驅動 API，LPC 系列的用戶手冊里甚至都會省去這些 IP 的寄存器介紹，直接就是 API 的介紹）。

typedef struct
{
void (*runBootloader)(void *arg);
uint32_t version;
const char *copyright;
const bootloader_context_t *runtimeContext;
const kb_interface_t *kbApi;
const usb_driver_interface_t *usbDriver;
const USBD_API_T *lpcUsbDriver;
const flexspi_nor_flash_driver_t *flexspiNorDriver;
const ocotp_driver_t *otpDriver;
const skboot_authenticate_interface_t *skbootAuthenticate;
} bootloader_api_entry_t;

//! @brief Static API tree.
__root const bootloader_api_entry_t g_bootloaderTree @".rom_api_tree_section" = {
.runBootloader = bootloader_user_entry,
.version = MAKE_VERSION('K', 3, 0, 0),
.copyright = "Copyright 2019 NXP.",
.runtimeContext = &g_bootloaderContext,
.kbApi = &g_romApiInterface,
.usbDriver = &g_usbDriverInterface,
.flexspiNorDriver = &g_flexspiNorFlashDriverInterface,
.otpDriver = &g_otpDriverInterface,
.skbootAuthenticate = &g_skbootAuthenticateInterface,
};

四、API 實例鏈接差異

i.MXRT1xxx 系列 ROM API 實例 g_bootloaderTree 都是讓鏈接器自由鏈接的，因此每個具體型號的實際 ROM API 鏈接地址沒有一致的規律可循（這也是為什么要在中斷向量表里固定位置統一保存一份），而這點在 i.MXRTxxx 上有了改進，i.MXRTxxx 里將 g_bootloaderTree 放到了 .rom_api_tree_section 段里，在鏈接文件里將該段固定鏈接在 ROM 區域最后 4KB 處（BootROM 代碼沒有把全部 ROM 空間用盡）。

下面是 i.MXRTxxx BootROM 源文件中 g_bootloaderTree 的定義，加了段修飾。此外還有額外的 k_romcrc，標示 API 實例區域的結束。

__root const bootloader_api_entry_t g_bootloaderTree @".rom_api_tree_section" = {
.runBootloader = bootloader_user_entry,
.version = MAKE_VERSION('K', 3, 0, 0),
.copyright = "Copyright 2019 NXP.",
.runtimeContext = &g_bootloaderContext,
// ...
};

__root const uint32_t k_romcrc @".romcrc" = 0xdeadbeef;

下面是 i.MXRTxxx 鏈接文件（IAR 工程）中 .rom_api_tree_section 段的處理（i.MXRT500 型號示例，ROM 空間是 192KB）。你可能好奇為啥 ROM_API_TREE_xx 等值是放在 0x13000000 開始的安全域 ROM 空間映射，BootROM 屬于上電啟動第一級，負責芯片系統的安全和啟動，當然是工作在安全狀態下，可以訪問安全域地址空間。

define symbol __ICFEDIT_region_ROM_API_TREE_start__ = 0x1302f000;
define symbol __ICFEDIT_region_ROM_API_TREE_end__ = 0x1302f0ff;
define symbol __ICFEDIT_region_ROM_CRC_CHECKSUM_start__ = 0x1302fffc;
define symbol __ICFEDIT_region_ROM_CRC_CHECKSUM_end__ = 0x1302ffff;

define region ROM_API_TREE_region = mem:[from __ICFEDIT_region_ROM_API_TREE_start__ to __ICFEDIT_region_ROM_API_TREE_end__];
define region ROM_CRC_CHECKSUM = mem:[from __ICFEDIT_region_ROM_CRC_CHECKSUM_start__ to __ICFEDIT_region_ROM_CRC_CHECKSUM_end__];

place in ROM_API_TREE_region { section .rom_api_tree_section };
place in ROM_CRC_CHECKSUM { section .romcrc };

基于上面的設計，你才會在 i.MXRT500 參考手冊里 Non-Secure Boot ROM 章節看到如下 ROM API 地址及結構信息圖（圖中僅標了常用的 API 功能函數），實際 ROM API 調用時，App 的執行其實都是經過 ROM 引導和認證的，App 中既可以訪問安全域地址（0x1302f000）來調用 API，也可以訪問非安全域地址（0x0302f000）來調用 API。

最后再來回答前面賣的關子，為什么 i.MXRTxxx 系列通過 BootROM 中斷向量表第 9 個向量值來訪問 ROM API 這種方式并不可取？其實從 BootROM 煞費苦心地將 g_bootloaderTree 固定鏈接在 ROM 區域最后 4KB 處，你就能看出其用意。如果你掛上調試器直接訪問 i.MXRTxxx 的 ROM 區域前 20KB 的空間，你會發現無法訪問，在 App 里 AHB 方式讀這個區域，也會直接產生 HardFault，因為 BootROM 里做了特殊設計故意隱藏了前 20KB 空間，這個空間里存放了 BootROM 想要保護的數據和代碼，至于內容是啥，純屬機密，恕不奉告，哈哈。

至此，i.MXRTxxx 系列 ROM API 設計細節痞子衡便介紹完畢了，掌聲在哪里~~~

審核編輯 黃昊宇