鴻蒙系統的啟動流程v2.0
鴻蒙系統的啟動流程
liangkz 2021.04.15 Ver2.0
- 目錄
- 1. 第一階段：U-Boot啟動..................................................................................... 3
- 2. 第二階段：匯編代碼引導LiteOS-a內核........................................................ 3
- 3. 第三階段：內核LiteOS-a的C語言啟動階段................................................ 4
- 4. 第四階段：鴻蒙系統框架層的啟動.............................................................. 14
- 5. 第四階段：鴻蒙系統框架層的啟動細節...................................................... 17
- 6. 鴻蒙應用(APP)的啟動...................................................................................... 20
- 附錄A. #task命令查看進程/線程信息(簡表).................................................... 21
聲明：
升級文檔到v2.0后可以聲明是原創的了。這是上了朱有鵬老師的免費課《想讀懂鴻蒙2.0源碼，也許你需要先懂這些》(link:https://edu.51cto.com/course/27341.html?hm)之后，做的一些總結。
課程時間一個半小時，內容也很多，學習過程中我發現朱老師的ppt上部分代碼/文件，在我本地的鴻蒙系統代碼上找不到，或者路徑不相同，所以我就做了一些整理。
這里僅摘取課程中的鴻蒙系統在HI3516DV300平臺上的啟動流程部分(從30:00開始講解啟動過程)進行匯總和整理，如有錯誤，請朱老師和各位同學指正。后繼在學習過程中會繼續對本文當作修正升級。附件升級了的v2.0文檔對閱讀更友好，歡迎下載收藏。
更新記錄：
我的本地代碼是基于最新發布的OpenHarmony 1.1.0 LTS(2021-04-01)版本抓取的，代碼根目錄OHOS1_1_0LTS：
- $repo init -u https://gitee.com/openharmony/manifest.git -b refs/tags/OpenHarmony_release_v1.1.0 --no-repo-verify
- $repo sync
在根目錄下執行
- OHOS1_1_0LTS$ hb set
- [OHOS INFO] Input code path: .
- OHOS Which product do you need?
- ->ipcamera_hispark_taurus@hisilicon
- OHOS1_1_0LTS$ hb build
即可開始編譯 hi3516dv300 平臺代碼。
輸出的過程文件和最終bin，在以下路徑內：
- out\hispark_taurus\ipcamera_hispark_taurus
因為本人還沒有開發板，無法燒錄、抓取log分析以及做相關的操作去驗證。
1. 第一階段：U-Boot啟動
- System startup
- Uncompress Ok!
- U-Boot 2016.11 (......) hi3516dv300
- ............
- ............(省略)
- Hit any key to stop autoboot: 0
- MMC read: dev #0, block # 2048, count 16384 ... 16384 blocks read: OK
- ## Starting application at 0x80000000...
到此為止屬于U-Boot的啟動。
Uboot不屬于鴻蒙系統，這里不做進一步分析，代碼在目錄
- device\hisilicon\third_party\uboot\u-boot-2020.01
2. 第二階段：匯編代碼引導LiteOS-a內核
Uboot引導liteos-a內核啟動起來，需要有一個入口，在：
- kernel\liteos_a\tools\build\liteos.ld
打開這個文件，可見：
- ENTRY(reset_vector)
- INCLUDE board.ld
- SECTIONS
- {
- ......
- }
reset_vector 就是整個鴻蒙內核啟動的入口點，這是一個符號，定義在：
- kernel\liteos_a\arch\arm\arm\src\startup\reset_vector_mp.S
同目錄下還有一個reset_vector_up.S文件，因為HI3516是ARM Cortex A7雙核處理器，所以需要看mp(多核)這個文件，up這個是單核的。
打開reset_vector_mp.S文件，找到“reset_vector:”符號，從這里開始跑匯編代碼，引導liteos-a內核的啟動，一直到：
- “
- bl main
- _start_hang:
- b _start_hang
- ”
這里調用一個 main 函數，然后執行 _start_hang 進入死循環，至此匯編代碼階段就結束了。
通過main函數進入內核LiteOS-a啟動的C語言階段。
3. 第三階段：內核LiteOS-a的C語言啟動階段
上面匯編階段調用的main函數，位于：
- kernel\liteos_a\platform\main.c
main函數通過OsSystemInfo();函數里打印下面這些信息
- ******************Welcome******************
- Processor : Cortex-A7*2
- Run Mode : SMP
- GIC Rev : GICv2
- build time : ......
- Kernel : Huawei LiteOS 2.0.0.xxx
- ********************************************
- main core booting up...
- ...
- ...
從這一步的main開始讀liteos-a的C語言源碼，可以直接在鴻蒙代碼的
- kernel\liteos_a\platform\main.c
進行閱讀理解。
- 不過，推薦從下面倉庫拉代碼下來讀，
- 鴻蒙內核源碼注解分析：
- https://gitee.com/weharmony/kernel_liteos_a_note.git
- 這是在鴻蒙官方開源項目 kernel_liteos_a 基礎上，給源代碼加上了給常詳細的中文注解，有利于加快理解。
- 需要注意的是，這個注解的內核代碼可能版本稍舊，而上面repo下來的內核部分代碼可能做了部分重構和修改，會有少量的不同。
main函數截圖如下：
Line173行調用的OsMain()函數，位于：
- kenerl\liteos_a\kernel\common\los_config.c
主要做了：
其中的：
- OsTickInit(......); // tick初始化,包含注冊中斷事件
硬件時鐘初始化，啟動節拍，注冊硬中斷
- OsKernelInitProcess(); // 完成內核進程的初始化
【鴻蒙內核源碼注解分析上的API與OpenHarmony 1.1.0 LTS(2021-04-01)上的API，有少量差異，但功能基本上是一樣的。】
代碼都在：kernel\liteos_a\kernel\base\core\los_process.c 文件內。
下面分別來看一下：
鴻蒙內核源碼注解分析：OsKernelInitProcess()
OsCreateResourceFreeTask()函數，下面的調用也是一樣的。
OpenHarmony 1.1.0 LTS（2021-04-01）：OsSystemProcessCreate( )
由上面的代碼截圖可以看出：
- 創建2號進程 KProcess，最高優先級0，這是一個內核態進程。
- 創建KProcess的子線程ResourceTask，優先級別5，用于資源回收
- 由KProcess復制(fork)出一個名叫 KIdle 的內核態進程，最低優先級31
- KIdle進程創建子線程Idle，優先級別31，給CPU空閑的時候使用.
注意，此時1號進程還沒有創建，它是用戶態根進程，要到稍微后面才創建。
可以在shell內執行task命令查看進程和線程信息，表格見附錄。
- OsSwtmrInit(); //軟時鐘模塊初始化
創建Swt_Task(software timmer)線程，父進程是2號進程KProcess，
- OsSystemInit(); //系統初始化
系統軟硬件的初始化，由2號進程 KProcess創建“system_wq”“SystemInit”“memshow_Task”等線程。
“SystemInit”線程：
跳出內核代碼，到外部提供的SystemInit()做系統初始化，在:
- device\hisilicon\hispark_taurus\sdk_liteos\mpp\module_init\src\system_init.c
里的SystemInit()函數:
其中的：
- ProcFsInit()
創建和掛載/proc文件系統，代碼見：
- kernel\liteos_a\fs\proc\os_adept\proc_init.c
- SDK_init() //calling SDK_init form HISI_SDK
初始化3516DV300特有的SDK，用內部的DSP硬件來做視頻編解碼，只提供相關庫文件，不開源。
代碼在：
- device\hisilicon\hispark_taurus\sdk_liteos\mpp\module_init\src\sdk_init.c
- OsMountRootfs()
掛載根文件系統：
- out\hispark_taurus\ipcamera_hispark_taurus\rootfs.tar
可以通過tar -tf rootfs.tar 命令查看里面都有些什么內容，下面顯示一部分目錄：
OsUserInitProcess()
- kernel\liteos_a\kernel\base\core\los_process.c
回到內核代碼，鴻蒙內核源碼注解分析：OsUserInitProcess()【最新1.1.0 LTS代碼有重構，但意思一樣】
這時候才創建1號進程Init，這是用戶態根進程，優先級別為28，
__user_init_entry 就是第一個用戶態根進程的地址，它通過宏LITE_USER_SEC_ENTRY進行定義：
代碼在：
- kernel\liteos_a\kernel\user\src\los_user_init.c
LiteOS_a操作系統起來后，到掛載根文件系統，都處于內核態(內核空間)，創建第一個用戶態根進程Init時，
通過第一個用戶態程序的地址 __user_init_entry / LITE_USER_SEC_ENTRY [ 進入OsUserInit() 并執行系統調用
"sys_call3" 切換到用戶態(用戶空間) ] 去運行g_initPath = "/bin/init" 程序。
簡單來說第一個用戶態根進程，實際上運行的就是/bin/init的代碼。
1. /kernel/liteos_a/apps目錄下，是liteoa_a自帶的內核應用，也就是內核的用戶態進程，
目前有 init、shell、tftp三個內核應用，編譯后會在下面路徑下生成同名的可執行文件：
- out\hispark_taurus\ipcamera_hispark_taurus\obj\kernel\liteos_a\bin
其中init.c 做的事情很簡單，就是fork一個新的用戶態進程并運行"/bin/shell".
2. /base/startup/init_lite目錄下的init_lite組件(init_lite module)的詳細說明，見該目錄下的官方文檔【README_zh.md】。
查看BUILD.gn可看到它也會被編譯成 init 可執行程序
在out\hispark_taurus\ipcamera_hispark_taurus\bin目錄下生成，同目錄下還有foundation、appspawn等可執行程序。
3. 【疑惑、解疑】
寫本文檔的v1.0版本時，我就一直存在一個很大的疑惑，理論上LiteOS_a內核的啟動，從內核態切換到用戶態時，
系統調用["sys_call3" ]去運行的 g_initPath = "/bin/init" ，應該是上面1編譯出來的init才對，可是為什么會去運行上面2編譯出來的init呢?
因為不懂直接分析build.py和gen_rootfs.py等編譯腳本，我只好用了最笨的分析方法，步驟如下：
3.1 可以確認的是兩個init，大小不一樣，生成位置也不一樣，init的生成時間1要比2早大約2分鐘。
3.2 懷疑是gen_rootfs.py在生成rootfs.tar時，只拷貝了2的init而沒有拷貝1的init到rootfs/bin目錄下。
但馬上推翻了，因為1生成的shell、tftp內核應用同時也拷貝到了rootfs/bin目錄下，不應該特殊處理init：
3.3 那就有可能是gen_rootfs.py在生成rootfs.tar時，先拷貝1的init/shell/tftp到/rootfs/bin，
接著再拷貝2的init/foundation/appspawn……到/rootfs/bin時，把1的init給替換掉了。
馬上驗證一下。
重新啟動編譯，等2的init一生成，馬上將其改名為init5，等編譯完成后，重新打開rootfs.tar查看，
果不其然，rootfs/bin里面出現了init和init5，文件大小基本對應得上，所以這就是真相。
3.4 有清楚gen_rootfs.py工作過程細節的同學麻煩從腳本分析入手確認一下。
3.5 另，關于shell的疑問，也請懂的同學回復一下，這里就不分析和驗證了：
kernel\liteos_a\apps\shell 會編譯成shell，據朱有鵬老師說這是精簡版的shell，
kernel\liteos_a\shell 這個也會編譯成shell，朱有鵬老師說是全功能版的shell，
這兩個版本的shell，哪個會在最終的gen_rootfs.py 時拷貝到 /bin 中?
通過上面的驗證，確認了LiteOS_a內核的啟動，從內核態切換到用戶態時，
系統調用["sys_call3" ]去運行的 g_initPath = "/bin/init" ，確實是base\startup\init_lite 組件
編譯生成的init，也就是鴻蒙系統的第一個用戶態根進程就是init_lite組件，這就進入到了
鴻蒙系統的框架層framework的啟動。
4. 第四階段：鴻蒙系統框架層的啟動
這個應用層實際上就是鴻蒙的framework，啟動init入口在：
- base\startup\init_lite\services\src\main.c
ReadFileToBuf()
這一步讀取的 /etc/init.cfg文件，在上面OsMountRootfs()掛載根文件系統的時候就掛載上了，它是
- vendor\hisilicon\hispark_taurus\init_configs\init_liteos_a_3516dv300.cfg
的副本，這個文件就包含了“pre-init”“init”“post-init”的相關操作，分別是設置掛載一些設備、設置好路徑，啟動服務等工作。
而后面的"services"則包含一組服務的定義，它們是系統里的關鍵進程。
- DoJob("init")
由“1號進程init”，在應用層通過start指令創建和啟動：shell/apphilogcat/.../ai_server等3~9號進程，它們都是用戶態進程，父進程都是“1號進程init”。
init將根據上面cfg配置的job和services來做對應的操作和啟動對應的服務程序，并設置它們的uid、gid、進程優先級和權限等。
可以在shell內執行task命令查看進程和線程信息，表格見文末。
- 【見官方文檔：base\startup\init_lite\README_zh.md】
- 這個init組件(即base\startup\init_lite)負責處理從內核加載第一個用戶態進程(1號進程init)開始，到第一個應用程序啟動之間的系統服務進程啟動過程。
- init將系統啟動分為三個階段：
- “pre-init”階段：啟動系統服務之前需要先執行的操作，例如掛載文件系統、創建文件夾、修改權限等
- “init”階段：系統服務啟動階段
- “post-init”階段：系統服務啟動完后還需要執行的操作
- 上述每個階段在配置文件init.cfg中都用一個job表示，每個job都對應一個命令集合，init通過依次執行每個job中的命令來完成系統初始化。job執行順序：先執行“pre-init”，再執行“init”，最后執行“post-init”，所有job都集中放在init.cfg的jobs數組中。
- 除上述jobs數組之外，init.cfg中還有一個services數組，用于存放所有需要由init進程啟動的系統關鍵服務的服務名、可執行文件路徑、權限和其他屬性信息。
- 配置文件init.cfg位于代碼倉庫/vendor/hisilicon/hispark_aries/init_configs/目錄，部署在/etc/下，采用json格式，文件大小目前限制在100KB以內。
- init組件會編譯成out\hispark_taurus\ipcamera_hispark_taurus目錄下的bin/init，同時打包在根文件系統rootfs.tar內，上面掛載根文件系統時，會掛載成/bin/init，由第三階段的最后一步OsUserInit()調用和執行。
- 【見官方文檔：base\startup\init_lite\README_zh.md】
總結：
Init_lite組件會編譯成out\hispark_taurus\ipcamera_hispark_taurus目錄下的bin/init，
然后在gen_rootfs.py生成rootfs.tar時替換掉系統自帶的內核應用init，成為系統第一個
用戶態根進程的啟動程序。并由它開啟系統里的其他關鍵服務進程。
5. 第四階段：鴻蒙系統框架層的啟動細節
上面第四階段簡單解釋了鴻蒙系統的關鍵系統進程和相關服務的啟動。
這一小節就要看看shell/apphilogcat/.../ai_server等3~9號進程的具體啟動過程和調用的相關代碼入口。
DoJob(“init”)會根據cmds的順序啟動相關服務：
- "name" : "init",
- "cmds" : [
- "start shell",
- "start apphilogcat",
- "start foundation",
- "start bundle_daemon",
- "start appspawn",
- "start media_server",
- "start wms_server",
- "start hiview",
- "start sensor_service",
- "start ai_server"
- ]
這些服務程序都對應在根目錄的/bin下存在(除了hiview?需平臺確認)
1.1 start shell
啟動shell服務，進程ID是3。精簡版和全功能版的shell，代碼分別在：
- kernel\liteos_a\apps\shell
- kernel\liteos_a\shell\full
具體跑哪個，目前存疑，待驗證。
1.2 start apphilogcat
啟動apphilogcat服務，進程ID是4。
- base\hiviewdfx\hilog_lite
hilog_lite組件，提供DFX(Design For X，面向X的設計)子系統在輕量系統和小型系統的流水日志功能。
詳情見目錄下的【README_zh.md】
- base\hiviewdfx\hilog_lite\services\apphilogcat\hiview_applogcat.c
- base\hiviewdfx\hilog_lite\services\hilogcat\hiview_logcat.c
main() 里面都是log文件的相關操作
1.3 start foundation
啟動foundation服務，進程ID是5。
- foundation\distributedschedule\safwk_lite
safwk_lite 是foundation進程的實現，負責提供基礎服務運行的空進程。
safwk_lite 屬于分布式任務調度子系統的一個模塊。
詳情見目錄下的【README_zh.md】 saf: system ability (SA) framework
- foundation\distributedschedule\safwk_lite\src\main.c
- main()里有調用: OHOS_SystemInit();
同文件有定義，不過是弱引用：
- void __attribute__((weak)) OHOS_SystemInit(void)
- {
- SAMGR_Bootstrap();
- }
在base\startup\bootstrap_lite\services\source\system_init.c 有另一個定義：
- void OHOS_SystemInit(void)
- {
- MODULE_INIT(bsp);
- MODULE_INIT(device);
- MODULE_INIT(core);
- SYS_INIT(service);
- SYS_INIT(feature);
MODULE_INIT(run); //SYS_RUN(HelloWorld); 從這里開始啟動，待驗證。
- //系統服務框架子系統啟動 [system ability (SA) framework]
- //foundation\distributedschedule\samgr_lite
- SAMGR_Bootstrap();
1.4 start bundle_daemon
啟動bundle_daemon服務，進程ID是6。
- foundation\appexecfwk\appexecfwk_lite
包管理組件服務，用戶程序框架子系統。
詳情見目錄下的【README_zh.md】
- foundation\appexecfwk\appexecfwk_lite\services\bundlemgr_lite\bundle_daemon\src\main.cpp
- main()里有調用: HOS_SystemInit();
同文件有定義，同樣是弱引用，不過暫未發現其他地方有定義：
- void __attribute__((weak)) HOS_SystemInit(void)
- {
- SAMGR_Bootstrap();
- }
1.5 start appspawn
啟動appspawn服務，進程ID是7。
- base\startup\appspawn_lite
appspawn_lite 應用孵化器組件，負責接受應用程序框架的命令孵化應用進程，設置其對應權限，并調用應用程序框架的入口。
詳情見目錄下的【README_zh.md】
- base\startup\appspawn_lite\services\src\main.c
main() 跑的流程基本上與bundle_daemon的一樣。
1.6 start media_server
啟動media_server服務，進程ID是8。
- foundation\multimedia\media_lite
media_lite媒體子系統組件(C++實現)，提供播放、錄制、解析、解碼等接口能力，并提供媒體播放錄制引擎服務化能力。詳情見目錄下的【README_zh.md】
- foundation\multimedia\media_lite\services\media_main.cpp
1.7 start wms_server
啟動wms_server服務，進程ID是9。
- oundation\graphic\wms
圖形服務采用C/S架構，內部分為窗口管理(WMS: Window Manager Service)和輸入事件管理(IMS: Input Manger Service)兩個子服務。APP調用客戶端接口完成窗口狀態獲取、事件處理等操作，服務端與硬件交互實現送顯、輸入事件分發等。
詳情見目錄下的【README_zh.md】
- foundation\graphic\wms\services\wms\wms.cpp
1.8 start hiview
啟動hiviewr服務，進程ID是10。
- base\hiviewdfx\hiview_lite
hiview_lite組件，提供DFX子系統整體的初始化功能，控制各組件按需啟動
- static void Init(void)
- {
- }
- SYS_SERVICE_INIT(Init);
1.9 start sensor_service
啟動sensor_server服務，進程ID是11。
- base\sensors\sensor_lite
泛Sensor服務子系統提供了輕量級sensor服務基礎框架。
詳情見目錄下的【README_zh.md】
1.10 start ai_server
啟動ai_server服務，進程ID是12。
- foundation\ai\engine
AI業務子系統是OpenHarmony提供原生的分布式AI能力的子系統。
詳情見目錄下的【README_zh.md】
5.11 HMOS的Service
HMOS的init進程啟動后，接下來會啟動上面一系列的服務(應該還會有其他更多的)，對于這些服務，鴻蒙OS有一個統一管理，所有的服務都被注冊到如下的動態數組當中。
- base\startup\init_lite\services\src\init_service_manager.c
- static Service* g_services = NULL;
- static int g_servicesCnt = 0;
具體情況需閱讀代碼進行理解。
6. 鴻蒙應用(APP)的啟動
在hi3516dv300平臺(帶屏幕)的桌面(也就是launcher進程)上點擊camera應用圖標，這時候會啟動camera應用程序，實際上會通過“7號進程appspawn”創建子進程“com.huawei.camera”，這是一個應用程序進程，其父進程并不是launcher進程，而是appspawn進程。
實際上所有的應用程序的父進程都是appspawn進程。
鴻蒙應用開發的第一個示例程序“helloworld”的啟動也應該類似。
- #include <stdio.h>
- #include "ohos_init.h"
- #include "ohos_types.h"
- void HelloWorld(void)
- {
- printf("[Init] Hello World!\n");
- }
- SYS_RUN(HelloWorld);
關于SYS_RUN()如何運作，以便讓HelloWorld運行起來，其他老師有非常詳細的解釋，這里不再復述。
附錄A. #task命令查看進程/線程信息(簡表)
