OpenHarmony輕量設備Hi3861芯片開發板啟動流程分析
OpenHarmony輕量設備Hi3861芯片開發板啟動流程分析
引言
OpenHarmony作為一款萬物互聯的操作系統，覆蓋了從嵌入式實時物聯網操作系統到移動操作系統的全覆蓋，其中內核包括LiteOS-M,LiteOS-A和Linux。LiteOS-M內核是面向IoT領域構建的輕量級物聯網操作系統內核，主要面向沒有MMU的處理器，架構如圖1-1所示。
圖1-1 LiteOS-M架構圖
Hi3861是一款高度集成的2.4GHz SoC WiFi芯片，采用高性能 32bit 微處理器，最大工作頻率 160MHz，內嵌 SRAM 352KB、ROM 288KB、Flash 2MB。目前市面上的采用LiteOS-M的OpenHarmony開發板廠商有深開鴻、潤和軟件、小熊派，因為海思的SDK是以庫文件的形式提供的，所以不同的Hi3861芯片開發板啟動流程是一樣的。
Hi3861 Boot介紹
Boot是操作系統啟動之前的軟件，通用叫法是bootloader，Hi3861的boot分為4部分：RomBoot、FlashBoot、LoaderBoot。
CommonBoot，如圖2-1所示。
圖2-1 Hi3861 Boot啟動流程
● RomBoot功能包括：加載LoaderBoot到RAM，進一步利用LoaderBoot下載鏡像到Flash、燒寫 EFUSE， 校驗并引導FlashBoot。FlashBoot分為AB面，A面校驗成功直接啟動，校驗失敗會去校驗B面，B面校驗成功會修復A面再引導啟動，否則復位重啟。
● FlashBoot功能包括：升級固件，校驗并引導固件。
● LoaderBoot功能包括：下載鏡像到Flash， 燒寫EFUSE（例如：安全啟動/Flash加密相關密鑰等）。
● CommonBoot為Flashboot與LoaderBoot共用的功能模塊。
相關文件介紹
Hi3861的LiteOS-M代碼是SDK中以庫文件的形式提供的，雖然我們無法看到源代碼，但這不代表我們分析不了啟動流程，我們可以從分析map文件和asm這兩個文件入手。這兩個文件都是編譯鏈接工具生成的，其中asm文件是匯編程序源文件，可以查看函數之間的調用關系，map文件里包括全局符號、函數地址及占用的空間和位置。map和asm文件主要作用是當開發板崩潰時用于分析其崩潰的原因，我們分析函數跳轉關系時并不需要知道太多匯編，只需要知道基本的跳轉語句和賦值語句即可，這兩個文件位于out目錄下和操作系統固件平級的目錄，如圖3-1。
圖3-1 Hi3861 asm和map文件位置圖
一個編譯完成的固件通常有以下幾部分：
1) RO段包括只讀代碼段(code段/.text段)和常量段(RO Data段/.constdata段)。
2) RW段(.data段)指已被初始化成非0值的變量段。
3) ZI段(.bss段)指未被初始化或初始化為0的變量段。
我們源代碼的函數和字符串常量都位于text段。
LiteOS-M啟動流程介紹
1) 嵌入式處理器和操作系統都具有類似的結構啟動流程也大體相似，從芯片上電開始Boot把控制權交給操作系統，Hi3861從Boot跳轉到操作系統代碼如下：
這部分是將該地址當函數作為跳轉，因為FlashBoot和kernel，是兩套代碼程序，他們之間沒有依賴引用關系，但是他們在一個地址空間，所以直接地址跳轉，這也是從Boot到kernel通用的跳轉方式。
2) 芯片啟動是從中斷向量表的復位中斷處理程序開始，接著把數據從Flash復制到RAM、清空bss數據段、初始化時鐘、跳轉到main函數。我們通過查看asm文件的main函數，可以看出其中調用的函數如圖4-1所示，從圖4-1 我們可得知調用的函數包括設置串口、校驗版本號、配置板子、Kernel初始化、應用初始化和操作系統的調度運轉，其中main函數位于liblitekernel_flash.a(main.o)文件中。
圖4-1 main函數調用關系
LOS_KernelInit是負責初始化內核數據結構的，如圖4-2所示，主要函數有OsMemSystemInit(內存初始化)、OsHwiInit(中斷初始化)、OsTaskInit(任務初始化) ，這些過程主要目的是把內核相關的變量初始化，準備好全局信息，方便API函數去調用，API函數調用必須在這些初始化完成后才可以。
3) 從AppInit開始脫離了sdk，可以看到源代碼了，AppInit函數位于libwifiiot_app.a(app_main.o)中，部分截圖如圖4-3，源代碼為app_main.c,其中調用的函數包括獲取sdk版本號，外設初始化，ipc初始化，flash分區，WiFi初始化，tcp/ip初始化，然后跳轉到了OpenHarmony特有的函數OHOS_Main。
OHOS_Main位于libwifiiot_app.a(ohos_main.o)中，源代碼為ohos_main.c,主要完成OpenHarmony系統相關和用戶應用相關的調用，里邊主要函數是OHOS_SystemInit，如圖4-4，在其中調用了用戶自己寫的應用任務相關代碼，如圖4-5，從而實現了在LOS_start之前把任務列表填好，這樣才能保證用戶任務或定時等功能參與了系統調度。
圖4-2 LOS_KernelInit函數調用關系
圖4-3 app_main函數調用關系
圖4-4 OHOS_Main函數調用關系
圖4-5 OHOS_SystemInit函數調用關系
用戶應用的啟動原理
1) 在圖4-5中出現的函數MODULE_INIT(run),就是調用最終調用用戶程序的代碼。
這是個宏定義，展開的調用關系 ：\base\startup\bootstrap_lite\services\source\core_main.h定義，從MODULE_CALL、MODULE_BEGIN 、MODULE_END，最終調用的地址是__zinitcall_##name##_start，MODULE_INIT(run)調用的函數地址是__zinitcall_run_start。
通過查看鏈接文件得出__zinitcall_run_start包含.zinitcall.run0.init)，如圖5-1所示。
圖5-1 __zinitcall_run_start鏈接關系
查看map文件發現我們自己的應用程序文件就在.zinitcall.run2.init中，如圖5-2所示。
圖5-2 led_exapmle文件在map中的位置
2) 從運行角度看啟動中調用到了應用程序led_exapmle，所謂位置為.zinitcall.run2.init，但我們在應用程序中的關聯函數是SYS_RUN(LedExampleEntry)，SYS_RUN的展開關系如圖5-3所示，最終即是 zinitcall.run2.init，和程序運行時候的調用匹配在一起了。應用程序的調用關系就是編譯鏈接階段生成指定的段，初始化時調用指定段，這樣實現了LiteOS-M的操作系統代碼與應用程序代碼的解耦。
圖5-3 SYS_RUN的展開關系
總結
本文向大家講述了在沒有部分源代碼的情況下，如何通過對map文件和asm文件的分析從而得出Hi3861芯片開發板LiteOS-M的啟動流程。總體過程就是最小硬件系統的配置完成后，LOS_KernelInit負責初始化系統到一個合適的狀態，AppInit調用OpenHarmony和應用相關代碼，最后LOS_Start負責把操作系統運轉起來。
