OpenHarmony设备开发 小型系统芯片移植指导

zh_ff
发布于 2023-3-22 10:56
浏览
0收藏

移植须知

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

表1 OpenHarmony小型系统已适配的开发板

开发板

内核

arch

ROM

RAM

文件系统

Flash 类型

hispark_taurus

LiteOS-A和linux-4.19

ARM cortex-a7

8G

1GB

VFAT、EXT4

eMMC4.5

hispark_aries

LiteOS-A

ARM cortex-a7

16M

512M

JFFS2

SPI NOR

表1中的开发板可作为待移植开发板的参考,当前LiteOS-A和linux-4.19支持的arch、ROM占用、支持的文件系统和支持的Flash类型如下表所示:

表2 OpenHarmony小型系统内核移植信息表

内核

支持的arch

ROM

文件系统

Flash类型

LiteOS-A

ARMv7

> 2M

VFAT、JFFS2、YAFFS2

SPI NOR、NAND、EMMC

linux-4.19

ARM, ARM64、 MIPS、 X86等

> 5M

VFAT、JFFS2、YAFFS、EXT/2/3/4、NFS等等

NOR、NAND、EMMC等

编译构建

编译环境搭建

首先请搭建OpenHarmony基础环境,相关操作请参考​​快速入门环境搭建章节​​。用户态和LiteOS-A的内核态编译均使用llvm编译器编译,安装方法在搭建基础环境中已提供。若选择移植linux内核,请执行如下命令安装gcc-arm-linux-gnueabi交叉编译工具链,用于编译linux内核态镜像:

sudo apt-get install gcc-arm-linux-gnueabi

编译构建系统介绍

编译构建流程、编译脚本编写、目录规则、独立编译单个组件、独立编译芯片解决方案等介绍请见​​编译构建子系统介绍​​。

新建芯片解决方案

了解编译框架和搭建完编译环境后,请参考如下步骤新建芯片解决方案:

  1. 新建目录 芯片解决方案的目录规则为:device/{芯片解决方案厂商}/{开发板}。以海思的hispark_taurus开发板为例,在代码根目录执行如下命令建立目录:

mkdir -p device/hisilicon/hispark_taurus

芯片解决方案目录树的规则如下:

device                                      
└── company                         # 芯片解决方案厂商
    └── board                       # 开发板名称
        ├── BUILD.gn                # 编译脚本
        ├── hals                    # OS南向接口适配
        ├── linux                   # 可选,linux内核版本
        │   └── config.gni          # linux版本编译配置
        └── liteos_a                # 可选,liteos内核版本
            └── config.gni          # liteos_a版本编译配置

以hispark_taurus移植linux内核为例,目录树应该如下:

device                  
└── hisilicon             
    └── hispark_taurus          
        ├── BUILD.gn    
        ├── hals        
        ├── ......      
        └── linux    
            └── config.gni  

目录树建立后开发板相关的源码放到hispark_taurus目录下。

2.配置开发板编译选项 步骤1中的config.gni可配置开发板相关的编译选项,编译构建框架将会遵照该配置文件中的参数编译所有用户态OS组件。其中关键的字段说明如下:

kernel_type:            开发板使用的内核类型,例如:“liteos_a”, “liteos_m”, “linux”。
kernel_version:         开发板使用的内核版本,例如:“4.19”。
board_cpu:              开发板CPU类型,例如:“cortex-a7”, “riscv32”。
board_arch:             开发板芯片arch, 例如: “armv7-a”, “rv32imac”。
board_toolchain:        开发板自定义的编译工具链名称,例如:“gcc-arm-none-eabi”。若为空,则使用默认为ohos-clang。
board_toolchain_prefix:编译工具链前缀,例如:“gcc-arm-none-eabi”。
board_toolchain_type:  编译工具链类型,目前支持gcc和clang。例如:“gcc” ,“clang”。
board_cflags:          开发板配置的c文件编译选项。
board_cxx_flags:       开发板配置的cpp文件编译选项。
board_ld_flags:        开发板配置的链接选项。

还以海思的hispark_taurus开发板为例,对应的device/hisilicon/hispark_taurus/config.gni内容如下:

# Board CPU type, e.g. "cortex-a7", "riscv32".
board_cpu = "cortex-a7"

# Toolchain name used for system compiling.
# E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang,  riscv32-unknown-elf.
# Note: The default toolchain is "ohos-clang". It's not mandatory if you use the default toochain.
board_toolchain = "mips-linux-gnu-gcc"

# The toolchain path installed, it's not mandatory if you have added toolchain path to your ~/.bashrc.
board_toolchain_path = 
    rebase_path("//prebuilts/gcc/linux-x86/arm/arm-linux-ohoseabi-gcc/bin",
                root_build_dir)

# Compiler prefix.
board_toolchain_prefix = "arm-linux-ohoseabi-"

# Compiler type, "gcc" or "clang".
board_toolchain_type = "gcc"

# Board related common compile flags.
board_cflags = [
]
board_cxx_flags = [
]
board_ld_flags = []

# Board related headfiles search path.
board_include_dirs = []
board_include_dirs += [ rebase_path(
        "//prebuilts/gcc/linux-x86/arm/arm-linux-ohoseabi-gcc/target/usr/include",
        root_build_dir) ]

# Board adapter dir for OHOS components.
board_adapter_dir = ""

# Sysroot path.
board_configed_sysroot = ""

# Board storage type, it used for file system generation.
storage_type = "emmc"

3.编写开发板编译脚本 步骤1中的BUILD.gn为新增的开发板的编译入口,主要用于编译开发板相关的代码,主要为设备侧驱动、设备侧接口适配(媒体,图形等)和开发板的SDK等等。
海思的hispark_taurus开发板的device/hisilicon/hispark_taurus/BUILD.gn可写成:

# group名称建议与开发板名称一致
group("hispark_taurus") {   
  deps = [ "//kernel/linux/patches:linux_kernel" ] # 拉起内核编译
  deps += [
  ...... # 开发板其他编译单元
  ]
}

4.编译调试 在开发板目录下执行hb set和hb build即可启动芯片解决方案的编译,编译框架会以开发板下的BUILD.gn为入口启动编译。

LiteOS-A内核

移植概述

移植场景

LiteOS-A当前支持ARMv7-a指令集架构,如果三方芯片为ARMv7-a架构,可以进行内核基础适配;否则还需要先根据芯片的架构来新增内核对该芯片架构的支持,这个工作较为复杂,不在这篇文章范围内。

目录规范

LiteOS-A目录规范参考​​LiteOS-A 简介​​。

基础适配

LiteOS-A提供系统运行所需的系统初始化流程和定制化配置选项。移植过程中,需要关注初始化流程中跟硬件配置相关的函数。

如下图所示,LiteOS-A的初始化流程主要包含以下七步:

  1. 新增target_config.h文件,并且编写单板内存相关的配置宏DDR_MEM_ADDR和DDR_MEM_SIZE,分别表示内存起始地址和内存的长度,预链接脚本board.ld.S会根据这两个宏进行展开生成链接脚本board.ld。
  2. 新增定义MMU映射全局数组(g_archMmuInitMapping),指定各个内存段属性及虚实映射关系,内核启动阶段根据该表建立内存映射关系。
  3. 如果是多核,需要新增定义从核操作函数句柄(struct SmpOps),其中SmpOps->SmpCpuOn函数需要实现唤醒从核的功能;接着定义SmpRegFunc函数,调用LOS_SmpOpsSet接口进行句柄注册;最后通过启动框架完成注册过程,即LOS_MODULE_INIT(SmpRegFunc, LOS_INIT_LEVEL_EARLIEST)。
  4. 链接阶段根据链接脚本board.ld生成内核镜像。
  5. 单核CPU镜像运行入口为汇编文件reset_vector_up.S,多核CPU的入口为reset_vector_mp.S,在汇编文件中进行中断向量表初始化、MMU页表初始化等操作。
  6. reset_vector.S汇编代码最终会跳转到C语言的main函数,进行硬件时钟、软件定时器、内存和任务等初始化,这个过程会依赖target_config.h的特性宏配置,最后会创建SystemInit任务,并且开启任务调度OsSchedStart()。
  7. SystemInit任务在单板代码中实现,其中调用DeviceManagerStart函数进行HDF驱动初始化,这个过程会调用单板代码中的驱动配置文件hdf.hcs以及drivers源码实现

整体启动流程如下图所示:

图1 整体启动流程

OpenHarmony设备开发 小型系统芯片移植指导 -鸿蒙开发者社区

从图1中可以看到,内核基础适配需要单板进行适配的代码包含三部分:

  • 新增target_config.h文件,其中新增单板硬件配置参数和特性开关的配置参数,具体说明如下:
    表1target_config.h配置项说明

配置项

说明

OS_SYS_CLOCK

系统cycle的频率

DDR_MEM_ADDR

系统内存的起始地址

DDR_MEM_SIZE

系统内存的大小

PERIPH_PMM_BASE

外设寄存器的起始地址

PERIPH_PMM_SIZE

外设寄存器的长度大小

OS_HWI_MIN

系统中断最小值

OS_HWI_MAX

系统中断最大值

NUM_HAL_INTERRUPT_UART0

UART0中断号

UART0_REG_BASE

UART0寄存器基址

GIC_BASE_ADDR

GIC中断寄存器基址

GICD_OFFSET

GICD相对GIC基址的偏移地址

GICC_OFFSET

GICC相对GIC基址的偏移地址


  • SystemInit函数用于单板用户态业务初始化,典型的初始化场景如图2所示:
    图2业务启动流程
  • OpenHarmony设备开发 小型系统芯片移植指导 -鸿蒙开发者社区

  • main函数用于内核基础初始化和单板内核态业务初始化,流程如下图3所示,整体由内核启动框架主导初始化流程,图中浅蓝色部分为启动框架中可接受外部模块注册启动的阶段。

注意:

 同一层级内的模块不能有依赖关系。

图3内核启动框架

OpenHarmony设备开发 小型系统芯片移植指导 -鸿蒙开发者社区

表2 启动框架层级

层级

说明

LOS_INIT_LEVEL_EARLIEST

最早期初始化

说明:不依赖架构,单板以及后续模块会对其有依赖的纯软件模块初始化

例如:Trace模块

LOS_INIT_LEVEL_ARCH_EARLY

架构早期初始化

说明:架构相关,后续模块会对其有依赖的模块初始化,如启动过程中非必需的功能,建议放到LOS_INIT_LEVEL_ARCH层

LOS_INIT_LEVEL_PLATFORM_EARLY

平台早期初始化

说明:单板平台、驱动相关,后续模块会对其有依赖的模块初始化,如启动过程中必需的功能,建议放到LOS_INIT_LEVEL_PLATFORM层

例如:uart模块

LOS_INIT_LEVEL_KMOD_PREVM

内存初始化前的内核模块初始化

说明:在内存初始化之前需要使能的模块初始化

LOS_INIT_LEVEL_VM_COMPLETE

基础内存就绪后的初始化

说明:此时内存初始化完毕,需要进行使能且不依赖进程间通讯机制与系统进程的模块初始化

例如:共享内存功能

LOS_INIT_LEVEL_ARCH

架构后期初始化

说明:架构拓展功能相关,后续模块会对其有依赖的模块初始化

LOS_INIT_LEVEL_PLATFORM

平台后期初始化

说明:单板平台、驱动相关,后续模块会对其有依赖的模块初始化

例如:驱动内核抽象层初始化(mmc、mtd)

LOS_INIT_LEVEL_KMOD_BASIC

内核基础模块初始化

说明:内核可拆卸的基础模块初始化

例如:VFS初始化

LOS_INIT_LEVEL_KMOD_EXTENDED

内核扩展模块初始化

说明:内核可拆卸的扩展模块初始化

例如:系统调用初始化、ProcFS初始化、Futex初始化、HiLog初始化、HiEvent初始化、LiteIPC初始化

LOS_INIT_LEVEL_KMOD_TASK

内核任务创建

说明:进行内核任务的创建(内核线程,软件定时器任务)

例如:资源回收系统常驻任务的创建、SystemInit任务创建、CPU占用率统计任务创建

进行单板移植适配,推荐关注LOS_INIT_LEVEL_ARCH至LOS_INIT_LEVEL_KMOD_TASK之间的层级,且尽可能拆分初始化行为进行细化阶段注册。

说明:

 启动框架中同一层级内的注册模块不能有依赖关系,建议新增模块按照上述启动阶段进行模块初始化的拆分,按需注册启动。

可通过查看系统编译生成文件OHOS_Image.map中.rodata.init.kernel.*段内的符号表来了解当前已注册进内核启动框架中的各个模块初始化入口,以及检查新注册的模块初始化入口是否生效。

编程样例

在单板SDK文件中

/* 内核启动框架头文件 */
#include "los_init.h"
......

/* 新增模块的初始化函数 */
unsigned int OsSampleModInit(void)
{
    PRINTK("OsSampleModInit SUCCESS!\n");
    ......
}
......
/* 在启动框架的目标层级中注册新增模块 */
LOS_MODULE_INIT(OsSampleModInit, LOS_INIT_LEVEL_KMOD_EXTENDED);

验证

main core booting up...
OsSampleModInit SUCCESS!
releasing 1 secondary cores
cpu 1 entering scheduler
cpu 0 entering scheduler

根据上述系统启动阶段的打印可知,内核在启动时进行了该注册模块的初始化函数调用,完成该模块的初始化操作。

系统启动完毕后进入内核态shell,能够运行task命令能够正常显示即可。

OHOS # help
***shell commands:*

arp           cat           cd            chgrp         chmod         chown         cp            cpup          
date          dhclient      dmesg         dns           format        free          help          hwi           
ifconfig      ipdebug       kill          log           ls            lsfd          memcheck      mkdir         
mount         netstat       oom           partinfo      partition     ping          ping6         pmm           
pwd           reset         rm            rmdir         sem           shm           stack         statfs        
su            swtmr         sync          systeminfo    task          telnet        touch         umount        
uname         v2p           virstatfs     vmm           watch         writeproc     

Linux内核

移植概述

Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后,进行基础的内核编译构建及验证。

基本信息

当前Linux内核基线是基于Linux社区 4.19 LTS版本演进,合入CVE及bugfix补丁。具体信息参考​​代码库​​,对应repo工程代码路径为kernel/linux-4.19。

Bootloader

可以使用芯片厂商自带的Bootloader,或者是开源Uboot等加载内核镜像。比如为支持Hi3516DV300开发板,OpenHarmony引入的开源​​Uboot​​。

适配编译和烧录启动

  1. 准备内核config(特别是芯片相关的config)。 config文件所在源码目录:kernel/linux/config/
    以hi3516dv300芯片为例,可在对应的linux-4.19/arch/arm/configs/目录下新建<YOUR_CHIP>_small_defconfig,如hi3516dv300_small_defconfig表示针对hi3516dv300小型系统的defconfig。该config文件可以由基础defconfig文件small_common_defconfig与该芯片相关的config组合生成。
  2. 准备芯片补丁。 补丁文件所在源码目录:kernel/linux/patches/linux-4.19
    以hi3516dv300芯片为例,参考已有的patch目录hi3516dv300_small_patch目录,新建<YOUR_CHIP>_patch目录,放置相关芯片补丁,注意hdf.patch等驱动补丁。
  3. 编译。 具体内核编译入口脚本位于工程目录kernel/linux/patches/下面,版本级整编命令会通过BUILD.gn进入kernel_module_build.sh和kernel.mk,需要在这2个文件中针对性进行patch及defconfig文件路径、编译器、芯片架构、内核Image格式等的适配。
    通过编译错误日志调整补丁,典型错误场景:
    (1)补丁合入失败,出现冲突,需要进行上下文适配修改。
    (2)编译失败,内核版本差异(函数实现调整等)需要针对性进行内核适配。

注意:

  • 参考kernel.mk,在OpenHarmony工程的编译构建流程中会拷贝kernel/linux-4.19的代码环境后进行打补丁动作,在使用版本级编译命令前,需要kernel/linux-4.19保持原代码环境。
  • 对应拷贝后的目录位于: out/<***>/kernel/linux-4.19,可以在该目录下进行补丁的修改适配。

4.烧录启动。 由于不同芯片的开发板的烧录方式不一样,此处不表述具体的烧录方式。需要注意烧录的各镜像的大小及启动参数的配置,参考hi3516dv300采用uboot启动参数:

setenv bootargs 'mem=128M console=ttyAMA0,115200 root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait blkdevparts=mmcblk0:1M(boot),9M(kernel),50M(rootfs),50M(userfs)'

验证

调试init进程、启动shell和运行简单的用户态程序,验证内核移植是否成功。OpenHarmony小型系统的OS镜像结构以及linux用户态的启动流程如下图1所示:

图1 基于linux内核的OS镜像结构和用户态程序启动流程 

OpenHarmony设备开发 小型系统芯片移植指导 -鸿蒙开发者社区

基于上述流程,推荐按以下步骤完成验证:

1.制作根文件系统镜像。 请参考​​新建芯片解决方案和产品解决方案​​生成根文件系统镜像rootfs.img。从上图可以看到启动过程与产品配置强相关,在制作rootfs.img过程中请完成如下四种配置:

  • 组件配置 产品组件配置文件vendor/{company}/{product}/config.json需配置启动恢复子系统(startup)的init_lite组件和内核子系统的linux_4_1_9组件。
  • 系统服务配置 系统服务配置文件vendor/{company}/{product}/init_configs/init_xxx.cfg需要启动shell服务。
  • 文件系统配置 文件系统配置vendor/{company}/{product}/fs.yml中需要创建“/bin/sh -> mksh“和“/lib/ld-musl-arm.so.1 -> libc.so“软连接,这两个文件分别是shell可执行程序和可执行程序依赖的c库。
  • 启动配置 启动配置在vendor/{company}/{product}/init_configs/etc目录下,包括fstab、rsS和Sxxx文件,请按开发板实际情况配置。

编译完成后,可通过检查产品编译输出目录下的rootfs内容,确认rootfs.img文件生成是否符合预期。

2.调试init进程和shell。 烧录rootfs.img并调试init进程和shell,不同厂商的开发板的烧录工具和流程可能不同,请按芯片解决方案提供的流程进行烧录。烧录rootfs.img前请确认bootloader和linux内核启动正常。如果rootfs.img被内核正常挂载,接着将运行/bin/init程序,init进程为用户态的第一个应用程序,它的运行意味着用户态的开始。
init程序首先会调用/etc/init.d/rcS脚本,rcS脚本执行第一条命令为"/bin/mount -a”,该命令会加载fstab文件,在fstab中的命令执行完后rcS将顺序调用Sxxx脚本完成设备节点创建和扫描、文件权限配置等操作。
最后,init程序会读取init.cfg系统服务配置文件。根据步骤1中的设置,init程序将会启动shell。如果上述流程运行正常,系统则会进入shell。
若串口有如下版本号日志打印,则表示init程序启动正常:
图2init启动正常日志

OpenHarmony设备开发 小型系统芯片移植指导 -鸿蒙开发者社区

正常进入shell后执行ls命令,串口打印信息如下图:

图3 正常进入shell后输入ls命令串口打印

OpenHarmony设备开发 小型系统芯片移植指导 -鸿蒙开发者社区

3.配置NFS。 init进程和shell正常启动后,以服务端IP为192.168.1.22、客户端IP为192.168.1.4为例,可在根目录执行如下命令开启NFS:

ifconfig eth0 192.168.1.4 netmask 255.255.255.0
mkdir -p /storgage/nfs
mount -t nfs -o nolock,addr=192.168.1.22 192.168.1.22:/nfs /storage/nfs

移植概述

驱动主要包含两部分,平台驱动和器件驱动。平台驱动主要包括通常在SOC内的GPIO、I2C、SPI等;器件驱动则主要包含通常在SOC外的器件,如 LCD、TP、WLAN等

图1 OpenHarmony 驱动分类

OpenHarmony设备开发 小型系统芯片移植指导 -鸿蒙开发者社区

HDF驱动被设计为可以跨OS使用的驱动程序,HDF驱动框架会为驱动达成这个目标提供有力的支撑。开发HDF驱动中,请尽可能只使用HDF驱动框架提供的接口,否则会导致驱动丧失跨OS使用的特性。在开始驱动开发前,建议先了解​​HDF驱动框架​​。

平台驱动移植

在这一步,我们会在源码目录//device/vendor_name/soc_name/drivers 目录下创建平台驱动,如果你要移植的SOC的厂商还没有创建仓库的话,请联系​​sig-devboard​​创建。

建议的目录结构:

device
├── vendor_name
│   ├── drivers
│   │   │   ├── common
│   │   │   ├── Kconfig # 厂商驱动内核菜单入口
│   │   │   └── lite.mk # 构建的入口
│   ├── soc_name
│   │   ├── drivers
│   │   │   ├── dmac
│   │   │   ├── gpio
│   │   │   ├── i2c
│   │   │   ├── LICENSE
│   │   │   ├── mipi_dsi
│   │   │   ├── mmc
│   │   │   ├── pwm
│   │   │   ├── README.md # docs 如果需要的话
│   │   │   ├── README_zh.md
│   │   │   ├── rtc
│   │   │   ├── spi
│   │   │   ├── uart
│   │   │   └── watchdog
│   ├── board_name

HDF为所有的平台驱动都创建了驱动模型,移植平台驱动的主要工作是向模型注入实例。 这些模型你可以在源码目录//drivers/framework/support/platform/include中找到定义。

本节我们会以GPIO为例,讲解如何移植平台驱动,移植过程包含以下步骤:

  1. 创建GPIO驱动 在源码目录//device/vendor_name/soc_name/drivers/gpio中创建文件soc_name_gpio.c 内容模板如下:

#include "gpio_core.h"

// 定义GPIO结构体,如果需要的话
struct SocNameGpioCntlr {
    struct GpioCntlr cntlr;  // 这是HDF GPIO驱动框架需要的结构体
    int myData; // 以下是当前驱动自身需要的
};

// Bind 方法在HDF驱动中主要用户对外发布服务,这里我们不需要,直接返回成功即可
static int32_t GpioBind(struct HdfDeviceObject *device)
{
    (void)device;
    return HDF_SUCCESS;
}

// Init方法时驱动初始化的入口,我们需要在Init方法中完成模型实例的注册
static int32_t GpioInit(struct HdfDeviceObject *device)
{
    SocNameGpioCntlr *impl = CreateGpio(); // 你的创建代码
    ret = GpioCntlrAdd(&impl->cntlr);  // 注册GPIO模型实例
    if (ret != HDF_SUCCESS) {
        HDF_LOGE("%s: err add controller:%d", __func__, ret);
        return ret;
    }
    return HDF_SUCCESS;
}

// Release方法会在驱动卸载时被调用,这里主要完成资源回收
static void GpioRelease(struct HdfDeviceObject *device)
{
    // GpioCntlrFromDevice 方法能从抽象的设备对象中获得init方法注册进去的模型实例。
    struct GpioCntlr *cntlr = GpioCntlrFromDevice(device);
    //资源释放...
}

struct HdfDriverEntry g_gpioDriverEntry = {
    .moduleVersion = 1,
    .Bind = GpioBind,
    .Init = GpioInit,
    .Release = GpioRelease,
    .moduleName = "SOC_NAME_gpio_driver", // 这个名字我们稍后会在配置文件中用到,用来加载驱动。
};
HDF_INIT(g_gpioDriverEntry); // 注册一个GPIO的驱动入口

2.创建厂商驱动构建入口 如前所述device/vendor_name/drivers/lite.mk是厂商驱动的构建的入口。我们需要从这个入口开始,进行构建

#文件device/vendor_name/drivers/lite.mk

SOC_VENDOR_NAME := $(subst $/",,$(LOSCFG_DEVICE_COMPANY))
SOC_NAME := $(subst $/",,$(LOSCFG_PLATFORM))
BOARD_NAME := $(subst $/",,$(LOSCFG_PRODUCT_NAME))

# 指定SOC进行构建
LIB_SUBDIRS += $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/

3.创建SOC驱动构建入口

#文件device/vendor_name/soc_name/drivers/lite.mk

SOC_DRIVER_ROOT := $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/

# 判断如果打开了GPIO的内核编译开关
ifeq ($(LOSCFG_DRIVERS_HDF_PLATFORM_GPIO), y)
    # 构建完成要链接一个叫hdf_gpio的对象
    LITEOS_BASELIB += -lhdf_gpio
    # 增加构建目录gpio
    LIB_SUBDIRS    += $(SOC_DRIVER_ROOT)/gpio 
endif

# 后续其他驱动在此基础上追加

4.创建GPIO构建入口

include $(LITEOSTOPDIR)/config.mk
include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk

# 指定输出对象的名称,注意要与SOC驱动构建入口里的LITEOS_BASELIB 保持一致
MODULE_NAME := hdf_gpio

# 增加HDF框架的INCLUDE
LOCAL_CFLAGS += $(HDF_INCLUDE)

# 要编译的文件
LOCAL_SRCS += soc_name_gpio.c

# 编译参数
LOCAL_CFLAGS += -fstack-protector-strong -Wextra -Wall -Werror -fsigned-char -fno-strict-aliasing -fno-common

include $(HDF_DRIVER)

5.配置产品加载驱动 产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。
平台驱动请添加到platform的host中。

说明:

 moduleName要与驱动定义中的相同。

root {
    ...
    platform :: host {
        device_gpio :: device {
                device0 :: deviceNode {
                    policy = 0;
                    priority = 10;
                    permission = 0644;
                    moduleName = "SOC_NAME_gpio_driver"; 
                }
        }
    }
}

器件驱动移植

本章节讲解如何移植各类器件驱动。

LCD驱动移植

移植LCD驱动的主要工作是编写一个驱动,在驱动中生成模型的实例,并完成注册。

这些LCD的驱动被放置在源码目录//drivers/framework/model/display/driver/panel中。

  1. 创建Panel驱动 创建HDF驱动,在驱动初始化中调用RegisterPanel接口注册模型实例。如:

int32_t LCDxxEntryInit(struct HdfDeviceObject *object)
{
    struct PanelData *panel = CreateYourPanel();
    // 注册模型实例
    if (RegisterPanel(panel) != HDF_SUCCESS) {
        HDF_LOGE("%s: RegisterPanel failed", __func__);
        return HDF_FAILURE;
    }
    return HDF_SUCCESS;
}

struct HdfDriverEntry g_xxxxDevEntry = {
    .moduleVersion = 1,
    .moduleName = "LCD_XXXX",
    .Init = LCDxxEntryInit,
};

HDF_INIT(g_xxxxDevEntry);

2.配置加载panel驱动 产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。修改该文件,在display的host中,名为device_lcd的device中增加配置。

注意:

 moduleName 要与panel驱动中的moduleName相同。

root {
    ...
    display :: host {
        device_lcd :: device {
                deviceN :: deviceNode {
                    policy = 0;
                    priority = 100;
                    preload = 2;
                    moduleName = "LCD_XXXX";
                }
        }
    }
}

TP驱动移植

本节描述如何移植触摸屏驱动。触摸屏的器件驱动被放置在源码目录//drivers/framework/model/input/driver/touchscreen中。 移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。

详细的驱动开发指导,请参考 ​​TOUCHSCREEN开发指导​​。

  1. 创建触摸屏器件驱动 在上述touchscreen目录中创建名为touch_ic_name.c的文件。编写如下内容

#include "hdf_touch.h"

static int32_t HdfXXXXChipInit(struct HdfDeviceObject *device)
{
    ChipDevice *tpImpl = CreateXXXXTpImpl();
    if(RegisterChipDevice(tpImpl) != HDF_SUCCESS) { // 注册ChipDevice模型
        ReleaseXXXXTpImpl(tpImpl);
        return HDF_FAILURE;
    }
    return HDF_SUCCESS;
}

struct HdfDriverEntry g_touchXXXXChipEntry = {
    .moduleVersion = 1,
    .moduleName = "HDF_TOUCH_XXXX", // 注意这里的moduleName要与后续的配置完全一致
    .Init = HdfXXXXChipInit,
};

HDF_INIT(g_touchXXXXChipEntry);

其中ChipDevice中要实现如下方法:

方法

实现说明

int32_t (*Init)(ChipDevice *device)

实现器件初始化

int32_t (*Detect)(ChipDevice *device)

实现器件探测

int32_t (*Suspend)(ChipDevice *device)

实现器件休眠

int32_t (*Resume)(ChipDevice *device)

实现器件唤醒

int32_t (*DataHandle)(ChipDevice *device)

需要实现从器件读取数据,将触摸点数据填写入device->driver->frameData中

int32_t (*UpdateFirmware)(ChipDevice *device)

实现固件升级

2.配置产品,加载器件驱动 产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。修改该文件,在名为input的host中,名为device_touch_chip的device中增加配置。

说明:

 moduleName 要与触摸屏驱动中的moduleName相同。

WLAN驱动移植

WLAN驱动分为两部分,一部分负责管理WLAN设备,另一个部分负责处理WLAN流量。

图1 OpenHarmony WLAN结构示意图 

OpenHarmony设备开发 小型系统芯片移植指导 -鸿蒙开发者社区

如图1,左半部分负责管理WLAN设备,右半部分负责WLAN流量。HDF WLAN分别为这两部分做了抽象,驱动的移植过程可以看做分别实现这两部分所需接口。这些接口有:

接口

定义头文件

接口说明

HdfChipDriverFactory

drivers\framework\include\wifi\hdf_wlan_chipdriver_manager.h

ChipDriver的Factory,用于支持一个芯片多个WLAN端口

HdfChipDriver

drivers\framework\include\wifi\wifi_module.h

每个WLAN端口对应一个HdfChipDriver,用来管理一个特定端口

NetDeviceInterFace

drivers\framework\include\wifi\net_device.h

与协议栈之间的接口,如发送数据、设置网络接口状态等

说明:

 详细的接口开发指导,请参考

​WLAN开发​

具体的移植步骤如下:

  1. 创建HDF WLAN 芯片驱动 在目录/device/vendor_name/peripheral/wifi/chip_name/ 创建文件 hdf_wlan_chip_name.c。内容模板如下:

static int32_t HdfWlanHisiChipDriverInit(struct HdfDeviceObject *device) {
    static struct HdfChipDriverFactory factory = CreateChipDriverFactory(); // 需要移植者实现的方法
    struct HdfChipDriverManager *driverMgr = HdfWlanGetChipDriverMgr();
    if (driverMgr->RegChipDriver(&factory) != HDF_SUCCESS) { // 注册驱动工厂
        HDF_LOGE("%s fail: driverMgr is NULL!", __func__);
        return HDF_FAILURE;
    }
    return HDF_SUCCESS;
}

struct HdfDriverEntry g_hdfXXXChipEntry = {
    .moduleVersion = 1,
    .Init = HdfWlanXXXChipDriverInit,
    .Release = HdfWlanXXXChipRelease,
    .moduleName = "HDF_WIFI_CHIP_XXX" // 注意:这个名字要与配置一致
};

HDF_INIT(g_hdfXXXChipEntry);

在上述代码的CreateChipDriverFactory方法中,需要创建一个HdfChipDriverFactory类型的对象。该对象提供如下方法

接口

说明

const char *driverName

当前driverName

int32_t (*InitChip)(struct HdfWlanDevice *device)

初始化芯片

int32_t (*DeinitChip)(struct HdfWlanDevice *device)

去初始化芯片

void (*ReleaseFactory)(struct HdfChipDriverFactory *factory)

释放HdfChipDriverFactory对象

struct HdfChipDriver *(*Build)(struct HdfWlanDevice *device, uint8_t ifIndex)

创建一个HdfChipDriver;输入参数中,device是设备信息,ifIndex是当前创建的接口在这个芯片中的序号

void (*Release)(struct HdfChipDriver *chipDriver)

释放chipDriver

uint8_t (*GetMaxIFCount)(struct HdfChipDriverFactory *factory)

获取当前芯片支持的最大接口数

其中Build方法负责创建一个管理指定网络接口的对象HdfChipDriver 。该对象需要提供方法:

接口

说明

int32_t (*init)(struct HdfChipDriver *chipDriver, NetDevice *netDev)

初始化当前网络接口,这里需要向netDev提供接口NetDeviceInterFace

int32_t (*deinit)(struct HdfChipDriver *chipDriver, NetDevice *netDev)

去初始化当前网络接口

struct HdfMac80211BaseOps *ops

WLAN基础能力接口集

struct HdfMac80211STAOps *staOps

支持STA模式所需的接口集

struct HdfMac80211APOps *apOps

支持AP模式所需要的接口集

2.编写配置文件描述驱动支持的芯片 在产品配置目录下创建芯片的配置文件,保存至源码路径//vendor/vendor_name/product_name/config/wifi/wlan_chip_chip_name.hcs
该文件模板如下:

root {
    wlan_config {
        chip_name :& chipList {
            chip_name :: chipInst {
                match_attr = "hdf_wlan_chips_chip_name"; /* 这是配置匹配属性,用于提供驱动的配置根 */
                driverName = "driverName"; /* 需要与HdfChipDriverFactory中的driverName相同*/
                sdio {
                    vendorId = 0xXXXX; /* your vendor id */
                    deviceId = [0xXXXX]; /*your supported devices */
                }
            }
        }
    }
}

说明:

 路径和文件中的vendor_name、product_name、chip_name请替换成实际名称

vendorId 和 deviceId需要根据实际芯片的识别码进行填写。

3.编写配置文件,加载驱动 产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。修改该文件,在名为network的host中,名为device_wlan_chips的device中增加配置。模板如下:

说明:

 moduleName 要与HDF WLAN 芯片驱动中的moduleName相同。

4.修改Kconfig文件,让移植的WLAN模组出现再内核配置中 在device/vendor_name/drivers/Kconfig中增加配置菜单,模板如下

config DRIVERS_HDF_WIFI_chip_name
    bool "Enable chip_name Host driver"
    default n
    depends on DRIVERS_HDF_WLAN   help
      Answer Y to enable chip_name Host driver.

说明:

 请替换模板中的chip_name为实际的芯片名称

5.修改构建脚本,让驱动参与内核构建 在源码文件//device/vendor_name/drivers/lite.mk末尾追加如下内容

ifeq ($(LOSCFG_DRIVERS_HDF_WIFI_chip_name), y)
    # 构建完成要链接一个叫hdf_wlan_chipdriver_chip_name的对象,建议按这个命名,防止冲突
    LITEOS_BASELIB += -lhdf_wlan_chipdriver_chip_name
    # 增加构建目录gpio
    LIB_SUBDIRS    += ../peripheral/wifi/chip_name
endif

说明:

 请替换模板中的chip_name为实际的芯片名称


文章转载自:​​https://docs.openharmony.cn/pages/v3.2Beta/zh-cn/device-dev/porting/porting-smallchip-driver-oom.md/​

收藏
回复
举报
回复
    相关推荐