引言

OpenHarmony作為一款萬物互聯(lián)的操作系統(tǒng)，覆蓋了從嵌入式實時物聯(lián)網(wǎng)操作系統(tǒng)到移動操作系統(tǒng)的全覆蓋，其中內(nèi)核包括LiteOS-M，LiteOS-A和Linux。LiteOS-M內(nèi)核是面向IoT領(lǐng)域構(gòu)建的輕量級物聯(lián)網(wǎng)操作系統(tǒng)內(nèi)核，主要面向沒有MMU的處理器，架構(gòu)如圖1-1所示。

圖1-1 LiteOS-M架構(gòu)圖

Hi3861是一款高度集成的2.4GHz SoC WiFi芯片，采用高性能 32bit 微處理器，最大工作頻率 160MHz，內(nèi)嵌 SRAM 352KB、ROM 288KB、Flash 2MB。目前市面上的采用LiteOS-M的OpenHarmony開發(fā)板廠商有深開鴻、潤和軟件、小熊派，因為海思的SDK是以庫文件的形式提供的，所以不同的Hi3861芯片開發(fā)板啟動流程是一樣的。

Hi3861 Boot介紹

Boot是操作系統(tǒng)啟動之前的軟件，通用叫法是bootloader，Hi3861的boot分為4部分：RomBoot、FlashBoot、LoaderBoot、 CommonBoot，如圖2-1所示。

圖2-1 Hi3861 Boot啟動流程

● RomBoot功能包括：加載LoaderBoot到RAM，進一步利用LoaderBoot下載鏡像到Flash、燒寫 EFUSE， 校驗并引導(dǎo)FlashBoot。FlashBoot分為AB面，A面校驗成功直接啟動，校驗失敗會去校驗B面，B面校驗成功會修復(fù)A面再引導(dǎo)啟動，否則復(fù)位重啟。

● FlashBoot功能包括：升級固件，校驗并引導(dǎo)固件。

● LoaderBoot功能包括：下載鏡像到Flash， 燒寫EFUSE（例如：安全啟動/Flash加密相關(guān)密鑰等）。

● CommonBoot為Flashboot與LoaderBoot共用的功能模塊。

相關(guān)文件介紹

Hi3861的LiteOS-M代碼是SDK中以庫文件的形式提供的，雖然我們無法看到源代碼，但這不代表我們分析不了啟動流程，我們可以從分析map文件和asm這兩個文件入手。這兩個文件都是編譯鏈接工具生成的，其中asm文件是匯編程序源文件，可以查看函數(shù)之間的調(diào)用關(guān)系，map文件里包括全局符號、函數(shù)地址及占用的空間和位置。map和asm文件主要作用是當開發(fā)板崩潰時用于分析其崩潰的原因，我們分析函數(shù)跳轉(zhuǎn)關(guān)系時并不需要知道太多匯編，只需要知道基本的跳轉(zhuǎn)語句和賦值語句即可，這兩個文件位于out目錄下和操作系統(tǒng)固件平級的目錄，如圖3-1。

圖3-1 Hi3861 asm和map文件位置圖

一個編譯完成的固件通常有以下幾部分：

1） RO段包括只讀代碼段（code段/.text段）和常量段（RO Data段/.constdata段）。

2） RW段（.data段）指已被初始化成非0值的變量段。

3） ZI段（.bss段）指未被初始化或初始化為0的變量段。

我們源代碼的函數(shù)和字符串常量都位于text段。

LiteOS-M啟動流程介紹

1） 嵌入式處理器和操作系統(tǒng)都具有類似的結(jié)構(gòu)啟動流程也大體相似，從芯片上電開始Boot把控制權(quán)交給操作系統(tǒng)，Hi3861從Boot跳轉(zhuǎn)到操作系統(tǒng)代碼如下：

這部分是將該地址當函數(shù)作為跳轉(zhuǎn)，因為FlashBoot和kernel，是兩套代碼程序，他們之間沒有依賴引用關(guān)系，但是他們在一個地址空間，所以直接地址跳轉(zhuǎn)，這也是從Boot到kernel通用的跳轉(zhuǎn)方式。

2） 芯片啟動是從中斷向量表的復(fù)位中斷處理程序開始，接著把數(shù)據(jù)從Flash復(fù)制到RAM、清空bss數(shù)據(jù)段、初始化時鐘、跳轉(zhuǎn)到main函數(shù)。我們通過查看asm文件的main函數(shù)，可以看出其中調(diào)用的函數(shù)如圖4-1所示，從圖4-1 我們可得知調(diào)用的函數(shù)包括設(shè)置串口、校驗版本號、配置板子、Kernel初始化、應(yīng)用初始化和操作系統(tǒng)的調(diào)度運轉(zhuǎn)，其中main函數(shù)位于liblitekernel_flash.a（main.o）文件中。

圖4-1 main函數(shù)調(diào)用關(guān)系

LOS_KernelInit是負責初始化內(nèi)核數(shù)據(jù)結(jié)構(gòu)的，如圖4-2所示，主要函數(shù)有OsMemSystemInit（內(nèi)存初始化）、OsHwiInit（中斷初始化）、OsTaskInit（任務(wù)初始化） ，這些過程主要目的是把內(nèi)核相關(guān)的變量初始化，準備好全局信息，方便API函數(shù)去調(diào)用，API函數(shù)調(diào)用必須在這些初始化完成后才可以。

3） 從AppInit開始脫離了sdk，可以看到源代碼了，AppInit函數(shù)位于libwifiiot_app.a（app_main.o）中，部分截圖如圖4-3，源代碼為app_main.c，其中調(diào)用的函數(shù)包括獲取sdk版本號，外設(shè)初始化，ipc初始化，flash分區(qū)，WiFi初始化，tcp/ip初始化，然后跳轉(zhuǎn)到了OpenHarmony特有的函數(shù)OHOS_Main。

OHOS_Main位于libwifiiot_app.a（ohos_main.o）中，源代碼為ohos_main.c，主要完成OpenHarmony系統(tǒng)相關(guān)和用戶應(yīng)用相關(guān)的調(diào)用，里邊主要函數(shù)是OHOS_SystemInit，如圖4-4，在其中調(diào)用了用戶自己寫的應(yīng)用任務(wù)相關(guān)代碼，如圖4-5，從而實現(xiàn)了在LOS_start之前把任務(wù)列表填好，這樣才能保證用戶任務(wù)或定時等功能參與了系統(tǒng)調(diào)度。

圖4-2 LOS_KernelInit函數(shù)調(diào)用關(guān)系

圖4-3 app_main函數(shù)調(diào)用關(guān)系

圖4-4 OHOS_Main函數(shù)調(diào)用關(guān)系

圖4-5 OHOS_SystemInit函數(shù)調(diào)用關(guān)系

用戶應(yīng)用的啟動原理

1） 在圖4-5中出現(xiàn)的函數(shù)MODULE_INIT（run），就是調(diào)用最終調(diào)用用戶程序的代碼。這是一個宏定義，展開的調(diào)用關(guān)系 ：asestartupootstrap_liteservicessourcecore_main.h定義，從MODULE_CALL、MODULE_BEGIN 、MODULE_END，最終調(diào)用的地址是__zinitcall_##name##_start，MODULE_INIT（run）調(diào)用的函數(shù)地址是__zinitcall_run_start。

通過查看鏈接文件得出__zinitcall_run_start包含.zinitcall.run0.init），如圖5-1所示。

圖5-1 __zinitcall_run_start鏈接關(guān)系

查看map文件發(fā)現(xiàn)我們自己的應(yīng)用程序文件就在.zinitcall.run2.init中，如圖5-2所示。

圖5-2 led_exapmle文件在map中的位置

2） 從運行角度看啟動中調(diào)用到了應(yīng)用程序led_exapmle，所謂位置為.zinitcall.run2.init，但我們在應(yīng)用程序中的關(guān)聯(lián)函數(shù)是SYS_RUN（LedExampleEntry），SYS_RUN的展開關(guān)系如圖5-3所示，最終即是 zinitcall.run2.init，和程序運行時候的調(diào)用匹配在一起了。應(yīng)用程序的調(diào)用關(guān)系就是編譯鏈接階段生成指定的段，初始化時調(diào)用指定段，這樣實現(xiàn)了LiteOS-M的操作系統(tǒng)代碼與應(yīng)用程序代碼的解耦。

圖5-3 SYS_RUN的展開關(guān)系

總結(jié)

本文向大家講述了在沒有部分源代碼的情況下，如何通過對map文件和asm文件的分析從而得出Hi3861芯片開發(fā)板LiteOS-M的啟動流程。總體過程就是最小硬件系統(tǒng)的配置完成后，LOS_KernelInit負責初始化系統(tǒng)到一個合適的狀態(tài)，AppInit調(diào)用OpenHarmony和應(yīng)用相關(guān)代碼，最后LOS_Start負責把操作系統(tǒng)運轉(zhuǎn)起來。