引言

OpenHarmony作為一款萬(wàn)物互聯(lián)的操作系統(tǒng)，覆蓋了從嵌入式實(shí)時(shí)物聯(lián)網(wǎng)操作系統(tǒng)到移動(dòng)操作系統(tǒng)的全覆蓋，其中內(nèi)核包括LiteOS-M，LiteOS-A和Linux。LiteOS-M內(nèi)核是面向IoT領(lǐng)域構(gòu)建的輕量級(jí)物聯(lián)網(wǎng)操作系統(tǒng)內(nèi)核，主要面向沒(mé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開(kāi)發(fā)板廠商有深開(kāi)鴻、潤(rùn)和軟件、小熊派，因?yàn)?a href="http://www.solar-ruike.com.cn/tags/海思/" target="_blank">海思的SDK是以庫(kù)文件的形式提供的，所以不同的Hi3861芯片開(kāi)發(fā)板啟動(dòng)流程是一樣的。

Hi3861 Boot介紹

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

圖2-1 Hi3861 Boot啟動(dòng)流程

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

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

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

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

相關(guān)文件介紹

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

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

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

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

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

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

我們?cè)创a的函數(shù)和字符串常量都位于text段。

LiteOS-M啟動(dòng)流程介紹

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

這部分是將該地址當(dāng)函數(shù)作為跳轉(zhuǎn)，因?yàn)镕lashBoot和kernel，是兩套代碼程序，他們之間沒(méi)有依賴(lài)引用關(guān)系，但是他們?cè)谝粋€(gè)地址空間，所以直接地址跳轉(zhuǎn)，這也是從Boot到kernel通用的跳轉(zhuǎn)方式。

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

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

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

3） 從AppInit開(kāi)始脫離了sdk，可以看到源代碼了，AppInit函數(shù)位于libwifiiot_app.a（app_main.o）中，部分截圖如圖4-3，源代碼為app_main.c，其中調(diào)用的函數(shù)包括獲取sdk版本號(hào)，外設(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)和用戶(hù)應(yīng)用相關(guān)的調(diào)用，里邊主要函數(shù)是OHOS_SystemInit，如圖4-4，在其中調(diào)用了用戶(hù)自己寫(xiě)的應(yīng)用任務(wù)相關(guān)代碼，如圖4-5，從而實(shí)現(xiàn)了在LOS_start之前把任務(wù)列表填好，這樣才能保證用戶(hù)任務(wù)或定時(shí)等功能參與了系統(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)系

用戶(hù)應(yīng)用的啟動(dòng)原理

1） 在圖4-5中出現(xiàn)的函數(shù)MODULE_INIT（run），就是調(diào)用最終調(diào)用用戶(hù)程序的代碼。這是一個(gè)宏定義，展開(kāi)的調(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。

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

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

總結(jié)

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