介绍一种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兼容性测评。请各位读者根据项目的实际情况在两种方案中进行选择。



审核编辑：刘清