介紹一種OpenAtom OpenHarmony輕量系統適配方案

1. 簡介

本文在不改變原有系統基礎框架的基礎上， 介紹了一種OpenAtom OpenHarmony（以下簡稱“OpenHarmony”）輕量系統適配方案。 本方案使用的是 OpenHarmony v3.2 Release版本源碼。

2. 方案設計

本文使用的硬件模塊的主要特性及功能如下：

通常，適配OpenHarmony的方案是，將內核由RTOS改為LiteOS-M，并移植原生所有功能模塊和鏡像打包功能。采用該方案面臨了諸多困難：

●編譯系統更改Gn+Ninjia，重寫和調試編譯腳本，需要學習成本

●適配和測試全部的原生功能，原本測試通過的功能需要重新測試，付出重復的勞動

●適配新的OS接口，需要修改原生系統的OSI層接口，以對接LiteOS-M

該方案的改動較多，將導致開發人員無法將精力聚焦于項目的新功能、工作量大、難度大，無法滿足項目的工期要求，項目風險大。

OpenHarmony的輕量系統編譯過程是，首先將各模塊編譯鏈接為靜態庫，再將靜態庫鏈接為應用程序，最后打包為鏡像文件。燒錄入硬件后，系統運行單一進程，各個不同的任務以多個線程運行。

結合原生編譯系統和 OpenHarmony的特點，最終采用的適配方案如下：

●不改變原生代碼的編譯系統和打包系統

●使用原生代碼的交叉編譯工具鏈編譯OpenHarmony為靜態庫，將靜態庫集成到原生代碼中

●OpenHarmony中不編譯LiteOS-M內核，使用原生代碼的RTOS內核

●原生代碼中新增適配代碼，以提供OpenHarmony需要的接口

整體的軟件框架設計如下：

方案保留了原始系統框架的大部分功能，新增OpenHarmony的模塊功能和其他項目需求功能，修改或升級部分原生功能（FreeRTOS、 MbedTLS等）。

3. OpenHarmony編譯

3.1 創建虛擬設備編譯

創建新的vendor和新的device配置，目錄如下：

●vendor/ohemu/L0_xts_demo

●device/qemu/L0_xts_demo

3.2 子系統配置

修改vendor/ohemu/L0_xts_demo/config.json，該文件包含了所有必須的子系統配置。

3.3 工具鏈配置

修改device/qemu/L0_xts_demo/liteos_m/config.gni，該文件包含了板級編譯配置，根據原生編譯系統的編譯設置來修改。

3.4 編譯命令

編譯命令如下：

python3 ./build.py -p L0_xts_demo -f -b debug --gn-args build_xts=true

編譯出的靜態庫位于out/L0_xts_demo/L0_xts_demo/libs

3.5 優化剪裁

對manifest和prebuild進行剪裁，只下 載必須的軟件和源碼。

●修改build/prebuilts_download_config.json，只保留GN、Ninja和Python。

●修改.repo/manifests/ohos/ohos.xml，刪除不需要的包和源碼。

3.6 集成

將編譯后的靜態庫拷貝到原生編譯系統中，并編寫demo程序，進行編譯。

3.6.1 編寫demo

OpenHarmony的demo分為兩個單元main.c和demo.c。

●main.c 主線程，調用OHOS_SystemInit()函數，啟動OpenHarmony

● demo.c 示例線程，調用hilog接口循環打印日志

3.6.2 編譯demo

在demo目錄下創建CMakeFile.txt文件。

定義OpenHarmony的頭文件包含目錄及庫文件，編譯main.c和demo.c，生成demo鏡像文件。

3.6.3 編譯XTS

將XTS編譯生成的靜態庫鏈接為鏡像，每一項XTS測試生成一個鏡像。

3.6.4 鏈接

修改ld文件的.TEXT段，新增OpenHarmony的自定義段設置。

4. 原生系統修改

在原生代碼中升級模塊或新增OpenHarmony調用的接口。

4.1 升級RTOS

由于不支持OpenHarmony中的底層接口，FreeRTOS內核從版本10.0.1升級到版本v10.3.1，適配其HAL層和 OSI層接口。

FreeRTOS源碼來自于官網地址： https://github.com/FreeRTOS/FreeRTOS

4.2 升級MbedTLS

因為原生MbedTLS代碼的版本較低，所以拷貝OpenHarmony中的MbedTLS源碼覆蓋到原生系統中。修改在OpenHarmony中不編譯三方庫MbedTLS。

修改CMakeFile.txt和config.h，打開OpenHarmony和原生系統需要的功能開關。

4.3 新增CMSIS接口

原生系統kernel中新增cmsis目錄，包含CMSIS的源碼和頭文件。

CMSIS源碼來自于開源項目CMSIS-FreeRTOS，地址：https://github.com/ARM-software/CMSIS-FreeR TOS

修改部分源碼適配系統源碼，并修改kernel的CMakeFile.txt，將源碼中的cmsis_os2.c文件加入編譯。

4.4 新增打印接口

新增打印接口，對接原生系統打印功能，比如打印到串口、保存文件等。新增加的功能模塊和OpenHarmony均調用新增的打印接口。

4.5 新增文件系統接口

適配OpenHarmony的文件系統調用的接口

●_open()

●_close()

●_read()

●_write()

●_lseek()

●_unlink()

需要注意的是，OpenHarmony要求打開文件最多為32個，這里需要控制通過_open()接口打開的文件 總數不能超過32個。

4.6 新增POSIX接口

適配編譯中報錯缺失的POSIX接口

●_exit()

●kill()

●sleep()

●_fini()

4.7 新增LiteOS接口

LiteOS中調用的接口

●ArchIntLock()

●ArchIntRestore()

●LOS_MuxCreate()

●LOS_MuxPend()

●LOS_MuxDelete()

●LOS_TickCountGet()

●osThreadGetArgument()

4.8 其他接口

適配缺失的其他接口

●OhosMalloc()

●OhosFree()

●RefreshAllServiceTimeStamp()

●HiLogWriteInternal()

5. OpenHarmony修改

5.1 三方庫

修改third_party/bounds_checking_function/BUILD.gn，編譯生成libsec_static靜態庫

5.2 修改hiview_lite

●base/hiviewdfx/hiview_lite/BUILD.gn，改為無緩存，直接輸出到串口。

●base/hiviewdfx/hiview_lite/hiview_util.c ，修改打印函數，調用原生系統新增的打印接口

5.3 修改HUKS

修改文件base/security/huks/utils/mutex/hks_mutex.c

因為原生系統并不支持POSIX的mutex系列接口，這里修改為LOS接口。如果原生系統支持POSIX接口，則這里不需要進行修改。

5.4 修改bootstrap_lite

修改文件base/startup/bootstrap_lite/services/source/core_main.h，取消宏里面的重復調用。

5.5 刪除-fPIC

刪除BUILD.gn文件里的-fPIC，否則會導致程序運行異常。

●foundation/ability/ability_lite/frameworks/want_lite/BUILD.gn

●foundation/bundlemanager/bundle_framework_lite/frameworks/bundle_lite/BUILD.gn

5.6 修改XTS

修改日志打印，將日志輸出到串口。

6. 總結

該方案與通用方案相比，降低了適配復雜度和開發難度，減少了工作量，使項目進度符合了工期要求，是一種快速的適配方案。采用該方案進行開發的輕量設備已經成功通過了OpenHarmony兼容性測評。請各位讀者根據項目的實際情況在兩種方案中進行選擇。



審核編輯：劉清