请选择 进入手机版 | 继续访问电脑版

积分152 / 贡献0

提问0答案被采纳0文章11

[经验分享] 一种OpenHarmony轻量系统适配方案 原创 精华

诚迈-陆志刚 显示全部楼层 发表于 2024-3-13 14:08:24
一种OpenHarmony轻量系统适配方案

(文章已获得原作者诚迈科技高级技术专家-潘杰授权

1. 简介
本文在不改变原有系统基础框架的基础上, 介绍了一种OpenAtom OpenHarmony(以下简称“OpenHarmony”)轻量系统适配方案。
本方案使用的是 OpenHarmony v3.2 Release版本源码。


2. 方案设计
本文使用的硬件模块的主要特性及功能如下:

fakename.png


通常,适配OpenHarmony的方案是,将内核由RTOS改为LiteOS-M,并移植原生所有功能模块和镜像打包功能。采用该方案面临了诸多困难:

●编译系统更改Gn+Ninjia,重写和调试编译脚本,需要学习成本
●适配和测试全部的原生功能,原本测试通过的功能需要重新测试,付出重复的劳动
●适配新的OS接口,需要修改原生系统的OSI层接口,以对接LiteOS-M

该方案的改动较多,将导致开发人员无法将精力聚焦于项目的新功能、工作量大、难度大,无法满足项目的工期要求,项目风险大。
OpenHarmony的轻量系统编译过程是,首先将各模块编译链接为静态库,再将静态库链接为应用程序,最后打包为镜像文件。烧录入硬件后,系统运行单一进程,各个不同的任务以多个线程运行。
结合原生编译系统和 OpenHarmony的特点,最终采用的适配方案如下:

●不改变原生代码的编译系统和打包系统
●使用原生代码的交叉编译工具链编译OpenHarmony为静态库,将静态库集成到原生代码中
●OpenHarmony中不编译LiteOS-M内核,使用原生代码的RTOS内核
●原生代码中新增适配代码,以提供OpenHarmony需要的接口

整体的软件框架设计如下:


fakename.png


方案保留了原始系统框架的大部分功能,新增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 编译命令
编译命令如下:

  1. python3 ./build.py -p L0_xts_demo -f -b debug --gn-args build_xts=true
复制代码


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

该方案涉及的相关源码已经开源,网址:  https://gitee.com/pjie131/OpenHarmony_L0_adapter

©著作权归作者所有,转载或内容合作请联系作者

您尚未登录,无法参与评论,登录后可以:
参与开源共建问题交流
认同或收藏高质量问答
获取积分成为开源共建先驱

Copyright   ©2023  OpenHarmony开发者论坛  京ICP备2020036654号-3 |技术支持 Discuz!

返回顶部