概 述

作為高性能、低功耗的嵌入式MCU產品，先楫半導體的HPM6000 系列產品廣泛應用于多個領域。在嵌入式系統的開發中，Bootloader 常常是開發者可能會遇到的第一個技術難點。應用程序運行環境能否正確構建，內核能否啟動成功，都取決于Bootloader 能否正確工作。一個功能完善的嵌入式系統，還需要Bootloader 能夠實現系統OTA更新升級的能力，即除了usb燒錄、串口燒錄等方式外，還預留給客戶通過以太網等方式實現快捷固件升級的窗口。

本文以HPM6450為例，基于HPM6000 系列產品嵌入式系統的硬件平臺和RT—thread 軟件平臺，描述系統引導程序Bootloader 的設計思路，闡述了設計時需要考量的因素和遇到的技術難點及操作，希望能給大家一些啟發。

二級boot方案思路分析

（圖1：整體思路分析）

如上圖所示，整個方案涉及3個部分：

FLASH空間的分區

二級boot

APP固件

因本次我們討論的重點是“二級boot”，所以下文內容僅涉及前兩部分。

1

FLASH空間的分區

HPM6700/6400系列的單片機和我們常用的stm32、at32這類的單片機最大的不同是該系列MCU 是通過 xpi 總線外掛外部FLASH，即代碼存儲在外部FLASH。

查閱芯片用戶手冊可知，該系列MCU支持通過 XPI0 或XPI1外掛FLASH（FLASH外掛方式，如圖2所示）。

其中xpi0映射的地址空間是0x80000000，xpi1映射的地址空間是 0x90000000, CPU可對這兩塊地址空間直接尋址并運行代碼（如圖3所示）。

（圖2：外部FLASH掛載于xpi0原理圖）

（圖3：地址空間映射關系）

為實現固件升級，FLASH空間需要進行合理的劃分，如Bootloader分區、用戶程序分區、OTA升級分區、用戶數據分區等。在RT-Thread上，FAL組件提供了方便的分區劃分機制。

本文分享的兩種方案均以W25Q256為例，該FLASH大小為32MB，掛載于XPI0外設上，首地址為0x80000000,通過FAL組件對FLASH的分區詳情如下圖所示：

（圖4：Flash 分區表）

注意，其中：

boot分區表示二級boot，該分區預留了1MB的存儲空間，為未來的功能升級留足了空間。

app 分區可根據實際需要來分配大小，本方案中預留了1MB的空間。

download分區用于下載固件，在APP執行過程中，新固件通過OTA下載于該分區，并在重啟后由boot分區的bootloader完成合法性檢驗和新固件升級操作。

Filesystem 分區用于實現文件系統，在此分區上面可以掛載littelfs格式文件系統，可以避免因頻繁掉電導致數據丟失的問題。

Easyflash 分區可用于存儲一些簡單的參數等。

2

二級boot

二級boot由芯片BootROM引導，從芯片的用戶手冊可知：HPM6700系列支持多種啟動方式，可到先楫半導體官網上查看“HPM6700/6400用戶手冊”的19.1內容部分，如下：

（圖5：官方代碼啟動描述）

由上可知當從串行nor flash啟動的時候，可支持“原地代碼執行”和“拷貝到內部RAM”執行。“啟動方式一” 表示代碼存儲在外部flash，并由CPU直接在flash上執行代碼；“啟動方式二” 表示代碼存在flash里面，然后通過BootROM復制代碼到內存后再執行。

受BootROM支持的兩類啟動方式的啟發，筆者經過分析以及與官方的技術支持討論得出如下結論：

采用FLASH原地執行的方式，系統可支持更大尺寸的應用程序，如支持GUI的應用。在cache的加持下，該方式可實現成本和執行速度的平衡。（需要注意的是：由于FLASH固有屬性的限制(多數FLASH不支持RWW)，在需要支持FLASH擦寫的應用中，用戶代碼需要做一些防止產生RWW場景的保護。）

采用拷貝到RAM中執行的方式，可實現如下優勢：

用戶代碼以更高的性能執行（RAM的隨機訪問性能優于FLASH）

規避了FLASH不支持RWW的限制，由于代碼執行于RAM，在需要FLASH擦寫的應用中邏輯會更簡單。

考慮到HPM6700/HPM6400系列有高達2MB連續空間的RAM，若用戶代碼及代碼所需要的RAM所占用的空間總和小于或等于2MB，“啟動方式二” 是一種值得考慮的選擇。

由于二級boot 同時支持以上兩種啟動方案，接下來，我們將針對每種方案分別進行討論。

方案一：FLASH原地執行

在該方案下，app 在FLASH里執行。如上所述，app 存儲于FLASH 1MB偏移處，需要將鏈接腳本中的FLASH首地址改為0x80100000。

需要注意的是，由于app是被二級 Bootloader 引導，因此應用程序中不應再攜帶用于 BootROM 引導識別的啟動頭(boot header)。

Boot 的 FLASH 腳本不改，最終跳轉邏輯為：

Boot啟動

檢查download分區是否有新固件，如果有則拷貝到APP

關閉中斷

跳轉到0x80100000地址，就啟動了APP。

這樣就完成了二級boot的設計。

這里最關鍵的就是如何修改連接腳本。

（圖6：啟動地址修改）

修改好app的鏈接腳本后，需要在boot里面進行跳轉，跳轉代碼參考如下：

（圖7：Boot 里跳轉）

其中app_addr 為跳轉偏移地址，如下：

（圖8：偏移地址計算）

二級boot完成App跳轉后，App在FLASH中原地執行。該方案的優勢是與復制到RAM相比，應用的尺寸可以大至數十MB。考慮到FLASH的固有限制（隨機訪問性能稍弱，不支持RWW等），當應用程序執行于FLASH上， 開發者需要注意以下幾點：

對于需要高頻執行的、對性能有要求的代碼，用戶程序需要將其復制到RAM中執行，否則會影響程序的效率（若cache未命中）。

若需要執行FLASH擦寫操作，需要保證在FLASH擦寫期間，沒有程序或者其他外設訪問FLASH（具體的實現方式有：關全局中斷、關調度器等）。

完成FLASH擦寫操作后，用戶代碼需要保證cache 一致性，否則可能會導致未預期的后果（如讀到錯誤代碼/數據）。

方案二：內存執行

若用戶代碼加代碼所需的RAM總和小于2M，基于HPM6700/HPM6400有高達2MB的連續RAM，為規避FLASH固有限制帶來的不便，產品可采用方案二，即：App本身在RAM中執行。啟動過程中，二級boot將App復制到RAM中并中轉到APP的目標地址執行。

（圖9：內存系統描述）

采用該方案時，需要注意以下三點：

二級boot所使用的RAM不應和用戶App所在RAM區域重疊，否則在拷貝中會產生錯誤。

二級boot在跳轉到用戶App前需要恢復中斷到默認狀態（關閉中斷）。

boot采用flash link的編譯方式，APP要采用ram link的編譯方式，即APP是通過內存方式的鏈接腳本，因此APP編譯后無法通過下載到flash的方式調試，必須使用USB或者其他的方式下載固件到0x80100000處。

（圖10：工作示意圖）

以下為boot里面的鏈接修改，供大家參考：

（圖11：Boot鏈接腳本參考）

（圖12：App ram link方式鏈接文件參考）

在方案二中，二級boot需要做的操作比flash boot的方式多了一個步驟，需要先將APP分區的代碼拷貝至內存，然后再跳轉至內存執行。

（圖13：代碼拷貝至內存）

（圖14：代碼跳轉至內存執行）

注意跳轉前，需要關閉各種中斷。

（圖15：運行效果示意圖）

3

注意事項

選擇鏈接腳本時，要注意看左側的鏈接腳本是否正確，如下圖所示：

（圖16：鏈接腳本示意圖）

如果鏈接腳本不能執行，請檢查下圖的設置。

（圖17：勾選newlib-nano）

編譯的時候，需要把nerlib-nano勾選上，否則當使用memcpy的時候，有可能會出現 “非法指令” 的錯誤。