概述
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"
scss
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"
修改如下:
ruby
{
"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段中,添加如下代码:
ini
__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创建任务。 配置任务参数,系统启动后,启动任务,示例如下:
scss
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);
}
DD一下: 欢迎大家关注公众号<程序猿百晓生>,可以了解到以下内容:
erlang
1.OpenHarmony开发基础
2.OpenHarmony北向开发环境搭建
3.鸿蒙南向开发环境的搭建
4.鸿蒙生态应用开发白皮书V2.0 & V3.0
5.鸿蒙开发面试真题(含参考答案)
6.TypeScript入门学习手册
7.OpenHarmony 经典面试题(含参考答案)
8.OpenHarmony设备开发入门【最新版】
9.沉浸式剖析OpenHarmony源代码
10.系统定制指南
11.【OpenHarmony】Uboot 驱动加载流程
12.OpenHarmony构建系统--GN与子系统、部件、模块详解
13.ohos开机init启动流程
14.鸿蒙版性能优化指南
.......
移植文件子系统
utils部件可被各业务子系统及上层应用使用,依赖芯片文件系统实现,需要芯片平台提供文件打开、关闭、读写、获取大小等功能。
移植指导
OpenHarmony文件系统需要适配如下HAL层接口:
表1 文件打开或关闭
接口名 | 描述 |
---|---|
HalFileOpen | 文件打开或创建新文件。 |
HalFileClose | 文件关闭。 |
表2 文件操作
接口名 | 描述 |
---|---|
HalFileRead | 读文件。 |
HalFileWrite | 写文件。 |
HalFileDelete | 删除文件。 |
HalFileStat | 获取文件属性。 |
HalFileSeek | 文件查找。 |
厂商适配相关接口的实现,请参考OpenHarmony中file的接口和hal层适配接口的定义:
ruby
//utils/native/lite/file
├── BUILD.gn
└── src
└── file_impl_hal
└── file.c #file接口
ruby
//utils/native/lite/hals
└── file
└── hal_file.h #hal层接口头文件
其中BUILD.gn的内容如下:
scss
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"
修改如下:
ruby
{
"subsystem": "utils",
"components": [
{ "component": "file", "features":[] }
]
},
- 添加适配文件。 在"vendor/MyVendorCompany/MyProduct/config.json"文件中,vendor_adapter_dir配置项通常进行如下配置:
"vendor_adapter_dir": "//device/MyDeviceCompany/MyBoard/adapter"。
在该目录下进行UtilsFile接口适配:
bash
hals/utils/file
├── BUILD.gn
└── src
└── hal_file.c
其中BUILD.gn内容如下:
ini
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",
]
}