OpenHarmony（鸿蒙南向开发）——移植子系统(一)

最新推荐文章于 2024-07-31 20:55:57 发布

OpenHarmony_小贾

最新推荐文章于 2024-07-31 20:55:57 发布

阅读量191

点赞数 3

分类专栏：移动开发鸿蒙开发 OpenHarmony 文章标签： OpenHarmony 子系统系统移植移动开发嵌入式开发鸿蒙开发驱动开发

本文链接：https://blog.csdn.net/maniuT/article/details/140823743

版权

移动开发同时被 3 个专栏收录

878 篇文章 5 订阅

订阅专栏

OpenHarmony

617 篇文章 11 订阅

订阅专栏

鸿蒙开发

426 篇文章 0 订阅

订阅专栏

概述

OpenHarmony系统功能按照“系统 > 子系统 > 部件”逐级展开，支持根据实际需求裁剪某些非必要的部件，本文以部分子系统、部件为例进行介绍。若想使用OpenHarmony系统的能力，需要对相应子系统进行适配。

OpenHarmony芯片适配常见子系统列表如下（详见表1），需结合具体芯片再做增删减操作。

表1 OpenHarmony子系统

子系统	作用
applications	应用程序demo。可将应用相关源码存放在此目录下。
kernel	内核子系统。负责任务调度、内存管理等常见的内核功能。
hiviewdfx	可维可测子系统。提供日志相关功能。
communication	通信子系统。包含Wi-Fi，蓝牙功能。
iothardware	IOT外设子系统。提供常见的外设接口，例如GPIO，I2C，SPI等。
startup	启动子系统。内核启动后运行的第一个子系统，负责在内核启动之后到应用启动之前的系统关键进程和服务的启动过程的功能。
update	升级子系统。用来支持OpenHarmony设备的OTA升级。
utils	公共基础库子系统。提供了一些常用的C、C++开发增强API。
distributed_schedule	分布式调度子系统。负责跨设备部件管理，提供访问和控制远程组件的能力，支持分布式场景下的应用协同。
security	安全子系统。包括系统安全、数据安全、应用安全等功能，为OpenHarmony提供有效保护应用和用户数据的能力。当前开源的功能，包括应用完整性保护、应用权限管理、设备认证、密钥管理服务、数据传输管控。
test	测试子系统。OpenHarmony为开发者提供了一套全面的自测试框架，开发者可根据测试需求开发相关测试用例，开发阶段提前发现缺陷，大幅提高代码质量。

移植启动恢复子系统

启动恢复子系统负责在内核启动之后到应用启动之前的系统关键进程和服务的启动过程的功能。

移植指导

针对轻量系统主要提供了各服务和功能的启动入口标识。在SAMGR启动时，会调用bootstrap标识的入口函数，并启动系统服务。

适配完成后，调用OHOS_SystemInit()接口，即可启动系统。

路径：“base/startup/bootstrap_lite/services/source/system_init.c”

void OHOS_SystemInit(void)
{
    MODULE_INIT(bsp);           //执行.zinitcall.bspX.init段中的函数
    MODULE_INIT(device);        //执行.zinitcall.deviceX.init段中的函数
    MODULE_INIT(core);          //执行.zinitcall.coreX.init段中的函数
    SYS_INIT(service);          //执行.zinitcall.sys.serviceX.init段中的函数
    SYS_INIT(feature);          //执行.zinitcall.sys.featureX.init段中的函数
    MODULE_INIT(run);           //执行.zinitcall.runX.init段中的函数
    SAMGR_Bootstrap();          //SAMGR服务初始化
}

移植实例

在“config.json”中添加启动子系统。

路径：“vendor/MyVendorCompany/MyProduct/config.json”

修改如下：

    {
        "subsystem": "startup",
        "components": [
            { "component": "bootstrap_lite", "features":[] },
            { "component": "syspara_lite", "features":[] }
        ]
    },

在startup子系统中有部分部件（如：syspara_lite等），会依赖“$ohos_product_adapter_dir/utils”中的模块。其中“ohos_product_adapter_dir”就是在config.json文件中配置的“product_adapter_dir”，我们通常配置其为“vendor/MyVendorCompany/MyProduct/hals”。

添加zinitcall以及run定义。在厂商ld链接脚本中.text段中，添加如下代码：

        __zinitcall_bsp_start = .;
        KEEP (*(.zinitcall.bsp0.init))
        KEEP (*(.zinitcall.bsp1.init))
        KEEP (*(.zinitcall.bsp2.init))
        KEEP (*(.zinitcall.bsp3.init))
        KEEP (*(.zinitcall.bsp4.init))
        __zinitcall_bsp_end = .;
        __zinitcall_device_start = .;
        KEEP (*(.zinitcall.device0.init))
        KEEP (*(.zinitcall.device1.init))
        KEEP (*(.zinitcall.device2.init))
        KEEP (*(.zinitcall.device3.init))
        KEEP (*(.zinitcall.device4.init))
        __zinitcall_device_end = .;
        __zinitcall_core_start = .;
        KEEP (*(.zinitcall.core0.init))
        KEEP (*(.zinitcall.core1.init))
        KEEP (*(.zinitcall.core2.init))
        KEEP (*(.zinitcall.core3.init))
        KEEP (*(.zinitcall.core4.init))
        __zinitcall_core_end = .;
        __zinitcall_sys_service_start = .;
        KEEP (*(.zinitcall.sys.service0.init))
        KEEP (*(.zinitcall.sys.service1.init))
        KEEP (*(.zinitcall.sys.service2.init))
        KEEP (*(.zinitcall.sys.service3.init))
        KEEP (*(.zinitcall.sys.service4.init))
        __zinitcall_sys_service_end = .;
        __zinitcall_sys_feature_start = .;
        KEEP (*(.zinitcall.sys.feature0.init))
        KEEP (*(.zinitcall.sys.feature1.init))
        KEEP (*(.zinitcall.sys.feature2.init))
        KEEP (*(.zinitcall.sys.feature3.init))
        KEEP (*(.zinitcall.sys.feature4.init))
        __zinitcall_sys_feature_end = .;
        __zinitcall_run_start = .;
        KEEP (*(.zinitcall.run0.init))
        KEEP (*(.zinitcall.run1.init))
        KEEP (*(.zinitcall.run2.init))
        KEEP (*(.zinitcall.run3.init))
        KEEP (*(.zinitcall.run4.init))
        __zinitcall_run_end = .;
        __zinitcall_app_service_start = .;  //SAMGR执行.zinitcall.app.serviceX.init段中的函数
        KEEP (*(.zinitcall.app.service0.init))
        KEEP (*(.zinitcall.app.service1.init))
        KEEP (*(.zinitcall.app.service2.init))
        KEEP (*(.zinitcall.app.service3.init))
        KEEP (*(.zinitcall.app.service4.init))
        __zinitcall_app_service_end = .;
        __zinitcall_app_feature_start = .; //SAMGR执行.zinitcall.app.featureX.init段中的函数
        KEEP (*(.zinitcall.app.feature0.init))
        KEEP (*(.zinitcall.app.feature1.init))
        KEEP (*(.zinitcall.app.feature2.init))
        KEEP (*(.zinitcall.app.feature3.init))
        KEEP (*(.zinitcall.app.feature4.init))
        __zinitcall_app_feature_end = .;
        __zinitcall_test_start = .;
        KEEP (*(.zinitcall.test0.init))
        KEEP (*(.zinitcall.test1.init))
        KEEP (*(.zinitcall.test2.init))
        KEEP (*(.zinitcall.test3.init))
        KEEP (*(.zinitcall.test4.init))
        __zinitcall_test_end = .;
        __zinitcall_exit_start = .;
        KEEP (*(.zinitcall.exit0.init))
        KEEP (*(.zinitcall.exit1.init))
        KEEP (*(.zinitcall.exit2.init))
        KEEP (*(.zinitcall.exit3.init))
        KEEP (*(.zinitcall.exit4.init))
        __zinitcall_exit_end = .;

芯片SDK创建任务。配置任务参数，系统启动后，启动任务，示例如下：

    void mainTask(void) {
       //厂商自定义功能
        OHOS_SystemInit();        //启动子系统初始化
        printf("MainTask running...\n");
    }

    void main(VOID) {
       //硬件初始化，printf输出重定向到debug串口等
        if (LOS_KernelInit() == 0) {            //ohos内核初始化
            task_init_param.usTaskPrio = 10;    //任务优先级
            task_init_param.pcName = "mainTask"; //任务进程名
            task_init_param.pfnTaskEntry = (TSK_ENTRY_FUNC)mainTask; //任务入口函数
            task_init_param.uwStackSize = 8192;          //任务栈大小
            LOS_TaskCreate(&tid, &task_init_param);      //创建任务
            LOS_Start();                                 //启动任务
        }
        else {
            printf("[BUG] LOS_KernelInit fail\n");
        }
        printf("[BUG] reach to unexpected code\n");
        while (1);
    }

移植文件子系统

utils部件可被各业务子系统及上层应用使用，依赖芯片文件系统实现，需要芯片平台提供文件打开、关闭、读写、获取大小等功能。

移植指导

OpenHarmony文件系统需要适配如下HAL层接口：

表1 文件打开或关闭

接口名	描述
HalFileOpen	文件打开或创建新文件。
HalFileClose	文件关闭。

表2 文件操作

接口名	描述
HalFileRead	读文件。
HalFileWrite	写文件。
HalFileDelete	删除文件。
HalFileStat	获取文件属性。
HalFileSeek	文件查找。

厂商适配相关接口的实现，请参考OpenHarmony中file的接口和hal层适配接口的定义：

//utils/native/lite/file
├── BUILD.gn
└── src
     └── file_impl_hal
            └── file.c             #file接口

//utils/native/lite/hals
└── file
└── hal_file.h                   #hal层接口头文件

其中BUILD.gn的内容如下：

import("//build/lite/config/component/lite_component.gni")

static_library("native_file") {
  sources = [
    "src/file_impl_hal/file.c",
  ]
  include_dirs = [
    "//utils/native/lite/include",
    "//utils/native/lite/hals/file",
  ]
  deps = ["$ohos_vendor_adapter_dir/hals/utils/file:hal_file_static"]  #依赖厂商的适配
}

lite_component("file") {
  features = [
    ":native_file",
  ]
}

从中可以看到厂商适配相关接口的存放目录应为“$ohos_vendor_adapter_dir/hals/utils/file”，且该目录下BUILD.gn文件中的目标应为hal_file_static。

通常厂商可以采用下面三种方式适配hal层接口：

直接flash读写，模拟文件的操作。
使用littlefs或者fatfs文件系统进行适配，littlefs或者fatfs都是轻量级文件系统适配简单，其中OpenHarmony的“//thirdparty”目录下已有fatfs可供参考。
使用厂商已有的文件系统进行适配。

移植实例

“config.json”添加文件系统。路径：“vendor/MyVendorCompany/MyProduct/config.json”

修改如下：

    {
    "subsystem": "utils",
    "components": [
        { "component": "file", "features":[] }
      ]
    },

添加适配文件。在“vendor/MyVendorCompany/MyProduct/config.json”文件中，vendor_adapter_dir配置项通常进行如下配置：

“vendor_adapter_dir”: “//device/MyDeviceCompany/MyBoard/adapter”。

在该目录下进行UtilsFile接口适配：

    hals/utils/file
    ├── BUILD.gn
    └── src
        └── hal_file.c

其中BUILD.gn内容如下：

import("//build/lite/config/component/lite_component.gni")
    static_library("hal_file_static") {     #目标名
      sources = [ "src/hal_file.c" ]        #厂商适配的源文件
      include_dirs = [
        "//utils/native/lite/hals/file",
      ]
    }

鸿蒙全栈开发全新学习指南

之前总有很多小伙伴向我反馈说，不知道学习哪些鸿蒙开发技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？而且学习时频繁踩坑，最终浪费大量时间。所以这里为大家准备了一份实用的鸿蒙（HarmonyOS NEXT）学习路线与学习文档用来跟着学习是非常有必要的。

针对一些列因素，整理了一套纯血版鸿蒙（HarmonyOS Next）全栈开发技术的学习路线，包含了鸿蒙开发必掌握的核心知识要点，内容有（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、WebGL、元服务、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、OpenHarmony驱动开发、系统定制移植等等）鸿蒙（HarmonyOS NEXT）技术知识点。

本路线共分为四个阶段：

第一阶段：鸿蒙初中级开发必备技能

在这里插入图片描述

第二阶段：鸿蒙南北双向高工技能基础：`gitee.com/MNxiaona/733GH`

第三阶段：应用开发中高级就业技术

第四阶段：全网首发-工业级南向设备开发就业技术：`gitee.com/MNxiaona/733GH`

《鸿蒙 (Harmony OS)开发学习手册》（共计892页）

如何快速入门？

1.基本概念
2.构建第一个ArkTS应用
3.……

开发基础知识:`gitee.com/MNxiaona/733GH`

1.应用基础知识
2.配置文件
3.应用数据管理
4.应用安全管理
5.应用隐私保护
6.三方应用调用管控机制
7.资源分类与访问
8.学习ArkTS语言
9.……

基于ArkTS 开发

1.Ability开发
2.UI开发
3.公共事件与通知
4.窗口管理
5.媒体
6.安全
7.网络与链接
8.电话服务
9.数据管理
10.后台任务(Background Task)管理
11.设备管理
12.设备使用信息统计
13.DFX
14.国际化开发
15.折叠屏系列
16.……

鸿蒙开发面试真题（含参考答案）:`gitee.com/MNxiaona/733GH`

鸿蒙入门教学视频：

美团APP实战开发教学：`gitee.com/MNxiaona/733GH`

写在最后

如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
点赞，转发，有你们的『点赞和评论』，才是我创造的动力。
关注小编，同时可以期待后续文章ing🚀，不定期分享原创知识。
想要获取更多完整鸿蒙最新学习资源，请移步前往小编：gitee.com/MNxiaona/733GH

OpenHarmony_小贾

关注

3
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
OpenHarmony（鸿蒙南向开发）——移植子系统(一)

OpenHarmony系统功能按照“系统 > 子系统 > 部件”逐级展开，支持根据实际需求裁剪某些非必要的部件，本文以部分子系统、部件为例进行介绍。若想使用OpenHarmony系统的能力，需要对相应子系统进行适配。OpenHarmony芯片适配常见子系统列表如下（详见表1），需结合具体芯片再做增删减操作。表1 OpenHarmony子系统子系统作用应用程序demo。可将应用相关源码存放在此目录下。kernel内核子系统。负责任务调度、内存管理等常见的内核功能。hiviewdfx。
复制链接

扫一扫