本文章基于恒玄科技BES2600W芯片的欧智通 Multi-modal V200Z-R开发板 ，进行轻量带屏开发板的标准移植，开发了智能开关面板样例，同时实现了ace_engine_lite、arkui_ui_lite、aafwk_lite、appexecfwk_lite、HDF等部件基于OpenHarmony LiteOS-M内核的适配。移植架构上采用Board与SoC分离的方案，工具链Newlib C库与Musl C库可选，LiteOS-M内核编译采用gn结合Kconfig图形化配置等需求。

编译构建

目录规划

本案例在芯片移植架构方面进行了一些改进，以前的芯片适配目录规划为：

device
└── <device_company>
    └── <device_name>

这样会导致，小熊派BearPi-HM Nano开发板与润和的HiSpark Pegasus开发板使用小海思的hi3861的SoC时，需要在这两款开发板里面都放置一份重复的代码。为了解决该问题，本案例将单板厂商与SoC厂商进行分离，可以参考Board和SoC解耦的设计思路，并把芯片适配目录规划为：

device
├── board                                --- 单板厂商目录
│   └── fnlink                           --- 单板厂商名字：欧智通
│       └── v200zr                       --- 单板名：v200zr
└── soc									 --- SoC厂商目录
    └── bestechnic                       --- SoC厂商名字：恒玄
        └── bes2600						 --- SoC Series名：bes2600是一个系列，里面包含bes2600w等SoC名

产品样例目录规划为：

vendor
└── bestechnic							 --- 开发产品样例厂商目录，恒玄开发的带屏样例，因此以bestechnic命名
    └── display_demo         			 --- 产品名字：以智能开关面板的带屏显示样例

预编译适配

在进行移植之前，需要进行预编译适配。

预编译适配主要使用hb set命令，设置整个项目的根目录、单板目录、产品目录、单板公司名等环境变量，为编译做准备。

具体的预编译适配步骤如下：

1. 在vendor/bestechnic/display_demo目录下新增config.json文件，用于描述这个产品样例所使用的单板、内核等信息，描述信息可参考如下内容：

{
  "product_name": "display_demo",       --- 用于hb set进行选择时，显示的产品名称
  "type": "mini",                       --- 构建系统的类型，mini/small/standard
  "version": "3.0",                     --- 构建系统的版本，1.0/2.0/3.0
  "device_company": "fnlink",           --- 单板厂商名，用于编译时找到/device/board/fnlink目录
  "board": "v200zr",                    --- 单板名，用于编译时找到/device/board/fnlink/v200zr目录
  "kernel_type": "liteos_m",            --- 内核类型，因为OpenHarmony支持多内核，一块单板可能适配了多个内核，所以需要指定某个内核进行编译
  "kernel_version": "3.0.0",            --- 内核版本，一块单板可能适配了多个linux内核版本，所以需要指定某个具体的内核版本进行编译
  "subsystems": [ ]                     --- 选择所需要编译构建的子系统
}

2. 在device/board/fnlink/v200zr/liteos_m目录下新增config.gni文件，用于描述这个产品样例所使用的单板、内核等信息，描述信息可参考如下内容：

# Kernel type, e.g. "linux", "liteos_a", "liteos_m".
kernel_type = "liteos_m"                --- 内核类型，跟config.json中kernel_type对应

# Kernel version.
kernel_version = "3.0.0"                --- 内核版本，跟config.json中kernel_version对应

3. 验证hb set配置是否正确，输入hb set能够显示如下图片表示配置正确。

执行hb set输入项目根目录，并且回车，hb命令会遍历所有//vendor/<product_company>/<product_name>目录下的config.json，给出可选产品编译选项，config.json的product_name用于显示产品名，device_company和board用于关联出//device/board/<device_company>/<board>目录，并且匹配<any_dir_name>/config.gni文件，如果能够匹配多个文件，表示该单板适配了多个内核，那么可以根据config.json的kernel_type和kernel_version来唯一匹配config.gni的kernel_type和kernel_version，即可确定了需要编译适配了哪个内核的单板。

过hb env可以查看选择出来的预编译环境变量。

在执行hb build之前，需要准备好LiteOS-M内核适配，具体适配步骤请参内核移植。

内核移植

内核移植需要完成LiteOS-M Kconfig适配、gn的编译构建和内核启动最小适配。

LiteOS-M Kconfig适配

在//kernel/liteos_m目录下执行make menuconfig命令，完成编译配置选项的选择。在Makefile文件中，会将hb env的结果转换成环境变量，即PRODUCT_PATH、DEVICE_PATH和BOARD_COMPANY。如下代码块所示：

$(foreach line,$(shell hb env | sed 's/\[OHOS INFO\]/ohos/g;s/ /_/g;s/:_/=/g' || true),$(eval $(line)))
ifneq ($(ohos_kernel),liteos_m)
$(error The selected product ($(ohos_product)) is not a liteos_m kernel type product)
endif
--- 将hb env的每一行输出转化为变量形式，例如将[OHOS INFO] device company: fnlink转换为ohos_device_company=fnlink

……

ifeq ($(BOARD_COMPANY),)
BOARD_COMPANY:=$(ohos_device_company)
endif
……
export BOARD_COMPANY
--- 将ohos_device_company转化为BOARD_COMPANY环境变量

在//kernel/liteos_m/Kconfig文件中使用这些导出的环境变量，Kconfiglib采用ulfalizer开发基于python的版本，源码地址，功能介绍连接参考，里面用到了orsource关键字，其中o表示optional，表示这个文件是否存在可选，r表示relative，表示这个文件相对当前文件的相对路径。

config SOC_COMPANY
    string "SoC company name to locate soc build path"
    help
      This option specifies the SoC company name, used to locate the build path for soc. This option is set by the
      SoC's Kconfig file, and should be exactly the same with SoC company path, and the user should generally avoid
       modifying it via the menu configuration.

orsource "../../device/board/*/Kconfig.liteos_m.shields"                                 --- 将所有扩展板配置信息加载进来，因为单板厂商A提供扩展板可以给单板厂商B使用，所以这里使用*匹配所有的扩展板，而非BOARD_COMPANY。另外由于OpenHarmony支持多内核设计，Kconfig文件采用liteos_m作为后缀，在进行单板适配过程中，其他内核在适配过程中，可以使用对应的内核名作为后缀名进行扩展。

orsource "../../device/board/$(BOARD_COMPANY)/Kconfig.liteos_m.defconfig.boards"         --- 加载BOARD_COMPANY的所有单板预定义配置

choice
    prompt "Board Selection"

orsource "../../device/board/$(BOARD_COMPANY)/Kconfig.liteos_m.boards"                   --- 提供Board选择列表

endchoice

orsource "../../device/soc/*/Kconfig.liteos_m.defconfig"                                 --- 加载所有SoC的默认配置定义

choice
    prompt "SoC Series Selection"

orsource "../../device/soc/*/Kconfig.liteos_m.series"                                    --- 提供所有SoC Series选择列表

endchoice

orsource "../../device/soc/*/Kconfig.liteos_m.soc"                                       --- 加载所有SoC配置

从//kernel/liteos_m/Kconfig文件可以看出需要在//device/board/fnlink目录下新增如下Kconfig文件进行适配：

.
├── v200zr                                       --- v200zr单板配置目录
│   ├── Kconfig.liteos_m.board                   --- 提供v200zr单板的配置选项
│   ├── Kconfig.liteos_m.defconfig.board         --- 提供v200zr单板的默认配置项
│   └── liteos_m
│       └── config.gni
├── Kconfig.liteos_m.boards                      --- 提供fnlink单板厂商下Boards配置信息
├── Kconfig.liteos_m.defconfig.boards			 --- 提供fnlink单板厂商下Boards默认配置信息
├── Kconfig.liteos_m.shields					 --- 提供fnlink单板厂商下扩展板配置信息
└── shields										 --- fnlink单板厂商的扩展板目录
    ├── v200zr-t0								 --- fnlink单板厂商的扩展板v200zr-t0
    │   ├── Kconfig.liteos_m.defconfig.shield	 --- 扩展板v200zr-t0默认配置
    │   └── Kconfig.liteos_m.shield				 --- 扩展板v200zr-t0配置信息
    ├── v200zr-t1
    │   ├── Kconfig.liteos_m.defconfig.shield
    │   └── Kconfig.liteos_m.shield
    └── Kconfig.liteos_m.shields

在 v200zr/Kconfig.liteos_m.board需要配置选择该单板的选项，以及它依赖的SoC，如下：

config BOARD_v200zr
    bool "select board v200zr"
    depends on SOC_BES2600W		 --- v200zr单板用的bes2600w的SoC，只有 bes2600w的SoC被选择后，v200zr单板配置选项才可见，可以被选择。

在 v200zr/Kconfig.liteos_m.defconfig.board需要配置选择该单板后，默认定义 BOARD 的名字为 "v200zr" ，如下：

if BOARD_v200zr
config BOARD
    string		 --- string后没有带提示，因此用户不可见
    default "v200zr"

endif # BOARD_v200zr

从//kernel/liteos_m/Kconfig文件可以看出需要在//device/soc/bestechnic目录下新增如下Kconfig文件进行适配：

.
├── bes2600									 --- bes2600 SoC系列
│   ├── Kconfig.liteos_m.defconfig.bes2600w	 --- bestechnic芯片厂商bes2600w SoC Series配置
│   ├── Kconfig.liteos_m.defconfig.series	 --- bestechnic芯片厂商bes2600默认配置
│   ├── Kconfig.liteos_m.series				 --- bestechnic芯片厂商bes2600 SoC Series配置
│   └── Kconfig.liteos_m.soc				 --- bestechnic芯片厂商bes2600 SoC配置
├── Kconfig.liteos_m.defconfig				 --- bestechnic芯片厂商SoC默认配置
├── Kconfig.liteos_m.series					 --- bestechnic芯片厂商SoC Series配置
└── Kconfig.liteos_m.soc					 --- bestechnic芯片厂商 SoC配置

在 bes2600/Kconfig.liteos_m.series 需要配置bes2600 SoC series，以及它的芯片架构等信息，如下：

config SOC_SERIES_BES2600			 --- 提供bes2600 SoC Series选项
    bool "Bestechnic 2600 Series"
    select ARM						 --- 选择bes2600后，默认选择ARM架构
    select SOC_COMPANY_BESTECHNIC    --- 选择bes2600后，默认选择bestechnic芯片公司，驱动会依赖这个宏配置，选择配置编译对应厂商的驱动
    select CPU_CORTEX_M33			 --- 选择bes2600后，默认选择cortex-m33 CPU
    help
        Enable support for Bestechnic 2600 series

在 bes2600/Kconfig.liteos_m.soc 需要提供bes2600 SoC series下有多少个具体的SoC可供选择，如下：

choice
    prompt "Bestechnic 2600 series SoC"
    depends on SOC_SERIES_BES2600	 --- 只有选择了bes2600 Series后，才会出现如下配置选项

config SOC_BES2600W					 --- 增加bes2600w SoC配置选择项
    bool "SoC BES2600w"

endchoice

在 bes2600/Kconfig.liteos_m.defconfig.series 需要提供bes2600 SoC series选择后的默认配置，如下：

if SOC_SERIES_BES2600							 --- 选择了bes2600 Series后，才会增加如下默认配置选项

rsource "Kconfig.liteos_m.defconfig.bes2600w"	 --- 增加bes2600w SoC的默认配置

config SOC_SERIES								 --- 增加SOC_SERIES的默认配置
    string
    default "bes2600"

endif

配置完成后，还需要根据 kernel/liteos_m/Makefile 文件配置make menuconfig的defconfig保存路径：

ifeq ($(TEE:1=y),y)
tee = _tee
endif
ifeq ($(RELEASE:1=y),y)
CONFIG ?= $(PRODUCT_PATH)/kernel_configs/release$(tee).config
else
CONFIG ?= $(PRODUCT_PATH)/kernel_configs/debug$(tee).config		 --- 配置文件保存在$(CONFIG)中，由产品最终定义
endif

……

update_config menuconfig:
	$(HIDE)test -f "$(CONFIG)" && cp -v "$(CONFIG)" .config && menuconfig $(args) && savedefconfig --out "$(CONFIG)"

在这个例子中，defconfig配置路径为 $(PRODUCT_PATH)/kernel_configs/debug.config，创建该文件后，内容为空，产品的目录文件结构如下：

.
└── display_demo
    ├── config.json
    └── kernel_configs
        └── debug.config

配置完成后，在 kernel/liteos_m 目录下执行 make menuconfig能够对SoC Series/SoC/Board进行选择，如下：

结果将自动保存在$(PRODUCT_PATH)/kernel_configs/debug.config，下次执行make menuconfig时会导出保存的结果。

gn编译适配

在上一步Kconfig的图形化配置后，将其生成的配置结果可以作为gn编译的输入，以控制不同模块是否编译。另外为了解决之前gn编写时，随意include的问题，内核编译做了模块化编译的设计，使得整个编译逻辑更加清晰，设计思路请参考LiteOS-M内核BUILD.gn编写指南。

在 kernel/liteos_m/BUILD.gn 中，指定了Board和SoC的编译入口为//device/board/fnlink和//device/soc/bestechnic。

deps += [ "//device/board/$device_company" ]
deps += [ "//device/soc/$LOSCFG_SOC_COMPANY" ]

在//device/board/fnlink/BUILD.gn中，新增内容如下：

if (ohos_kernel_type == "liteos_m") {                    --- 由于多内核设计，对于LiteOS-M内核适配，需要用宏来隔离
  import("//kernel/liteos_m/liteos.gni")				 --- 引入内核gn编写模板
  module_name = get_path_info(rebase_path("."), "name")	 --- 动态获取当前文件目录作为模块名，防止目录名修改后，这里还需要跟着修改
  module_group(module_name) {							 --- 采用module_group模板
    modules = [											 --- 添加需要编译的模块
    ]
  }
}

同理//device/soc/bestechnic/BUILD.gn也是一样。

内核启动适配

系统启动流程分为三个阶段：

阶段名称	分区规划	描述
BOOT1	[0, 0x10000]	第一阶段启动，进行固件启动
BOOT2	[0x2C010000, 0x2C020000]	第二阶段启动，进行OTA升级启动
RTOS_MAIN	[0x2C080000, 0x2C860000]	第三阶段启动，进行内核启动

在第三阶段内核启动中，需要适配的文件路径在 //device/soc/bestechnic/bes2600/liteos_m/sdk/bsp/rtos/liteos/liteos_m/board.c

内核启动适配总体思路如下：

1. 中断向量的初始化os_vector_init ，初始化中断的处理函数。
2. 内核初始化osKernelInitialize 。
3. 创建线程board_main，进行芯片平台初始化。
4. 内核启动，开始调度线程osKernelStart 。

其中，本章节详细对第3步进行展开，其他几步为对内核函数调用，不作详细描述。

第3步中board_main在启动OHOS_SystemInit之前，需要初始化必要的动作，如下：

...
    if(!ret) {
        ...
        OhosSystemAdapterHooks();    --- 系统启动时候设置钩子，启动OpenHarmonyOHOS_SystemInit的之前完成打印和驱动的初始化
        ...
        OHOS_SystemInit(); 			 --- 启动OpenHarmony服务，以及组件初始化
    }
....

OhosSystemAdapterHooks函数在device/soc/bestechnic/bes2600/liteos_m/components/utils/src/hm_sys.c文件中，如下：

int OhosSystemAdapterHooks(void)
{
    init_trace_system(); 	 --- 初始化打印函数
    DeviceManagerStart(); 	 --- 调用DeviceManagerStart函数进行HDF驱动初始化，这个过程会调用单板代码中的驱动配置文件hdf.hcs以及drivers源码实现
    return 0;
}

littlefs文件系统移植

V200Z-R开发板开发板采用最大32MB的支持XIP的Nor Flash，文件系统可以使用example，适配过程中，需要在指定路径下放置文件系统预置文件，根据配置可自动生成文件系统镜像，可以实现自动化生成和打包到烧录包中。

1. 配置指定目录放置打包文件系统config.json，通过flash_partition_dir指定目录：

  "flash_partition_dir": "fs" 	 --- 表示在vendor/bestechnic/display_demo/fs目录下放置文件系统预置文件

2. 在指定目录vendor/bestechnic/display_demo/fs下放置两部分内容：

• wifi_Download_cfg.yaml：镜像的烧录配置文件，可以根据实际情况调整分区。
• /data/data：第一个/data是挂载的根目录；第二个data是根目录里面的data目录，里面可以存放预置文件，或者在第二个data的同级目录再创建一个目录，打包的时候只认第一个data挂载根目录。

3. config.json中根据wifi_Download_cfg.yaml最后调整结果。

• fs_src配置文件系统挂载名字。
• fs_name是最后生成文件系统的名字。
• block_size配置成4K对齐，建议不修改。
• fs_size是生成文件系统的大小。
• burn_name是烧录bin名字的大小。
• enable 表示是否生成这个文件系统

4. 在//device/soc/bestechnic/bes2600/liteos_m/components/hdf_config/hdf.hcs文件配置文件系统的烧录的起始地址、文件系统的大小以及读数据块的大小block_size等信息，参考配置如下：

    misc {
        fs_config {
            example_config {
                match_attr = "littlefs_config";
                mount_points = ["/data"];
                partitions = [10];
                block_size = [4096];
                block_count = [1024];
            }
        }
        storage_config {
            flash_config {
                match_attr = "flash_config";
                partitions = [10];
                owner = [0];
                description = ["littlefs"];
                start_addr = [0xB60000];
                length = [0x400000];
                options = [3];
            }
        }
    }

最后在device/soc/bestechnic/bes2600/liteos_m/components/fs/fs_init.c中，通过hdf加载数据，进行读写flash，如下：

static int32_t FsDriverInit(struct HdfDeviceObject *object)
{
    if (object == NULL) {
        return HDF_FAILURE;
    }
    if (object->property) {
        if (FsGetResource(fs, object->property) != HDF_SUCCESS) {
            HDF_LOGE("%s: FsGetResource failed", __func__);
            return HDF_FAILURE;
        }
    }
    for (int i = 0; i < sizeof(fs) / sizeof(fs[0]); i++) {
        if (fs[i].mount_point == NULL)
            continue;

        fs[i].lfs_cfg.read = littlefs_block_read;
        fs[i].lfs_cfg.prog = littlefs_block_write;
        fs[i].lfs_cfg.erase = littlefs_block_erase;
        fs[i].lfs_cfg.sync = littlefs_block_sync;

        fs[i].lfs_cfg.read_size = 256;
        fs[i].lfs_cfg.prog_size = 256;
        fs[i].lfs_cfg.cache_size = 256;
        fs[i].lfs_cfg.lookahead_size = 16;
        fs[i].lfs_cfg.block_cycles = 1000;

        int ret = mount(NULL, fs[i].mount_point, "littlefs", 0, &fs[i].lfs_cfg);
        HDF_LOGI("%s: mount fs on '%s' %s\n", __func__, fs[i].mount_point, (ret == 0) ? "succeed" : "failed");
    }
    return HDF_SUCCESS;
}

C库适配

在轻量系统中，C库适配比较复杂，设计思路请参考LiteOS-M内核支持musl与newlib平滑切换方案，由于我们的工具链采用 gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 自带newlib的C库，那么系统移植整体采用newlib的C库。那么在内核的make menuconfig中选择newlib，如下图：

malloc适配

malloc适配参考The Red Hat newlib C Library-malloc。实现malloc适配有以下两种方法：

• 实现 _sbrk_r 函数。这种方法中，内存分配函数使用newlib中的。

• 实现 _malloc_r, _realloc_r, _reallocf_r, _free_r, _memalign_r, 和 _malloc_usable_size_r。这种方法中，内存分配函数可以使用内核的。

为了方便地根据业务进行内存分配算法调优和问题定位，在这两种方法中，本案例选择后者。

首先，由于newlib中已经存在这些函数的符号，因此需要用到gcc的wrap的链接选项替换这些函数符号为内核的实现，内核的实现为 //kernel/liteos_m/kal/libc/newlib/porting/src/malloc.c。

然后，在//device/board/fnlink/v200zr/liteos_m/config.gni的新增这些函数的wrap链接选项。

board_ld_flags += [
     "-Wl,--wrap=_malloc_r",
     "-Wl,--wrap=_realloc_r",
     "-Wl,--wrap=_reallocf_r",
     "-Wl,--wrap=_free_r",
     "-Wl,--wrap=_memalign_r",
     "-Wl,--wrap=_malloc_usable_size_r",
]

vsprintf等适配

参考 https://sourceware.org/newlib/libc.html#vfprintf ，实现 vprintf, vfprintf, printf, snprintf 和sprintf。

类似malloc适配，首先要提供这些函数的实现，//device/soc/bestechnic/bes2600/liteos_m/components/utils/src/printf.c，本案例直接采用开源协议友好的实现。与malloc适配不同的是，这个函数由芯片原厂提供。因为就打印来说，根据项目的需要，实现可大可小，内核不方便提供统一的实现。

然后，在//device/board/fnlink/v200zr/liteos_m/config.gni的新增这些函数的wrap链接选项。

board_ld_flags += [
     "-Wl,--wrap=printf",
     "-Wl,--wrap=sprintf",
     "-Wl,--wrap=snprintf",
     "-Wl,--wrap=vsnprintf",
     "-Wl,--wrap=vprintf",
]

open等适配

这部分实现由内核统一实现，芯片适配无须关注，内核文件//kernel/liteos_m/kal/libc/newlib/porting/src/fs.c，适配了newlib的_read、_write等函数，如下：

……
ssize_t _read(int fd, void *buf, size_t nbyte)
{
    return LOS_Read(fd, buf, nbyte);
}

ssize_t _write(int fd, const void *buf, size_t nbyte)
{
    return LOS_Write(fd, buf, nbyte);
}

off_t _lseek(int fd, off_t offset, int whence)
{
    return LOS_Lseek(fd, offset, whence);
}
……

板级系统移植

驱动移植

SoC芯片平台HDF驱动移植

驱动适配相关文件放置在drivers/adapter/platform中，对应有gpio，i2c，pwm，spi，uart，watchdog，都是通过HDF机制加载，本章节以gpio为例进行详细说明。

GPIO驱动适配

gpio驱动适配需要完成编译的适配、源码的适配。

在//drivers/adapter/platform/gpio/BUILD.gn文件中，描述了恒玄gpio驱动的编译适配。如下：

module_switch = defined(LOSCFG_DRIVERS_HDF_PLATFORM_GPIO)	 --- 如果打开HDF的GPIO配置开关，才进行如下编译
module_name = get_path_info(rebase_path("."), "name")

hdf_driver(module_name) {
  sources = []
  if (defined(LOSCFG_SOC_COMPANY_BESTECHNIC)) {				 --- 如果打开恒玄的芯片配置开关，才进行恒玄GPIO的驱动编译
    sources += [ "gpio_bes.c" ]
  }

  include_dirs = [ "." ]
}

在//drivers/adapter/platform/gpio/gpio_bes.c文件中，描述了恒玄gpio驱动的源码适配。
首先，按照OpenHarmony的HDF驱动框架加载驱动基本适配框架，如下：

struct HdfDriverEntry g_GpioDriverEntry = {
    .moduleVersion = 1,
    .moduleName = "BES_GPIO_MODULE_HDF",
    .Bind = GpioDriverBind,
    .Init = GpioDriverInit,
    .Release = GpioDriverRelease,
};
HDF_INIT(g_GpioDriverEntry); 	 --- 通过HDF_INIT 加载GPIO驱动

然后，在初始化的时候会获取hcs参数进行初始化，如下：

static int32_t GpioDriverInit(struct HdfDeviceObject *device)
{
    int32_t ret;
    struct GpioCntlr *gpioCntlr = NULL;

    if (device == NULL) {
        HDF_LOGE("%s: device is NULL", __func__);
        return HDF_ERR_INVALID_PARAM;
    }

    gpioCntlr = GpioCntlrFromDevice(device); 	 --- gpioCntlr节点变量就可以获取具体gpio配置
    if (gpioCntlr == NULL) {
      ...

编码规范和设计思想见bes 驱动适配PR的评论。

Board外设器件HDF驱动移植

Board外设器件表示通过SoC平台总线连接的外设器件，在本案例中，显示屏属于外设器件，其驱动适配放在//device/board/fnlink/drivers/liteos_m目录中。

显示驱动适配

同SoC驱动适配，在//device/board/fnlink/drivers/liteos_m/display/BUILD.gn文件中，根据hdf_driver模板加载驱动模块，如下：

module_name = get_path_info(rebase_path("."), "name")
hdf_driver(module_name) {
  sources = [
    "zzw395.c",
  ]
  include_dirs = [
    "//drivers/peripheral/display/interfaces/include",
  ...
  ]
}

在//device/board/fnlink/drivers/liteos_m/display/zzw395.c文件中，根据驱动框架加载显示驱动，如下：

static struct HdfDriverEntry g_ZZW395DriverEntry = {
    .moduleVersion = 1,
    .moduleName = "HDF_PANEL_ZZW395",
    .Bind = PanelDriverBind,
    .Init = PanelDriverInit,
    .Release = PanelDriverRelease,
};

HDF_INIT(g_ZZW395DriverEntry);

其中的驱动参数根据hcs配置，在PanelDriverInit初始化时加载，如下：

static int32_t PanelDriverInit(struct HdfDeviceObject *object)
{
    if (object == NULL) {
        return HDF_FAILURE;
    }
    HDF_LOGD("%s entry !!!", __func__);
    if (object->property) {
        if (PanelGetResource(&priv, object->property) != HDF_SUCCESS) {
            HDF_LOGE("%s: PanelGetResource failed", __func__);
            return HDF_FAILURE;
        }
    }
...

OpenHarmony子系统适配

OpenHarmony子系统适配一般包含两部分：

• 在config.json中增加对应子系统和部件，这样编译系统会将该部件纳入编译目标中。
• 针对该部件的HAL层接口进行硬件适配，或者可选的软件功能适配。

分布式软总线子系统适配

wifi_lite部件适配

首先，在config.json文件中，增加communication子系统的wifi_lite部件，如下：

    {
      "subsystem": "communication",
      "components": [
        {
          "component": "wifi_lite",
          "optional": "true"
        }
      ]
    },

wifi_lite部件在//build/lite/components/communication.json文件中，描述如下：

    {
      "component": "wifi_lite",
……
      "targets": [
        "//foundation/communication/wifi_lite:wifi"		 --- wifi_lite的编译目标
      ],
……
    },

在//foundation/communication/wifi_lite/BUILD.gn文件中，描述需要适配的接口头文件路径，如下：

config("include") {
  include_dirs = [ "interfaces/wifiservice" ]	 --- 因为wifi_lite只提供头文件，不提供wifi的具体实现，所以wifi模块暴露出适配的目录路径提供给硬件厂商来适配，厂商提供wifi协议栈源码实现。
}

group("wifi") {
  public_configs = [ ":include" ]
}

因为在本案例中，wifi属于SoC提供的功能，所以适配源码放在SoC的//device/soc/bestechnic/hals/communication/wifi_lite/wifiservice目录下，包含wifi_device.c和wifi_hotspot.c分别适配wifi_device.h和wifi_hotspot.h。如下：

……
WifiErrorCode Scan(void)	 --- wifi_device.c中扫描wifi热点的函数，对wifi_device.h中Scan函数的适配实现
{
    WifiErrorCode ret = ERROR_WIFI_BUSY;


    if (IsWifiActive() != WIFI_STA_ACTIVE)
        return ERROR_WIFI_IFACE_INVALID;

    if (g_HalHmosWifiInfo.scan_state == SCAN_REQUEST ||
        g_HalHmosWifiInfo.scan_state == SCAN_TRIGGER)
        return ERROR_WIFI_BUSY;

    HalHmosWifiLock();
    ret = ((HalHmosSendEvent(HMOS_ON_WIFI_SCAN_STATE_CHANGED, NULL) == 0) ? WIFI_SUCCESS : ERROR_WIFI_BUSY);
    HalHmosWifiUnLock();

    return ret;
}
……
int GetSignalLevel(int rssi, int band)	 --- wifi_hotspot.c中获取wifi信号热点函数，对wifi_hotspot.h中GetSignalLevel函数的适配实现。
{
    if (band == HOTSPOT_BAND_TYPE_2G) {
        if (rssi >= RSSI_LEVEL_4_2_G)
            return RSSI_LEVEL_4;
        if (rssi >= RSSI_LEVEL_3_2_G)
            return RSSI_LEVEL_3;
        if (rssi >= RSSI_LEVEL_2_2_G)
            return RSSI_LEVEL_2;
        if (rssi >= RSSI_LEVEL_1_2_G)
            return RSSI_LEVEL_1;
    }

    if (band == HOTSPOT_BAND_TYPE_5G) {
        if (rssi >= RSSI_LEVEL_4_5_G)
            return RSSI_LEVEL_4;
        if (rssi >= RSSI_LEVEL_3_5_G)
            return RSSI_LEVEL_3;
        if (rssi >= RSSI_LEVEL_2_5_G)
            return RSSI_LEVEL_2;
        if (rssi >= RSSI_LEVEL_1_5_G)
            return RSSI_LEVEL_1;
    }
    return ERROR_WIFI_INVALID_ARGS;
}

LWIP部件适配

LiteOS-M kernel目录下默认配置了lwip，因而具有编译功能，可以在kernel组件中指定lwip编译的目录。如下：

    {
      "subsystem": "kernel",
      "components": [
        {
          "component": "liteos_m",
          "features": [
            "ohos_kernel_liteos_m_lwip_path = \"//device/soc/bestechnic/bes2600/liteos_m/components/net/lwip-2.1\""		 --- 指定在芯片厂商目录中进行适配
          ]
        }
      ]
    },

在//device/soc/bestechnic/bes2600/liteos_m/components/net/lwip-2.1/BUILD.gn文件中，描述了lwip的编译，如下：

import("//kernel/liteos_m/liteos.gni")
import("$LITEOSTHIRDPARTY/lwip/lwip.gni")
import("$LITEOSTOPDIR/components/net/lwip-2.1/lwip_porting.gni")

module_switch = defined(LOSCFG_NET_LWIP_SACK)
module_name = "lwip"
kernel_module(module_name) {
  sources = LWIP_PORTING_FILES + LWIPNOAPPSFILES -
            [ "$LWIPDIR/api/sockets.c" ] + [ "porting/src/ethernetif.c" ]		 --- 增加ethernetif.c文件，用以适配ethernet网卡的初始化适配
  defines = [ "LITEOS_LWIP=1" ]
  defines += [ "CHECKSUM_BY_HARDWARE=1" ]
}

config("public") {
  defines = [ "_BSD_SOURCE=1" ]
  include_dirs =
      [ "porting/include" ] + LWIP_PORTING_INCLUDE_DIRS + LWIP_INCLUDE_DIRS
}

在//device/soc/bestechnic/bes2600/liteos_m/components/net/lwip-2.1/porting/include/lwip/lwipopts.h文件中，说明原有lwip配置选项保持不变，软总线会依赖这些配置选项，并且新增硬件适配的配置项，如下：

#ifndef _PORTING_LWIPOPTS_H_
#define _PORTING_LWIPOPTS_H_

#include_next "lwip/lwipopts.h"				 --- 保持原来的配置项不变

#define LWIP_NETIF_STATUS_CALLBACK      1
#define LWIP_CHECKSUM_ON_COPY           0
#define CHECKSUM_GEN_UDP                0	 --- 新增硬件适配选项

#endif /* _PORTING_LWIPOPTS_H_ */

在//device/soc/bestechnic/bes2600/liteos_m/components/net/lwip-2.1/porting/src/ethernetif.c文件中，说明对ethernet网卡初始化的适配，如下：

err_t
ethernetif_init(struct netif *netif)
{
……
#ifdef CHECKSUM_BY_HARDWARE
    eth_hw_checksum_init();
#endif
……
    netif->linkoutput = low_level_output;

    netif->drv_send = liteos_low_level_output;
    netif->hwaddr_len = NETIF_MAX_HWADDR_LEN;
    low_level_init(netif);
    driverif_init(netif);
    return ERR_OK;
……
}

dsoftbus部件适配

在config.json中增加dsoftbus部件配置如下：

{
  "component": "dsoftbus",
  "features": [
    "softbus_adapter_config = \"//vendor/bestechnic/mini_distributed_music_player/dsoftbus_lite_config\""
  ]
},

dsoftbus部件在//foundation/communication/dsoftbus/dsoftbus.gni文件中提供了softbus_adapter_config配置选项可供移植过程进行配置，该配置设定了软总线移植适配的路径。

在本案例中，softbus_adapter_config配置为//vendor/bestechnic/mini_distributed_music_player/dsoftbus_lite_config路径，该路径下的内容为：

.
├── feature_config					--- 软总线功能特性配置，例如是否开启自发现功能等
│   └── mini
│       └── config.gni
└── spec_config						--- 软总线规格特性配置，例如设置软总线日志级别设置
    ├── softbus_config_adapter.c
    ├── softbus_config_adapter.h
    └── softbus_config_type.h

在config.gni文件中规定了以下配置项：

配置项	描述
dsoftbus_feature_disc_ble	是否开启BLE发现功能
dsoftbus_feature_disc_coap	是否开启COAP发现功能
dsoftbus_feature_conn_tcp	是否开启TCP连接功能
dsoftbus_feature_conn_br	是否开启BR连接功能
dsoftbus_feature_conn_ble	是否开启BLE连接功能
dsoftbus_feature_conn_p2p	是否开启P2P连接功能
dsoftbus_feature_trans_udp	是否开启UDP传输功能
dsoftbus_feature_trans_udp_stream	是否开启UDP传输流功能
dsoftbus_feature_trans_udp_file	是否开启UDP传输文件功能
dsoftbus_feature_ip_auth	是否开启认证传输通道功能
dsoftbus_feature_auth_account	是否开启基于账号认证功能
dsoftbus_feature_qos	是否开启QoS功能

在softbus_config_adapter.c文件中规定了以下配置项：

配置项	描述
SOFTBUS_INT_MAX_BYTES_LENGTH	SendBytes发送最大Bytes长度
SOFTBUS_INT_MAX_MESSAGE_LENGTH	SendMessage发送最大消息的长度
SOFTBUS_INT_CONN_BR_MAX_DATA_LENGTH	蓝牙最大接收数据量
SOFTBUS_INT_CONN_RFCOM_SEND_MAX_LEN	蓝牙最大接收数据量
SOFTBUS_INT_ADAPTER_LOG_LEVEL	日志级别设置
SOFTBUS_STR_STORAGE_DIRECTORY	存储目录设置

因为软总线配置了后，不会默认启动，所以需要在通过启动框架调用InitSoftBusServer函数，如下：

static void DSoftBus(void)
{
    osThreadAttr_t attr;
    attr.name = "dsoftbus task";
    attr.attr_bits = 0U;
    attr.cb_mem = NULL;
    attr.cb_size = 0U;
    attr.stack_mem = NULL;
    attr.stack_size = 65536;
    attr.priority = 24;

    extern void InitSoftBusServer(void);
    if (osThreadNew((osThreadFunc_t) InitSoftBusServer, NULL, &attr) == NULL) {
        printf("Failed to create WifiSTATask!\n");
    }
}

APP_FEATURE_INIT(DSoftBus);

RPC部件适配

在config.json中增加rpc部件配置如下：

{
  "component": "rpc"
},

同样地，rpc部件需要通过启动框架调用StartDBinderService函数，由于该函数正常运行依赖主机已经获取IP地址，因此在LWIP协议栈注册IP地址变化事件的回调函数中调用该函数，如下：

static void RpcServerWifiDHCPSucCB(struct netif *netif, netif_nsc_reason_t reason,
                                   const netif_ext_callback_args_t *args)
{
    (void) args;
    if (netif == NULL) {
        printf("%s %d, error: input netif is NULL!\n", __FUNCTION__, __LINE__);
        return;
    }
    if (reason == LWIP_NSC_IPSTATUS_CHANGE) {
        if (netif_is_up(netif) && !ip_addr_isany(&netif->ip_addr)) {
            printf("%s %d, start rpc server!\n", __FUNCTION__, __LINE__);
            StartDBinderService();
        }
    }
}

static void WifiDHCPRpcServerCB(void)
{
    NETIF_DECLARE_EXT_CALLBACK(WifiReadyRpcServerCallback);
    netif_add_ext_callback(&WifiReadyRpcServerCallback, RpcServerWifiDHCPSucCB);
}

APP_FEATURE_INIT(WifiDHCPRpcServerCB);

启动恢复子系统适配

启动恢复子系统适配bootstrap_lite/syspara_lite两个部件。请在vendor/bestechnic_bak/display_demo/config.json中新增对应的配置选项。

{
  "subsystem": "startup",
  "components": [
	{
	  "component": "bootstrap_lite"		 --- bootstrap_lite 部件
	},
	{
	  "component": "syspara_lite",		 --- syspara_lite 部件
	  "features": [
		"enable_ohos_startup_syspara_lite_use_posix_file_api = true"
	  ]
	}
  ]
},

适配bootstrap_lite部件时，需要在连接脚本文件//device/soc/bestechnic/bes2600/liteos_m/sdk/bsp/out/best2600w_liteos/_best2001.lds中手动新增如下段：

       __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 = .;
      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 = .;
      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 = .;

需要新增上述段是因为bootstrap_init提供的对外接口，见//utils/native/lite/include/ohos_init.h文件，采用的是灌段的形式，最终会保存到上述链接段中。主要的服务自动初始化宏如下表格所示：

接口名	描述
SYS_SERVICE_INIT(func)	标识核心系统服务的初始化启动入口
SYS_FEATURE_INIT(func)	标识核心系统功能的初始化启动入口
APP_SERVICE_INIT(func)	标识应用层服务的初始化启动入口
APP_FEATURE_INIT(func)	标识应用层功能的初始化启动入口

说明：
通过上面加载的组件编译出来的lib文件需要手动加入强制链接。

如在 vendor/bestechnic/display_demo/config.json 中配置了bootstrap_lite 部件

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

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

static void Init(void)
{
    static Bootstrap bootstrap;
    bootstrap.GetName = GetName;
    bootstrap.Initialize = Initialize;
    bootstrap.MessageHandle = MessageHandle;
    bootstrap.GetTaskConfig = GetTaskConfig;
    bootstrap.flag = FALSE;
    SAMGR_GetInstance()->RegisterService((Service *)&bootstrap);
}
SYS_SERVICE_INIT(Init);   --- 通过SYS启动即SYS_INIT启动就需要强制链接生成的lib

在//base/startup/bootstrap_lite/services/source/BUILD.gn文件中，描述了在out/v200zr/display_demo/libs 生成 libbootstrap.a，如下：

static_library("bootstrap") {
  sources = [
    "bootstrap_service.c",
    "system_init.c",
  ]
  ....

那么需要在 vendor/bestechnic/display_demo/config.json 配置强制链接库bootstrap，如下：

  "bin_list": [
    {
      "elf_name": "wifiiot",
      "bsp_target_name": "best2600w_liteos",
      "signature": "false",
      "burn_name": "rtos_main",
      "enable": "true",
      "force_link_libs": [
        "bootstrap",	 --- 强制链接libbootstrap.a
        ...
      ]
    },

适配syspara_lite部件时，系统参数会最终写到文件中进行持久化保存。在轻量系统中，文件操作相关接口有POSIX接口与HalFiles接口这两套实现。

因为对接内核的文件系统，采用POSIX相关的接口，所以features字段中需要增加enable_ohos_startup_syspara_lite_use_posix_file_api = true。

如果对接HalFiles相关的接口实现的，则无须修改。

在适配GetSerial接口时，开发板不像产线生产过程那样，会写入一个具体的Serial Number，因而需要确定一个数据对开发板进行唯一标识。本案例采用WiFi Mac地址进行适配。

#define ETH_ALEN 6
#define MAC_BITS 4
#define MAC_HIGH_MASK 0xf0
#define MAC_LOW_MASK 0x0f
#define HEX_A 0xa
#define CHAR_NUM_OFFSET 0x30
#define CHAR_CAPITAL_OFFSET 0x37
#define STR_END_FLAG '\0'

typedef unsigned char               u8;

static char serialNumber[2*ETH_ALEN + 1];		 --- 最后一位留作'\0'结束符标识


static char Hex2Char(u8 hex)
{
    if (hex < HEX_A) {
        return hex + CHAR_NUM_OFFSET;			 --- 将数值0转为char的'0'
    } else {
        return hex + CHAR_CAPITAL_OFFSET;		 --- 将数值0xa转为char的'A'
    }
}

const char* HalGetSerial(void)
{
    char macAddr[ETH_ALEN];
    // as devboard has no production serial number, we just
    // use wifi mac address as device serial number.
    if (serialNumber[0] == STR_END_FLAG) {		 --- 只有第一次调用时，才去获取mac地址
        extern int bwifi_get_own_mac(u8 *addr);
        bwifi_get_own_mac(macAddr);				 --- 获取mac地址
        int j = 0;
        for (int i = 0; i < ETH_ALEN; i++) {
            u8 lowFour, highFour;
            highFour = (macAddr[i] & MAC_HIGH_MASK) >> MAC_BITS;
            serialNumber[j] = Hex2Char(highFour);
            j++;
            lowFour = macAddr[i] & MAC_LOW_MASK;
            serialNumber[j] = Hex2Char(lowFour);
            j++;
        }		 --- 将mac地址值转化为serial number
    }
    return serialNumber;
}

DFX子系统适配

进行DFX子系统适配需要添加hilog_lite部件，直接在config.json文件配置即可。

{
  "subsystem": "hiviewdfx",
  "components": [
	{
	  "component": "hilog_lite",
	  "optional": "true"
	}
  ]
},

配置完成之后，在//device/soc/bestechnic/bes2600/liteos_m/components/utils/src/hm_sys.c中注册日志输出实现函数。

boolean HilogProc_Impl(const HiLogContent *hilogContent, uint32 len)
{
    char tempOutStr[LOG_FMT_MAX_LEN] = {0};
    if (LogContentFmt(tempOutStr, sizeof(tempOutStr), hilogContent) > 0) {
        printf(tempOutStr);
    }
	return TRUE;   
}

HiviewRegisterHilogProc(HilogProc_Impl);

系统服务管理子系统适配

进行系统服务管理子系统适配需要添加samgr_lite部件，直接在config.json配置即可。

{
  "subsystem": "systemabilitymgr",
  "components": [
	{
	  "component": "samgr_lite",
	  "features": [
		"config_ohos_systemabilitymgr_samgr_lite_shared_task_size = 4096"
	  ]
	}
  ]
},

在轻量系统中，samgr_lite配置的共享任务栈大小默认为0x800。当函数调用栈较大时，会出现栈溢出的问题。在本次适配过程中，将其调整为0x1000。

安全子系统适配

进行安全子系统适配需要添加huks/deviceauth_lite部件，直接在config.json配置即可。

    {
      "subsystem": "security",
      "components": [
        {
          "component": "huks",
          "features": [
            "huks_use_lite_storage = true",
            "huks_use_hardware_root_key = true",
            "huks_config_file = \"hks_config_lite.h\"",
            "huks_key_store_path = \"/data/\"",
            "ohos_security_huks_mbedtls_porting_path = \"//device/soc/bestechnic/hals/mbedtls\""
          ]
        },
        {
          "component": "deviceauth_lite",
          "features": [
            "deviceauth_storage_path = \"/data/\"",
            "deviceauth_hichain_thread_stack_size = 9472"
          ]
        }
      ]
    }

huks部件适配时，huks_key_store_path配置选项用于指定存放秘钥路径，ohos_security_huks_mbedtls_porting_path配置选项用于指定进行mbedtls适配的目录，用于芯片对mbedtls进行硬件随机数等适配。

deviceauth_lite部件适配时，deviceauth_storage_path配置选项用于指定存放设备认证信息的路径，deviceauth_hichain_thread_stack_size用于指定线程栈大小。

媒体子系统适配

进行媒体子系统适配需要添加histreamer部件，直接在config.json配置即可。

{
  "subsystem": "multimedia",
  "components": [
    {
      "component": "histreamer",
      "features": [
        "histreamer_enable_plugin_hdi_adapter = true",
        "histreamer_enable_plugin_minimp3_adapter = true",
        "histreamer_enable_plugin_ffmpeg_adapter = false",
        "config_ohos_histreamer_stack_size = 65536"
      ]
    }
  ]
},

histreamer部件配置项说明如下：

配置项	说明
histreamer_enable_plugin_hdi_adapter	是否使能histreamer对接到hdi接口
histreamer_enable_plugin_minimp3_adapter	是否使能插件适配minimp3
histreamer_enable_plugin_ffmpeg_adapter	是否使能插件适配FFmpeg
config_ohos_histreamer_stack_size	histreamer栈大小设置

公共基础库子系统适配

进行公共基础库子系统适配需要添加kv_store/js_builtin/timer_task/kal_timer部件，直接在config.json配置即可。

{
  "subsystem": "utils",
  "components": [
	{
	  "component": "kv_store",
	  "features": [
		"enable_ohos_utils_native_lite_kv_store_use_posix_kv_api = true"
	  ]
	},
	{
	  "component": "js_builtin"
	},
	{
	  "component": "timer_task"
	},
	{
	  "component": "kal_timer",
	}
  ]
},

与适配syspara_lite部件类似，适配kv_store部件时，键值对会写到文件中。在轻量系统中，文件操作相关接口有POSIX接口与HalFiles接口这两套实现。因为对接内核的文件系统，采用POSIX相关的接口，所以features需要增加enable_ohos_utils_native_lite_kv_store_use_posix_kv_api = true。如果对接HalFiles相关的接口实现的，则无须修改。

图形子系统适配

进行图形子系统适配需要添加graphic_utils部件，直接在config.json配置即可。

    {
      "components": [
        {
          "component": "graphic_utils",
          "features": [
            "enable_ohos_graphic_utils_product_config = true"
          ]
        },
        {
          "component": "ui"
        }
      ]
    },

graphic配置文件见 //vendor/bestechnic/display_demo/graphic_config/product_graphic_lite_config.h。

graphic适配见//device/soc/bestechnic/bes2600/liteos_m/components/ui, 主要功能如下：

• display_device：实例化BaseGfxEngine。
• touch_input：实例化PointerInputDevice。
• UiMainTask：初始化字体引擎，执行渲染任务等。

图形子系统层次：

aafwk_lite + appexecfwk_lite    (AAFWK + APPEXECFWK)
      |
ace_engine_lite + jerryscript + i18n_lite + resmgr_lite + utils/native/lite/... (ACE,JS引擎及其依赖)
      |
arkui_ui_lite + graphic_utils      (图形框架)
      |
giflib + libjpeg + libpng + qrcodegen + freetype... (图形第三方库)

图形应用示例见文件//vendor/bestechnic/display_demo/tests/app.cpp，如下：

/* ui app entry */
void RunApp()
{
#ifdef UI_TEST
    AnimatorDemoStart(); 	 --- native ui demo
#elif defined(ABILITY_TEST)
    StartJSApp(); 			 --- js demo
#endif
}

void AppEntry(void)
{
    UiMain();
}

APP_FEATURE_INIT(AppEntry);

ACE开发框架子系统适配

进行ACE开发框架子系统适配需要添加ace_engine_lite部件，直接在config.json配置即可。

{
  "subsystem": "ace",
  "components": [
    {
      "component": "ace_engine_lite",
      "features": [
        "enable_ohos_ace_engine_lite_product_config = true"
      ]
    }
  ]
},

ace_engine_lite部件配置文件见 //vendor/bestechnic/display_demo/ace_lite_config/product_acelite_config.h。

ace_lite的应用采用js语言进行开发，详细步骤如下：

1. 用DevEco Studio编写js应用，参考轻量级智能穿戴开发。
2. 使用预览功能进行预览，并且得到js包：entry\.preview\intermediates\res\debug\lite\assets\js\default。
3. 将js包放到对应的文件系统目录下，文件系统路径为vendor/bestechnic/display_demo/fs/data/data/js，如下：

├── app.js
├── common
├── i18n
├── manifest.json
└── pages

4. 最终编译生成系统镜像，烧录到单板后，系统会从app.js加载启动ace的应用。

元能力子系统适配

进行元能力子系统适配需要添加aafwk_lite部件，直接在config.json配置即可。

    {
      "subsystem": "aafwk",
      "components": [
        {
          "component": "aafwk_lite",
          "features": [
            "enable_ohos_appexecfwk_feature_ability = true",	 --- 支持FA特性，即包含图形能力
            "config_ohos_aafwk_ams_task_size = 4096"			 --- 配置aafwk栈的大小
          ]
        }
      ]
    },

aafwk_lite相关的应用样例见vendor/bestechnic/display_demo/tests/ability目录，包含launcher和js app这两类应用，应用的函数调用流程描述如下：

1. launcher应用，通过InstallLauncher安装BundleName为 "com.example.launcher"的native ui应用，在AbilityMgrSliteFeature启动后会调用AbilityMgrHandler::StartLauncher()启动launcher应用。

2. StartJSApp应用，通过StartAbility启动任意Want，通过将want data传递JS_APP_PATH,
   SetWantData(&want, JS_APP_PATH, strlen(JS_APP_PATH) + 1)。

包管理子系统适配

进行包管理子系统适配需要添加appexecfwk_lite部件，直接在config.json配置即可。

    {
      "subsystem": "appexecfwk",
      "components": [
        {
          "component": "appexecfwk_lite"
        }
      ]
    },

兼容性认证

产品兼容性规范

产品兼容性规范文档请参考产品兼容性SIG介绍。

XTS用例

XTS测试参考资料见xts参考资料，进行XTS子系统适配需要添加xts_acts/xts_tools部件，直接在config.json配置即可，配置如下：

{
  "subsystem": "xts",
  "components": [
    { "component": "xts_acts", "features":
      [
        "config_ohos_xts_acts_utils_lite_kv_store_data_path = \"/data\"",
        "enable_ohos_test_xts_acts_use_thirdparty_lwip = true"
      ]
    },
    { "component": "xts_tools", "features":[] }
  ]
}

其中，

• config_ohos_xts_acts_utils_lite_kv_store_data_path 是配置挂载文件系统根目录的名字。
• enable_ohos_test_xts_acts_use_thirdparty_lwip 表示如果使用thirdparty/lwip目录下的源码编译，则设置为true，否则设置为false。

全部跑完会有显示xx Tests xx Failures xx Ignored，如下：

...
[16:53:43:438]../../../test/xts/acts/utils_lite/kv_store_hal/src/kvstore_func_test.c:793:testKvStoreMaxSize004:PASS
[16:53:43:438]+-------------------------------------------+
[16:53:43:438]
[16:53:43:438]-----------------------
[16:53:43:438]32 Tests 0 Failures 0 Ignored 
[16:53:43:438]OK
[16:53:43:439]All the test suites finished!

报告提交

将上图XTS用例的情况保存为测试报告，上传到OpenHarmony兼容性测试网站进行认证，作为sig仓库转正到master仓库的必要条件。详细步骤如下：

步骤1：将XTS测试报告压缩成zip文件。

步骤2：生成测试报告的SHA校验码。本案例是将zip文件传到在线生成hash的网站生成SHA校验码。

步骤3：进入OpenHarmony兼容性测试网站上传报告。

• 其中API Level填写报告中的"sdkApiLevel"字段
• OS版本号填写报告中的"OS Version"字段。

todo

后续会补充以下方面的移植：

• 蓝牙
• bms包安装
• 验证运行JS的bytecode
• 分布式能力：dms、dm
• 分布式音乐播放器样例

porting-bes2600w-on-minisystem-display-demo.md

为了能让大家更好的学习鸿蒙（HarmonyOS NEXT）开发技术，这边特意整理了《鸿蒙开发学习手册》（共计890页），希望对大家有所帮助：https://qr21.cn/FV7h05

《鸿蒙开发学习手册》：

如何快速入门：https://qr21.cn/FV7h05

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

开发基础知识：https://qr21.cn/FV7h05

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

基于ArkTS 开发：https://qr21.cn/FV7h05

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

鸿蒙开发面试真题（含参考答案）：https://qr18.cn/F781PH

鸿蒙开发面试大盘集篇（共计319页）：https://qr18.cn/F781PH

1.项目开发必备面试题
2.性能优化方向
3.架构方向
4.鸿蒙开发系统底层方向
5.鸿蒙音视频开发方向
6.鸿蒙车载开发方向
7.鸿蒙南向开发方向