OpenHarmony輕量設(shè)備Hi3861芯片開發(fā)板啟動(dòng)流程分析
??想了解更多關(guān)于開源的內(nèi)容，請(qǐng)?jiān)L問：??
OpenHarmony輕量設(shè)備Hi3861芯片開發(fā)板啟動(dòng)流程分析
引言
OpenHarmony作為一款萬物互聯(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)核，主要面向沒有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ā)板廠商有深開鴻、潤(rùn)和軟件、小熊派，因?yàn)楹Ｋ嫉腟DK是以庫文件的形式提供的，所以不同的Hi3861芯片開發(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、燒寫 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， 燒寫EFUSE（例如：安全啟動(dòng)/Flash加密相關(guān)密鑰等）。
● CommonBoot為Flashboot與LoaderBoot共用的功能模塊。
相關(guān)文件介紹
Hi3861的LiteOS-M代碼是SDK中以庫文件的形式提供的，雖然我們無法看到源代碼，但這不代表我們分析不了啟動(dòng)流程，我們可以從分析map文件和asm這兩個(gè)文件入手。這兩個(gè)文件都是編譯鏈接工具生成的，其中asm文件是匯編程序源文件，可以查看函數(shù)之間的調(diào)用關(guān)系，map文件里包括全局符號(hào)、函數(shù)地址及占用的空間和位置。map和asm文件主要作用是當(dāng)開發(fā)板崩潰時(shí)用于分析其崩潰的原因，我們分析函數(shù)跳轉(zhuǎn)關(guān)系時(shí)并不需要知道太多匯編，只需要知道基本的跳轉(zhuǎn)語句和賦值語句即可，這兩個(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)都具有類似的結(jié)構(gòu)啟動(dòng)流程也大體相似，從芯片上電開始Boot把控制權(quán)交給操作系統(tǒng)，Hi3861從Boot跳轉(zhuǎn)到操作系統(tǒng)代碼如下：
這部分是將該地址當(dāng)函數(shù)作為跳轉(zhuǎn)，因?yàn)镕lashBoot和kernel，是兩套代碼程序，他們之間沒有依賴引用關(guān)系，但是他們?cè)谝粋€(gè)地址空間，所以直接地址跳轉(zhuǎn)，這也是從Boot到kernel通用的跳轉(zhuǎn)方式。
2) 芯片啟動(dòng)是從中斷向量表的復(fù)位中斷處理程序開始，接著把數(shù)據(jù)從Flash復(fù)制到RAM、清空bss數(shù)據(jù)段、初始化時(shí)鐘、跳轉(zhuǎn)到main函數(shù)。我們通過查看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ù)初始化) ，這些過程主要目的是把內(nèi)核相關(guān)的變量初始化，準(zhǔ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版本號(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)和用戶應(yīng)用相關(guān)的調(diào)用，里邊主要函數(shù)是OHOS_SystemInit，如圖4-4，在其中調(diào)用了用戶自己寫的應(yīng)用任務(wù)相關(guān)代碼，如圖4-5，從而實(shí)現(xiàn)了在LOS_start之前把任務(wù)列表填好，這樣才能保證用戶任務(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)系
用戶應(yīng)用的啟動(dòng)原理
1) 在圖4-5中出現(xiàn)的函數(shù)MODULE_INIT(run),就是調(diào)用最終調(diào)用用戶程序的代碼。
這是個(gè)宏定義，展開的調(diào)用關(guān)系 ：\base\startup\bootstrap_lite\services\source\core_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) 從運(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的展開關(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的展開關(guān)系
總結(jié)
本文向大家講述了在沒有部分源代碼的情況下，如何通過對(duì)map文件和asm文件的分析從而得出Hi3861芯片開發(fā)板LiteOS-M的啟動(dòng)流程。總體過程就是最小硬件系統(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)起來。
