鸿蒙开发知识记录

OpenHarmony内核提供的Shell支持调试常用的基本功能，包含系统、文件、网络相关命令。同时OpenHarmony内核的Shell支持添加新的命令，可以根据需求来进行定制。

Trace调测旨在帮助开发者获取内核的运行流程，各个模块、任务的执行顺序，从而可以辅助开发者定位一些时序问题或者了解内核的代码运行过程。

内存调测方法旨在辅助定位动态内存相关问题，提供了基础的动态内存池信息统计手段，向用户呈现内存池水线、碎片率等信息；提供了内存泄漏检测手段，方便用户准确定位存在内存泄漏的代码行，也可以辅助分析系统各个模块内存的使用情况；提供了踩内存检测手段，可以辅助定位越界踩内存的场景。

通过VFS层提供了POSIX标准的操作，保持了接口的一致性，但是因为M核的资源非常紧张，VFS层非常轻薄，没有提供类似A核的高级功能（如pagecache等），主要是接口的标准化和适配工作，具体的事务由各个文件系统实际承载。加载过程中，根据ELF文件的句柄以及程序头表的段偏移可以得到需要加载到内存的LOAD段，一般有两个段，只读段及读写段，如下所示，可以用readelf -l查看ELF文件的LOAD段信息。如图3所示，根据相应的对齐属性申请物理内存，通过每个段的加载基址及偏移将代码段或数据段写入内存中。

时间管理以系统时钟为基础，给应用程序提供所有和时间有关的服务。系统时钟是由定时器/计数器产生的输出脉冲触发中断产生的，一般定义为整数或长整数。输出脉冲的周期叫做一个“时钟滴答”。系统时钟也称为时标或者Tick。

由事件初始化函数配置的一个结构体，在事件读写等操作时作为参数传入，用于标识不同的事件，控制块数据结构如下：

从系统角度看，任务是竞争系统资源的最小运行单元。任务可以使用或等待CPU、使用内存空间等系统资源，各任务的运行相互独立。

在程序运行过程中，出现需要由CPU立即处理的事务时，CPU暂时中止当前程序的执行转而处理这个事务，这个过程叫做中断。当硬件产生中断时，通过中断号查找到其对应的中断处理程序，执行中断处理程序完成中断处理。

用户最常见到并与之交互的操作系统界面，其实只是操作系统最外面的一层。操作系统最重要的任务，包括管理硬件设备，分配系统资源等，我们称之为操作系统内在最重要的核心功能。而实现这些核心功能的操作系统模块，业界一般称之为操作系统“内核”。OpenHarmony的Linux内核基于开源Linux内核LTS分支演进，在此基线基础上，回合CVE补丁及OpenHarmony特性，作为OpenHarmony Common Kernel基线。针对不同的芯片，各厂商合入对应的板级驱动补丁，完成对OpenHarmony的基线适配。

本文以OpenHarmony 3.0为基础，讲解基于HDF(Hardware Driver Foundation)驱动框架开发的Audio驱动框架，包括Audio驱动的架构组成、功能部件的实现和服务节点详细介绍。音频驱动框架模型，向上服务于多媒体音频子系统，便于系统开发者能够更便捷的根据场景来开发应用。向下服务于具体的设备厂商，对于Codec和DSP设备厂商来说，可根据ADM模块提供的向下统一接口适配各自的驱动代码，就可以实现快速开发和适配HOS系统。接收lib层的控制指令并将控制指令分发到驱动层。

OpenHarmony Camera驱动模型结构HDI Implementation：对上实现HDI接口，向下调用框架层的接口，完成HDI接口任务的转发。Buffer Manager：屏蔽不同内存管理的差异，为子系统提供统一的操作接口，同时提供buffer轮转的功能。Pipeline Core：解析HCS配置完成pipeline的搭建，调度pipeline中的各个node完成流的处理Device Manager：通过调用底层硬件适配层接口，实现查询控制底层设备、枚举监听底层设备的功能。

本文章是基于瑞芯微RK3566芯片的khdvk_3566b开发板，进行标准系统相关功能的移植，主要包括产品配置添加，内核启动、升级，音频ADM化，Camera，TP，LCD，WIFI，BT，vibrator、sensor、图形显示模块的适配案例总结，以及相关功能的适配。二级启动简单来说就是将之前直接挂载sytem，从system下的init启动，改成先挂载ramdsik，从ramdsik中的init 启动，做些必要的初始化动作，如挂载system,vendor等分区，然后切到system下的init。

调试AP模块时，无法正常开启AP功能的解决方法。

主要完成Codec/DMA/I2S驱动注册，使得ADM可以加载驱动节点；并注册ADM与Drivers交互的接口函数主要完成ADM Drivers adapter接口函数的实现，以及Codec_config.hcs/dai_config.hcs等配置信息的获取，并注册到对应的设备ADM Drivers impl可以直接阅读硬件手册，完成驱动端到端的配置；也可以借用Linux原生驱动实现与接口，减少开发者工作量。

本文章基于意法半导体STM32MP157芯片的小熊派BearPi-HM Micro开发板，进行小型带屏开发板的移植，实现了ace_engine_lite、arkui_ui_lite、aafwk_lite、appexecfwk_lite、HDF等部件基于OpenHarmony LiteOS-A内核的适配。移植架构上采用Board与SoC分离的方案。

文件下，描述了产品使用的内核、单板、子系统等信息。其中，内核、单板型号、单板厂商需提前规划好，是预编译指令hb set关注的。"product_name": "neptune_iotlink_demo", --- 产品名"ohos_version": "OpenHarmony 3.1", --- 使用的OS版本"type":"mini", --- 系统类型: mini"version": "3.0", --- 系统版本: 3.0。

bootstrap_lite部件会编译//base/startup/bootstrap_lite/services/source/bootstrap_service.c，该文件中，通过SYS_SERVICE_INIT将Init函数符号灌段到__zinitcall_sys_service_start和__zinitcall_sys_service_end中，由于Init函数是没有显式调用它，所以需要将它强制链接到最终的镜像。

以vendor/chipsea/iotlink_demo为例，这里描述了产品使用的内核、单板、子系统等信息。其中，内核、单板型号、单板厂商需要提前规划好，也是预编译指令所关注的信息。这里填入的信息与规划的目录相对应。"product_name": "iotlink_demo", --- 产品名"version": "3.0", --- 系统版本：3.0"device_company": "chipsea", --- 单板厂商：chipsea。

以为例，这里描述了产品使用的内核、单板、子系统等信息。其中，内核、单板型号、单板厂商需要提前规划好，也是预编译指令（hb set）所关注的。这里填入的信息与规划的目录相对应。"product_name": "wifi_demo", --- 产品名"type": "mini", --- 系统类型: mini"version": "3.0", --- 系统版本: 3.0"device_company": "lango", --- 单板厂商：lango。

huks部件适配时，huks_key_store_path配置选项用于指定存放秘钥路径，ohos_security_huks_mbedtls_porting_path配置选项用于指定进行mbedtls适配的目录，用于芯片对mbedtls进行硬件随机数等适配。graphic配置文件见 //vendor/bestechnic/display_demo/graphic_config/product_graphic_lite_config.h。在本次适配过程中，将其调整为0x1000。

其中OHOS_SYSROOT_PATH需用绝对路径指定出sysroot所在目录，以OpenHarmony为例即源码根目录下out/hispark_xxx/ipcamera_hispark_xxx/sysroot目录的绝对路径。上述目录会在全量编译后生成，因此移植前先完成一次全量编译。yxml库添加的过程除了适配文件build.gn和config.gni有些许变化外，其他和double-conversion库完全一致，参考CMake方式组织编译的库移植的配置过程。

本文为OpenHarmony开发者提供一些组织编译形式比较常见（CMakeLists、Makefile）的三方库的移植指南，该指南当前仅适用于Hi3516DV300和Hi3518EV300两个平台，文中着重介绍各编译组织方式下工具链的设置方法以及如何将该库的编译添加到OpenHarmony整个工程的构建中。

本文面向希望将OpenHarmony移植到三方芯片平台硬件的开发者，介绍一种借助三方芯片平台自带Linux内核的现有能力，快速移植OpenHarmony到三方芯片平台的方法。

本文以移植名为MyProduct的开发板为例讲解移植过程，假定MyProduct是MyProductVendor公司的开发板，使用MySoCVendor公司生产的MySOC芯片作为处理器。在名称的目录下创建一个config.json文件，该文件用于描述产品所使用的SOC 以及所需的子系统。配置如下：},...主要的配置内容配置项说明（必填）产品名称version（必填）版本type（必填）配置的系统级别，包含（small、standard等)target_cpu。

驱动主要包含两部分，平台驱动和器件驱动。平台驱动主要包括通常在SOC内的GPIO、I2C、SPI等；器件驱动则主要包含通常在SOC外的器件，如 LCD、TP、WLAN等图1OpenHarmony 驱动分类HDF驱动被设计为可以跨OS使用的驱动程序，HDF驱动框架会为驱动达成这个目标提供有力的支撑。开发HDF驱动中，请尽可能只使用HDF驱动框架提供的接口

LiteOS-A当前支持ARMv7-a指令集架构，如果三方芯片为ARMv7-a架构，可以进行内核基础适配；否则还需要先根据芯片的架构来新增内核对该芯片架构的支持，这个工作较为复杂，不在这篇文章范围内。Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后，进行基础的内核编译构建及验证。

本文详细介绍如何将OpenHarmony小型系统的linux和LiteOS-A内核移植到新的开发板上，要求读者具有一定的嵌入式系统开发经验。建议先查看 入门指导 ，以了解OpenHarmony软件架构、目录结构、内核子系统和驱动子系统相关知识。当前小型系统已适配的开发板如下表所示

芯片架构的移植是内核移植的基础，在OpenHarmony中芯片架构移植是可选过程，如果当前OpenHarmony已经支持对应芯片架构则不需要移植操作，在“liteos_m/arch”目录下可看到当前已经支持的架构，如表1：

OpenHarmony芯片移植完成后，需要开展OpenHarmony兼容性测试以及芯片SDK功能性测试。除可获得测试认证之外，还可以在开发阶段提前发现缺陷，大幅提高代码质量。

OpenHarmony提供了mbedtls的开源三方库，路径为“//third_party/mbedtls”。此库中提供了“mbedtls_platform_entropy_poll”、“mbedtls_hardclock_poll”、“mbedtls_havege_poll”、“mbedtls_hardware_poll”等几种产生随机数的方式。厂商需要根据芯片适配“mbedtls_hardware_poll”方式。

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

在链接选项中，需要链接生成于“out/MyBoard/MyProduct/libs”目录下的 XTS 的.a 库，其库的名称格式为 libmodule_ActsXxxTest.a，链接方式为"-lmodule_ActsXxxTest",示例代码如下：

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

根据代码我们可以看出需要配置“MBEDTLS_NO_PLATFORM_ENTROPY”、“MBEDTLS_ENTROPY_HARDWARE_ALT”两个宏，才能编译硬件随机数的相关代码。路径：“third_party/mbedtls/library/entropy.c”

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

外设驱动子系统提供 OpenHarmony 专有的外部设备操作接口。本模块提供设备操作接口有：FLASH, GPIO, I2C, PWM, UART, WATCHDOG 等。OpenHarmony 提供了两种驱动适配方式：使用外设驱动子系统、使用 HDF 驱动框架。由于轻量级系统的资源有限，这里建议使用 IOT 子系统方式。

通信子系统目前涉及 Wi-Fi 和蓝牙适配，厂商应当根据芯片自身情况进行适配。

OpenHarmony 源码重要目录介绍见表 1 OpenHarmony 重要目录，其中 device 和 vendor 目录为芯片厂商和终端模组厂商工作区域（在 搭建编译框架 部分详细介绍）。表 1OpenHarmony 重要目录目录用途build编译框架所在目录。内核所在的目录，其中 arch 目录描述支撑的内核架构。device芯片厂商适配目录，其中“config.gni”描述当前芯片使用的 arch，工具链，编译链接选项等。vendor。

本文档从芯片适配的端到端视角，为芯片/模组制造商提供基于 OpenHarmony 的芯片适配指导。典型的芯片架构，例如 cortex-m、risc-v 系列都可以按照本文档进行适配移植。

芯片架构的移植是内核移植的基础，在 OpenHarmony 中芯片架构移植是可选过程，如果当前 OpenHarmony 已经支持对应芯片架构则不需要移植操作，在“liteos_m/arch”目录下可看到当前已经支持的架构，