鸿蒙OpenHarmony【HDF驱动开发流程】 子系统

HDF驱动开发流程

概述

HDF(Hardware Driver Foundation)驱动框架,为驱动开发者提供驱动框架能力,包括驱动加载、驱动服务管理、驱动消息机制和配置管理。并以组件化驱动模型作为核心设计思路,让驱动开发和部署更加规范,旨在构建统一的驱动架构平台,为驱动开发者提供更精准、更高效的驱动管理的开发环境,力求做到一次开发,多系统部署。

驱动加载

HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能。

驱动服务管理

HDF框架可以集中管理驱动服务,开发者可直接通过HDF框架对外提供的能力接口获取驱动相关的服务。

驱动消息机制

HDF框架提供统一的驱动消息机制,支持用户态应用向内核态驱动发送消息,也支持内核态驱动向用户态应用发送消息。

配置管理

HCS(HDF Configuration Source)是HDF驱动框架的配置描述源码,内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦,便于开发者进行配置管理。

驱动模型

HDF框架将一类设备驱动放在同一个Host(设备容器)里面,用于管理一组设备的启动加载等过程。在划分Host时,驱动程序是部署在一个Host还是部署在不同的Host,主要考虑驱动程序之间是否存在耦合性,如果两个驱动程序之间存在依赖,可以考虑将这部分驱动程序部署在一个Host里面,否则部署到独立的Host中是更好的选择。Device对应一个真实的物理设备。DeviceNode是设备的一个部件,Device至少有一个DeviceNode。每个DeviceNode可以发布一个设备服务。驱动即驱动程序,每个DevicdNode唯一对应一个驱动,实现和硬件的功能交互。HDF驱动模型如下图所示:

图1 HDF驱动模型

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

功能描述

驱动加载

HDF驱动框架提供把和配置的设备列表匹配成功的驱动程序加载起来的功能,支持按需加载和按序加载两种策略,具体设备的加载策略由配置文件中的preload字段来控制,配置值参考如下:

typedef enum {
    DEVICE_PRELOAD_ENABLE = 0,
    DEVICE_PRELOAD_ENABLE_STEP2 = 1,
    DEVICE_PRELOAD_DISABLE = 2,
    DEVICE_PRELOAD_INVALID
} DevicePreload;
c
按需加载
  • preload字段配置为0(DEVICE_PRELOAD_ENABLE),则系统启动过程中默认加载。
  • preload字段配置为1(DEVICE_PRELOAD_ENABLE_STEP2),当系统支持快速启动的时候,则在系统完成之后再加载这一类驱动,否则和DEVICE_PRELOAD_ENABLE含义相同。
  • preload字段配置为2(DEVICE_PRELOAD_DISABLE),则系统启动过程中默认不加载,支持后续动态加载,当用户态获取驱动服务[消息机制]时,如果驱动服务不存在,HDF框架会尝试动态加载该驱动。
按序加载(默认加载策略)

配置文件中的priority(取值范围为整数0到200)是用来表示host(驱动容器)和驱动的优先级的。不同的host内的驱动,host的priority值越小,驱动加载优先级越高;同一个host内驱动的priority值越小,加载优先级越高。

异常恢复(用户态驱动)

当驱动服务异常退出时,恢复策略如下:

  • preload字段配置为0(DEVICE_PRELOAD_ENABLE)或1(DEVICE_PRELOAD_ENABLE_STEP2)的驱动服务,由启动模块拉起host并重新加载服务。
  • preload字段配置为2(DEVICE_PRELOAD_DISABLE)的驱动服务,需业务模块注册HDF的服务状态监听器,当收到服务退出消息时,业务模块调用LoadDevice重新加载服务。

驱动服务管理

驱动服务是HDF驱动设备对外提供能力的对象,由HDF框架统一管理。驱动服务管理主要包含驱动服务的发布和获取。HDF框架定义了驱动对外发布服务的策略,由配置文件中的policy字段来控制,policy字段的取值范围以及含义如下:

typedef enum {
    /* 驱动不提供服务 */
    SERVICE_POLICY_NONE = 0,
    /* 驱动对内核态发布服务 */
    SERVICE_POLICY_PUBLIC = 1,
    /* 驱动对内核态和用户态都发布服务 */
    SERVICE_POLICY_CAPACITY = 2,
    /* 驱动服务不对外发布服务,但可以被订阅 */
    SERVICE_POLICY_FRIENDLY = 3,
    /* 驱动私有服务不对外发布服务,也不能被订阅 */
    SERVICE_POLICY_PRIVATE = 4,
    /* 错误的服务策略 */
    SERVICE_POLICY_INVALID
} ServicePolicy;
c
使用场景

当驱动需要以接口的形式对外提供能力时,可以使用HDF框架的驱动服务管理能力。

接口说明

针对驱动服务管理功能,HDF框架开放了以下接口供开发者调用,如下表所示:

表1 服务管理接口

方法 描述
int32_t (*Bind)(struct HdfDeviceObject *deviceObject) 需要驱动开发者实现Bind函数,将自己的服务接口绑定到HDF框架中。
const struct HdfObject *DevSvcManagerClntGetService(const char *svcName) 获取驱动的服务。
int HdfDeviceSubscribeService( struct HdfDeviceObject *deviceObject, const char *serviceName, struct SubscriberCallback callback) 订阅驱动的服务。

驱动消息机制管理

使用场景

当用户态应用和内核态驱动需要交互时,可以使用HDF框架的消息机制来实现。

接口说明

消息机制的功能主要有以下两种:

  • 用户态应用发送消息到驱动。
  • 用户态应用接收驱动主动上报事件。

表2 消息机制接口

方法 描述
struct HdfIoService *HdfIoServiceBind(const char *serviceName); 用户态获取驱动的服务,获取该服务之后通过服务中的Dispatch方法向驱动发送消息。
void HdfIoServiceRecycle(struct HdfIoService *service); 释放驱动服务。
int HdfDeviceRegisterEventListener(struct HdfIoService *target, struct HdfDevEventlistener *listener); 用户态程序注册接收驱动上报事件的操作方法。
int32_t HdfDeviceSendEvent(const struct HdfDeviceObject *deviceObject, uint32_t id, const struct HdfSBuf *data) 驱动主动上报事件接口。

配置管理

配置概述

HCS(HDF Configuration Source)是HDF驱动框架的配置描述源码,内容以Key-Value为主要形式。它实现了配置代码与驱动代码解耦,便于开发者进行配置管理。HC-GEN(HDF Configuration Generator)是HCS配置转换工具,可以将HDF配置文件转换为软件可读取的文件格式:

  • 在弱性能环境中,转换为配置树源码或配置树宏定义,驱动可直接调用C代码或宏式APIs获取配置。
  • 在高性能环境中,转换为HCB(HDF Configuration Binary)二进制文件,驱动可使用HDF框架提供的配置解析接口获取配置。

以下是使用HCB模式的典型应用场景:

图2 配置使用流程图

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

HCS经过HC-GEN编译生成HCB文件,HDF驱动框架中的HCS Parser模块会从HCB文件中重建配置树,HDF驱动模块使用HCS Parser提供的配置读取接口获取配置内容。

配置语法

HCS的语法介绍如下:

关键字

HCS配置语法保留了以下关键字。

表3 HCS配置语法保留关键字

关键字 用途 说明
root 配置根节点 -
include 引用其他HCS配置文件 -
delete 删除节点或属性 只能用于操作include导入的配置树
template 定义模板节点 -
match_attr 用于标记节点的匹配查找属性 解析配置时可以使用该属性的值查找到对应节点
基本结构

HCS主要分为属性(Attribute)和节点(Node)两种结构。

属性

属性即最小的配置单元,是一个独立的配置项。语法如下:

  attribute_name = value;
  • attribute_name是字母、数字、下划线的组合且必须以字母或下划线开头,字母区分大小写。

  • value的可用格式如下:

    • 数字常量,支持二进制、八进制、十进制、十六进制数,具体[数据类型]章节。
    • 字符串,内容使用双引号(“”)引用。
    • 节点引用。
  • attribute必须以分号(;)结束且必须属于一个node。

节点

节点是一组属性的集合,语法如下:

  node_name {
      module = "sample";
      ...
  }
  • node_name是字母、数字、下划线
<think>好的,用户是一位有丰富经验的Linux驱动工程师,想在RK3568上学习OpenHarmony南向开发。首先,我需要明确他的需求和背景。他可能已经熟悉Linux内核和驱动开发,但对OpenHarmony的架构、与Linux的区别以及如何快速上手南向开发还不熟悉。需要帮他整理一个学习规划,重点放在鸿蒙架构特性、与Linux的异同,以及设备适配的实践步骤上。 首先,用户需要了解OpenHarmony的架构特性,特别是分布式能力和轻量化设计。这可能包括LiteOS内核和Linux内核的区别,以及南向开发的组成部分。接下来,对比OpenHarmony和Linux的差异,比如内核选择、驱动框架、硬件抽象层等,这些对于他的驱动开发经验转换很重要。 然后,考虑到用户已经有Linux驱动经验,可以强调两者的异同点,帮助他快速迁移知识。比如,HDF驱动框架与Linux驱动的区别,以及如何将现有的驱动适配到HDF中。此外,工具链和编译系统的差异也是关键,比如使用hb和gn等工具。 接下来,学习路径需要分阶段。第一阶段是基础学习,包括文档阅读和开发环境搭建。第二阶段深入内核和驱动开发,重点放在HDF驱动迁移上。第三阶段是实践项目,通过具体案例巩固知识。最后是进阶扩展,了解更高级的特性和社区资源。 在实践步骤中,设备适配是关键。需要指导他如何创建HDF驱动,处理硬件差异,配置编译文件,调试和测试。同时,利用他的Linux经验,提供迁移现有驱动的方法,比如封装HDF接口或使用兼容层。 可能遇到的挑战包括HDF框架的学习曲线,以及内核差异带来的兼容性问题。需要建议他多参考官方文档和社区案例,逐步适应新的开发模式。此外,分布式能力的应用可能需要新的思维方式,不同于传统的Linux驱动开发。 总结来说,学习规划应结合他的现有经验,突出OpenHarmony的特有部分,分阶段逐步深入,强调实践和迁移方法,帮助他高效过渡到南向开发。</think>以下是为您量身定制的OpenHarmony南向开发学习规划(基于RK3568平台): --- ### 一、鸿蒙架构核心认知(1-2周) 1. **架构特性重点突破** - 掌握分布式能力:$$ \text{设备发现} \rightarrow \text{能力协商} \rightarrow \text{任务协同} $$ - 理解轻量化设计:内核层(LiteOS/Linux双内核选择策略)、系统服务层(差异化服务按需裁剪) - 南向开发定位:HDF驱动框架、KAL硬件抽象层、外设总线管理 2. **与Linux的差异对照表** $$ \begin{array}{|l|l|l|} \hline \text{维度} & \text{OpenHarmony} & \text{Linux} \\ \hline \text{内核选择} & \text{多内核支持(LiteOS/可选Linux)} & \text{单一Linux内核} \\ \hline \text{驱动框架} & \text{HDF分层解耦设计} & \text{传统字符/块设备驱动模型} \\ \hline \text{硬件抽象} & \text{KAL统一接口规范} & \text{直接操作寄存器/内核接口} \\ \hline \end{array} $$ --- ### 二、高效学习路径(4-6周) #### 阶段1:基础奠基 1. **文档精读** - [OpenHarmony Device Development](https://gitee.com/openharmony/docs) - RK3568芯片手册(重点关注GPIO/I2C/SPI等接口) 2. **环境搭建** ```bash # 推荐开发环境配置 $ python3 -m pip install --user ohpm $ hb set # 选择rk3568标准系统 ``` #### 阶段2:内核与驱动开发 1. **HDF驱动框架实践** ```c // 典型HDF驱动结构(对比Linux驱动) struct HdfDriverEntry g_sampleDriverEntry = { .moduleVersion = 1, .Bind = SampleDriverBind, // 类似probe函数 .Init = SampleDriverInit, // 设备初始化 .Release = SampleDriverRelease, }; ``` 2. **驱动迁移技巧** - Linux驱动代码 → 封装为HDF驱动(保留核心算法) - 寄存器操作 → 通过KAL接口访问 - 中断处理 → 使用OSAL抽象接口 #### 阶段3:设备适配实战 1. **外设驱动开发流程** $$ \text{需求分析} \Rightarrow \text{HDF驱动模板生成} \Rightarrow \text{硬件操作实现} \Rightarrow \text{编译配置} \Rightarrow \text{烧写验证} $$ 2. **调试技巧** - HDF日志分级控制:`hdf_log.h`中的HDF_LOG_DEBUG等级 - 系统级调试:`hilog`命令实时监控 --- ### 三、RK3568专项训练(2-3周) 1. **典型外设适配案例** - GPIO控制:对比Linux的sysfs接口与HDF的GPIO服务 - I2C设备驱动:重点理解HDF的DeviceResource配置 ```c /* HCS配置文件示例 */ sample_i2c_config { match_attr = "sample_i2c_driver"; busName = "i2c_6"; // 总线编号 regAddrType = 0; // 7位地址模式 } ``` 2. **性能优化方向** - 电源管理:利用鸿蒙分布式软总线实现低功耗协同 - 启动优化:对比Linux的init进程与鸿蒙的appspawn机制 --- ### 四、经验迁移策略(重点) 1. **Linux驱动工程师优势转化** - 硬件知识复用率:80%(寄存器操作/时序分析等) - 需要转变的思维: $$ \text{直接内核操作} \rightarrow \text{通过HDF服务调用} $$ $$ \text{Makefile/Kconfig} \rightarrow \text{BUILD.gn/HCS配置} $$ 2. **快速适配checklist** - [ ] HDF驱动模型选择(字符设备/平台设备) - [ ] OSAL接口适配(内存管理/线程同步) - [ ] 设备树配置转换(.dts → .hcs) --- ### 五、持续提升路径 1. **进阶方向建议** - 分布式能力开发:研究`Distributed Hardware`子系统 - 安全机制:掌握HUKS与权限验证体系 2. **推荐学习资源** - OpenHarmony SIG仓:[drivers_peripheral](https://gitee.com/openharmony/drivers_peripheral) - 官方训练营:[RK3568开发板实战课程] 建议每周投入15-20小时,重点突破HDF框架和分布式特性,您的Linux驱动经验可缩短50%以上的学习周期。遇到具体开发问题时,可优先查阅`drivers_framework`仓的参考实现。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值