第三章 iTop3588平台移植OpenHarmony-4.0-Release

最新推荐文章于 2026-05-16 13:45:35 发布

原创最新推荐文章于 2026-05-16 13:45:35 发布 · 4k 阅读

48 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#harmonyos #开源 #开放原子 #程序人生 #python

OpenHarmony标准系统全栈开发实战录专栏收录该内容

5 篇文章

订阅专栏

iTop3588平台移植OpenHarmony-4.0-Release

第一章 OpenHarmony标准系统全栈开发实战导论

第二章 OpenHarmony开发环境搭建

第三章 iTop3588平台移植OpenHarmony-4.0-Release

第四章内核程序开发示例：HelloWorld（待发）

第五章 OpenHarmony标准系统全栈开发全流程第一例：开关工作指示灯（待发）

南向开发篇

第六章 Linux驱动适配HDF框架开发（待发）

第七章 GPIO设备纯HDF驱动开发（待发）

第八章 iTop3588平台Touchscreen驱动适配与功能调测（待发）

第九章 iTop3588平台Wifi驱动适配与功能调测（待发）

第十章 iTop3588平台Gmac驱动适配与功能调测（待发）

第十一章 iTop3588平台Bluetooth驱动适配与功能调测（待发）

第十二章 iTop3588平台Audio驱动适配与功能调测（待发）

第十三章 iTop3588平台Camera驱动适配与功能调测（待发）

第十四章使用PWM调节补光灯全栈开发（待发）

第十五章使用GPIO和PWM驱动云台电机全栈开发（待发）

前言

本文档旨在为小伙伴们快速在iTop3588开发平台上移植OpenHarmony 4.0 Release版本标准系统提供技术指导。iTop3588是一款基于Rockchip RK3588处理器的开发板，具有强大的计算能力和丰富的外设接口，非常适合作为OpenHarmony系统的硬件载体。OpenHarmony 4.0版本标准系统中开发套件同步升级到API 10，相比3.2 Release版本，新增了4000多个API，应用开发能力更加丰富；HDF新增200多个HDI接口，硬件适配更加便捷；持续优化了图形框架和方舟编译器（ArkCompiler），用户交互体验得到进一步提升；ArkUI组件定制化能力和组件动效能力也得到进一步增强；分布式硬件支持的范围扩大到音频和输入领域；分布式数据为开发者数据分享带来了全新的统一数据管理框架。另外，该版本在媒体、安全和隐私保护等方面也得到了进一步增强¹。将OpenHarmony 4.0 Release版本移植到iTop3588平台，可以充分利用该平台的硬件优势，为开发者提供一个高性能的OpenHarmony开发环境。

一、移植方案概述

1.代码目录结构介绍

OpenHarmony 4.0 Release代码一级目录结构如下：

图1：OpenHarmony 4.0 Release代码一级目录结构图

平台移植OpenHarmony系统涉及到的代码目录主要有：
- build：增加新的子系统及其白名单配置
- device：增加新的单板（device/board/{device_company}/{device_name}）与SoC（device/soc/{soc_company}/{soc_name}）
- drivers：HDF驱动框架与设备驱动
- vendor：增加新产品（vendor/{product_company}/{product_name}）

2.移植目标

在iTop3588开发平台上运行OpenHarmony 4.0 Release版本标准系统，实现以下基本功能运行正常：

启动系统
mipi屏显示
显示开机logo（uboot logo、kernel Logo）
显示开机动画
进入系统桌面
鼠标操作
hdc连接与操作（usb模式）

3.移植流程

为了实现上述移植目标，依据据标准系统移植指南²，我们需要在定义OpenHarmony 4.0 Release代码中增加iTop3588开发平台的产品定义，内核移植、mipi屏驱动适配、usb（含OTG）驱动适配和开机logo与动画制作。具体移植流程如下图：
iTop3588平台移植OpenHarmony 4.0 Release流程

图2：iTop3588平台移植OpenHarmony 4.0 Release流程图

注：图中灰底色过程为可省流程，因为OpenHarmony 4.0 Release中rk3588已定义好了，mipi和USB驱动在移植内核过程中也已适配好了，开机Logo与动画先使用其他平台（如dayu210）的即可。

4.移植方法

所谓在某个开发平台上移植OpenHarmony系统，其实现方法就是在OpenHarmony系统代码中完成定义和配置该平台对应的产品、主板、SoC(System of Chip)、内核、驱动等过程。小伙伴们可以按移植流程，参照标准系统方案的移植案例（如：标准系统方案之瑞芯微RK3568移植案例³），完成移植过程操作，有利于学习和理解在OpenHarmony系统中产品、开发板、SoC、内核之间的关联关系、更能深入理解OpenHarmony系统中的子系统、部件和模块之间的逻辑关系与配置方法。在开发实践中，使用这种标准方法在iTop3588开发平台移植OpenHarmony系统，过程比较多，用时比较长。而且大多情况下，是卡在无法完成系统编译的过程中，我们会将更多精力放在如何解决问题上去，无法快速达成移植目标。为此我以iTop3588平台移植为例，介绍并推荐一种快速在开发平台上移植OpenHarmony系统的方法，即在OpenHarmony 4.0 Release版本代码中，dayu210也是基于RK3588芯片的产品，SoC是相同的，因此我们先直接复制产品、开发板、内核和驱动相关的代码文件，再将这些代码中dayu210相关的平台参数值（包含文件名）批量替换为iTop3588平台参数值，最后逐个确认文件的正确性。这种方法可以保证iTop3588平台在代码结构与参数的完整性，既快又易成功。iTop3588重要参数定义及其值与dayu210与比较如下表：

参数名	iTop3588	dayu210	备注
product_name	itop3588	dayu210	产品名称
product_company和device_company	topeet	HiHope或hihope	设备公司名称
board和device_name	itop3588	rk3588	单板名称
soc_name	rk3588	rk3588	SOC名称
soc_company	rockchip	rockchip	SOC公司名称
product_path	vendor/topeet/itop3588	vendor/hihope/dayu210	产品路径
device_build_path	device/board/topeet/itop3588	device/board/hihope/dayu210	单板构建路径

从上表中看出iTop3588与dayu210的重要参数中，含有以下3个重要特点（批量替换时牢记此处的差异）：
- iTop3588的soc_name和soc_company值同dayu210相同。
- iTop3588的board和device_name同product_name值相同。
- dayu210的board和device_name同soc_name值相同。

二、定义产品

1.创建产品目录

cd /home/ivan/share/OpenHarmony-v4.0-release

mkdir -p vendor/topeet/itop3588

2.复制dayu210产品文件到产品目录中

cd /home/ivan/share/OpenHarmony-v4.0-release/vendor/topeet/itop3588

cp -rf /home/ivan/share/OpenHarmony-v4.0-release/vendor/hihop/dayu210/* ./

## 查看所有文件
tree

itop3588产品目录后所有文件

图3：复制dayu210产品文件到itop3588产品目录后所有文件示例图

3.替换文件名

cd /home/ivan/share/OpenHarmony-v4.0-release/vendor/topeet/itop3588

mv etc/param/hardware_dayu210.para etc/param/hardware_itop3588.para
mv etc/param/product_dayu210.para etc/param/product_itop3588.para

产品目录中替换文件名后文件差异

图4：产品目录中替换文件名后文件差异示例图

4.替换产品参数值

在产品目录中的所有的配置、脚本、自述等文件（包括：*.json、*.xml、*.cfg、*.hcs、*.para、*.build、*.gn、*.gni、*Makefile、*.sh、*.txt和*.md，还包括其它无扩展名的文件）中，依次替换以下产品参数值(不区分大小写)：

1）产品名称：将dayu210替换成itop3588

2）设备公司名称：将HiHope或hihope替换成topeet

3）单板名称：将rk3588替换成itop3588（注：此时只能手动确认方式单独替换单板名称，不能批量查找与替换单板名称，因为单板名称与SOC名称相同。）

**方法：依次在配置、脚本、自述等文件中批量查找与替换产品名称、设备公司名称和单板名称。**下面仅以gn和gni文件批量查找与替换产品名称的过程为例说明操作步骤，其他类型的文件与另外2个产品参数值替换操作均相同。

在windows文件资源管理器中，搜索产品目录中所有gn和gni文件（搜索通配符：*.gn*）

图5：产品目录中查找gn与gni文件示例图

使用Notepad++打开搜索结果中的所有文件（Notepad++当前窗口中先关闭已打开的文件，以免干扰操作），并在所有打开的文件中查找dayu210替换成itop3588。

图6：产品目录中所有gn与gni文件中替换产品名称示例图

重复上述过程，将所有配置、脚本、自述等文件中的产品名称、单板构建路径和设备公司名称全部替换完成，再使用Beyond Compare进行文件夹比对，并仔细检查每一个差异文件的变更是否正确。

图7：产品目录中替换产品参数值后所有变更的文件示例图

5.查看itop3588产品信息

itop3588产品信息定义在vendor/topeet/itop3588/config.json中。
itop3588产品定义信息

图8：itop3588产品定义信息示例图

三、定义单板

1.创建单板目录

cd /home/ivan/share/OpenHarmony-v4.0-release

mkdir -p device/board/topeet/itop3588

2.复制dayu210单板文件到单板目录中

cd /home/ivan/share/OpenHarmony-v4.0-release/device/board/topeet/itop3588

cp -rf /home/ivan/share/OpenHarmony-v4.0-release/device/board/hihope/dayu210/* ./

## 查看所有文件
tree

itop3588单板目录后所有文件

图9：复制dayu210单板文件到itop3588单板目录后所有文件示例图

3.替换文件名

cd /home/ivan/share/OpenHarmony-v4.0-release/device/board/topeet/itop3588

mv cfg/fstab.dayu210 cfg/fstab.itop3588
mv cfg/init.dayu210.cfg cfg/init.itop3588.cfg
mv cfg/init.dayu210.usb.cfg cfg/init.itop3588.usb.cfg
mv kernel/kernel_patch/linux-5.10/dayu210_patch kernel/kernel_patch/linux-5.10/itop3588_patch
mv updater/config/init.dayu210.usb.cfg updater/config/init.itop3588.usb.cfg

单板目录中替换文件名后文件差异

图10：单板目录中替换文件名后文件差异示例图

4.替换产品参数值

在单板目录中的所有的配置、脚本、自述等文件（包括：*.json、*.xml、*.cfg、*.hcs、*.para、*.build、*.gn、*.gni、*Makefile、*.sh、*.txt和*.md，还包括其它无扩展名的文件）中，依次替换产品名称、设备公司名称、单板名称和SOC路径（/device/soc/rockchip/ ${device_name}替换为/device/soc/rockchip/$ {soc_name}），操作方法同定义产品中替换产品参数值相同，此处不再赘述和举例。
单板目录中替换产品参数值后所有变更的文件

图11：单板目录中替换产品参数值后所有变更的文件示例图

四、移植内核

源码中已给所有平台提供了Linux 5.10的内核（kernel/linux/linux-5.10），但每个平台对内核要求有所不同（如编译与构建，dts配置，内核或驱动补丁等），所以不同平台应有自己的内核。iTop3588平台移植内核过程的重点是配置dts、修改内核编译脚本与替换loader相关固件文件，其它同dayu210保持一致。

1.配置iTop3588平台的dts

iTop3588平台的dts文件由开发板厂商提供，所有device/soc/rockchip/rk3588/kernel/arch/arm64/boot/dts/rockchip所有的dts文件及include结构如下：

itop3588-evb-linux.dts
├── itop3588-linux.dtsi
│   ├── rk3588.dtsi
│   │   ├── rk3588s.dtsi
│   │   │   └── rk3588s-pinctrl.dtsi
│   │   │       └── rockchip-pinconf.dtsi
│   │   └── rk3588-vccio3-pinctrl.dtsi
│   │           └── rockchip-pinconf.dtsi
│   ├── rk3588-evb.dtsi
│   └── rk3588-rk806-single.dtsi
├── rk3588-linux.dtsi
├── iTop-3588-mipi0.dtsi
└── iTop-3588-dphy3.dtsi

在device/soc/rockchip/rk3588/kernel/arch/arm64/boot/dts/rockchip/rk3588-linux.dtsi中的dayu210修改为itop3588：

## 将下面代码
bootargs = "earlycon=uart8250,mmio32,0xfeb50000 console=ttyFIQ0 root=PARTUUID=614e0000-0000 hardware=dayu210 default_boot_device=fe2e0000.mmc rw rootwait ohos.required_mount.system=/dev/block/platform/fe2e0000.mmc/by-name/system@/usr@ext4@ro,barrier=1@wait,required ohos.required_mount.vendor=/dev/block/platform/fe2e0000.mmc/by-name/vendor@/vendor@ext4@ro,barrier=1@wait,required ohos.required_mount.misc=/dev/block/platform/fe2e0000.mmc/by-name/misc@none@none@none@wait,required ohos.required_mount.bootctrl=/dev/block/platform/fe2e0000.mmc/by-name/bootctrl@none@none@none@wait,required";

## 修改成
bootargs = "earlycon=uart8250,mmio32,0xfeb50000 console=ttyFIQ0 root=PARTUUID=614e0000-0000 hardware=itop3588 default_boot_device=fe2e0000.mmc rw rootwait ohos.required_mount.system=/dev/block/platform/fe2e0000.mmc/by-name/system@/usr@ext4@ro,barrier=1@wait,required ohos.required_mount.vendor=/dev/block/platform/fe2e0000.mmc/by-name/vendor@/vendor@ext4@ro,barrier=1@wait,required ohos.required_mount.misc=/dev/block/platform/fe2e0000.mmc/by-name/misc@none@none@none@wait,required ohos.required_mount.bootctrl=/dev/block/platform/fe2e0000.mmc/by-name/bootctrl@none@none@none@wait,required";

在device/soc/rockchip/rk3588/kernel/arch/arm64/boot/dts/rockchip/Makefile增加以下代码：

dtb-$(CONFIG_ARCH_ROCKCHIP) += itop3588-evb-linux.dtb

2.修改内核编译脚本

在device/board/hihope/dayu210/kernel/make-ohos.sh中增加以下代码：

model_list=(
	......
	"ITOP3588      arm64 0xfe660000 itop3588-evb-linux  Image rockchip_linux_defconfig"
)

在device/board/hihope/dayu210/kernel/build_kernel.sh中更新以下代码：

# 将下面代码：
if [ "enable_ramdisk" == "${9}" ]; then
    ./make-ohos.sh BQ3588C1 enable_ramdisk
else
    ./make-ohos.sh BQ3588C1 disable_ramdisk
fi

# 修改成
if [ "enable_ramdisk" == "${9}" ]; then
    ./make-ohos.sh ITOP3588 enable_ramdisk
else
    ./make-ohos.sh ITOP3588 disable_ramdisk
fi

3.更正soc中codec与display相关模块的子系统名

device/soc/rockchip/rk3588/hardware/codec/BUILD.gn

device/soc/rockchip/rk3588/hardware/display/BUILD.gn

diff --git a/rk3588/hardware/codec/BUILD.gn b/rk3588/hardware/codec/BUILD.gn
index 3b625fa..51d6fa3 100755
--- a/rk3588/hardware/codec/BUILD.gn
+++ b/rk3588/hardware/codec/BUILD.gn
@@ -56,7 +56,7 @@ ohos_shared_library("libcodec_oem_interface") {
   }
 
   install_images = [ chipset_base_dir ]
-  subsystem_name = "hdf"
+  subsystem_name = "rockchip_products"
   part_name = "rockchip_products"
 }
 
diff --git a/rk3588/hardware/display/BUILD.gn b/rk3588/hardware/display/BUILD.gn
index 99dc77d..225690d 100755
--- a/rk3588/hardware/display/BUILD.gn
+++ b/rk3588/hardware/display/BUILD.gn
@@ -60,7 +60,7 @@ ohos_shared_library("libdisplay_buffer_vdi_impl") {
   install_enable = true
   install_images = [ chipset_base_dir ]
   innerapi_tags = [ "chipsetsdk" ]
-  subsystem_name = "hdf"
+  subsystem_name = "rockchip_products"
   part_name = "rockchip_products"
 }
 
@@ -98,7 +98,7 @@ ohos_shared_library("libdisplay_buffer_vendor") {
   install_enable = true
   install_images = [ chipset_base_dir ]
   innerapi_tags = [ "chipsetsdk" ]
-  subsystem_name = "hdf"
+  subsystem_name = "rockchip_products"
   part_name = "rockchip_products"
 }
 
@@ -153,7 +153,7 @@ ohos_shared_library("libdisplay_composer_vdi_impl") {
 
   install_enable = true
   install_images = [ chipset_base_dir ]
-  subsystem_name = "hdf"
+  subsystem_name = "rockchip_products"
   part_name = "rockchip_products"
 }
 
@@ -209,7 +209,7 @@ ohos_shared_library("display_composer_vendor") {
   ]
   install_enable = true
   install_images = [ chipset_base_dir ]
-  subsystem_name = "hdf"
+  subsystem_name = "rockchip_products"
   part_name = "rockchip_products"
 }
 
@@ -238,6 +238,6 @@ ohos_shared_library("display_gfx") {
 
   install_enable = true
   install_images = [ chipset_base_dir ]
-  subsystem_name = "hdf"
+  subsystem_name = "rockchip_products"
   part_name = "rockchip_products"
 }

五、增加子系统与白名单

从前面流程中可以看出，iTop3588平台移植OpenHarmony 4.0 Release版本标准系统时定义新的子系统，所以需要增加了子系统和白名单。

1.增加子系统

在build/subsystem_config.json中增加以下代码：

  "rockchip_products": {
    "path": "device/soc/rockchip",
    "name": "rockchip_products"
  },
  "product_topeet": {
    "path": "vendor/topeet",
    "name": "product_topeet"
  }

2.增加白名单

在build/compile_standard_whitelist.json中增加以下代码：

    "bundle_subsystem_error": [
        ......
        "vendor/topeet/itop3588/ohos.build",
        "device/board/topeet/itop3588/ohos.build"
    ],

六、编译与构建代码

1.itop3588产品编译指令

cd /home/ivan/share/OpenHarmony-v4.0-release

## 第一次全量编译,并编译sdk
./build.sh --product-name itop3588 --ccache --sparse-image build_product_type=DEBUG --enable_notice_collection=false --gn-args load_test_config=false -j4

##全量编译,不编译sdk
./build.sh --product-name itop3588 --ccache --sparse-image --no-prebuilt-sdk build_product_type=DEBUG --enable_notice_collection=false --gn-args load_test_config=false -j4

## 单编部件或模块
./build.sh --product-name ohos-sdk --ccache --sparse-image --no-prebuilt-sdk build_product_type=DEBUG --enable_notice_collection=false --gn-args load_test_config=false -j4 --build-target hdf_core


## 单编内核
cd /home/ivan/share/OpenHarmony-v4.0-release/out/kernel/src_tmp/linux-5.10

./make-ohos ITOP3588

2.编译中出现的问题与解决方法

编译sdk时，找不到glx.h文件

图12：找不到glx.h文件错误示例图

原因分析：错误发生在编译 Flutter/Skia 的 GLX 相关代码时，系统缺少 OpenGL 开发文件。

解决方法：Ubuntu系统中安装 OpenGL/GLX 开发包

sudo apt-get install libgl1-mesa-dev xorg-dev

编译kernel时，打内核补丁出错

图13：打内核补丁失败文件示例图

原因分析：错误发生在编译kernel时，kernel.patch中的文件与当前内核版本有冲突（注：我也是移完代码后，才发现dayu210在OpenHarmony 4.0 Release版本中的内核补丁未更新）。

解决方法：需要手动修改kernel.patch文件。

七、启动系统

1.启动系统

startup

图14：iTop3588平台烧录OpenHarmony-4.0-Release固件后启动画面

2.查看启日志

查看启动日志

图15：查看启动日志示例图

3.hdc连接与操作

hdc连接成功与执行命令

图16：hdc连接成功与执行命令示例图

3.启动时出现的问题与解决方法

内核日志中不断打印“audit: type=1400 audit(806.006:242): avc: denied…”信息

原因分析：错误发生在selinux进行安全检查过程，系统未适配完善。

解决方法：先关掉selinux安全检查，待系统适配完善后现开启。

## 运行时临时性修改,在板上系统中执行：
setenforce 0

## 运行时持久性修改，在板上系统中执行：
echo "SELINUX=Permissive" > /etc/selinux/config

## 永久性关闭（需编译代码），代码中修改base/security/selinux_adapter/selinux.gni
declare_args() {
  selinux_enforce = false
}

内核logo画面无法释放

原因分析：错误发生在display显示驱动代码中未释放显示logo内存。

解决方法：更新device/soc/rockchip/rk3588/hardware/display目录中的驱动代码。

总结

本次采用从dayu210平台复制替换的方式，快速在 iTOP-3588移植了OpenHarmony 4.0 Release系统，并适配了关键硬件驱动，成功实现了移植目标。下一步就可以在此平台上做OpenHarmony的内核编程、南向开发、服务能力开发、北向开发任务了。将此方案分享出来，是为小伙伴们在不同平台中移植OpenHarmony系统提供思路，对应的代码和补丁我会抽空整理出来，后续以资源方式发布。

参考

Device开发官网：https://device.harmonyos.com
OpenHarmony的Gitee仓库：https://gitee.com/openharmony
OpenHarmony官网：https://www.openharmony.cn/mainPlay
OpenHarmony官方文档：https://docs.openharmony.cn/

https://gitee.com/openharmony/docs/blob/master/zh-cn/release-notes/OpenHarmony-v4.0-release.md ↩︎
https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/porting/standard-system-porting-guide.md ↩︎
https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/porting/porting-dayu200-on_standard-demo.md ↩︎