说明：

文章由移远通信技术股份有限公司提供
以下内容包含了个人理解，仅供参考，如有不合理处，请联系笔者修改13677951658(微信同号)

笔者去年将rk3562芯片成功移植至OpenHarmony5.0.3版本（未使用oh公版内核，使用第三方5.10内核）。今年笔者决定升级至OpenHarmony6.1R版本,在此分享笔者总结的芯片升级OpenHarmony版本的常规步骤和升级至6.1r过程遇到的问题及其解决办法。

写作环境

• rk3562芯片
• OpenHarmony6.1r版本
• kernel 5.10内核

升级思路

适配一款 SoC 到 OpenHarmony 标准系统一般涉及四个目录，以 rk3568 为例：

• device/board/hihope/rk3568
• device/soc/rockchip/rk3568
• vendor/hihope/rk3568
• kernel/linux/linux-6.6

因此，芯片升级 OpenHarmony 版本通常需要同步升级这四个目录。但由于笔者的 rk3562 Linux 5.10 内核在适配 OpenHarmony 时已投入大量工作，因此选择保持内核不变，仍然沿用之前的第三方 5.10 内核。

笔者也曾尝试将 rk3562 内核升级至 OpenHarmony 公版 6.6.101，并实现了文件系统初步挂载，但发现需要迁移的内核板级驱动过多，最终决定继续使用 5.10 内核，主要改动 board、soc、vendor 三个目录。待实现 6.1r 初步点亮图形后，再逐步修复适配其他 OpenHarmony 功能。

1.获取社区6.1r源码

笔者在此选择6.1r刚发布时候的tag版本代码

注意6.1r编译依赖ubuntu22.04编译环境！！！

版本发布说明： https://gitcode.com/openharmony/docs/blob/master/zh-cn/release-notes/OpenHarmony-v6.1-release.md

repo init -u https://gitcode.com/openharmony/manifest -b refs/tags/OpenHarmony-v6.1-Release --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'

2.升级 vendor 相关配置和 config.json

主要涉及以下目录和文件：

.
├── config.json
├── hdf_config
├── image_conf
├── ohos.build
├── preinstall-config
├── resourceschedule
├── security_config
├── updater_config
└── window_config

注意事项：

• hdf_config：需先同步为 rk3568 的配置，否则会缺少必要服务导致系统功能异常，后续再逐步调整。
• config.json：最为关键，不同版本的子系统配置不同，务必及时同步更新。
• preinstall-config：系统应用配置，需同步更新为 rk3568 的版本。
• resourceschedule：资源配置，先同步为 rk3568 的版本，后续再适配修改。
• security_config：SA 服务配置，同样需同步更新为 rk3568 的版本，后续再适配修改。

3.先关闭foundation、appspawn、render_service保证文件系统挂载完整

在适配升级OpenHarmony版本时，一定是需要确认文件系统挂载正常的。在这之前关闭foundation、appspawn、render_service服务

以3568为例，vendor/hihope/rk3568/security_config/critical_reboot_process_list.json中将foundation、appspawn、render_service服务都修改为不启动

--- a/foundation/graphic/graphic_2d/graphic.cfg    2026-03-19 15:15:18.921933714 +0800
+++ a/foundation/graphic/graphic_2d/graphic.cfg    2026-03-19 15:14:46.323507554 +0800
@@ -41,7 +41,7 @@
     "services" : [{
             "name" : "render_service",
             "path" : ["/system/bin/render_service"],
-            "critical" : [1, 5, 60],
+            "critical" : [0, 0, 60],
             "importance" : -20,
             "uid" : "graphics",
             "gid" : ["system", "tp_host", "data_reserve", "dev_dma_heap", "composer_host"],
--- a/foundation/systemabilitymgr/safwk/etc/profile/foundation.cfg    2026-03-19 15:22:04.570424629 +0800
+++ a/foundation/systemabilitymgr/safwk/etc/profile/foundation.cfg    2026-03-19 15:21:49.558896626 +0800
@@ -43,7 +43,7 @@
     "services" : [{
             "name" : "foundation",
             "path" : ["/system/bin/sa_main", "/system/profile/foundation.json"],
-            "critical" : [1, 4, 240],
+            "critical" : [0, 0, 240],
             "importance" : -20,
             "uid" : "foundation",
             "permission" : [
--- a/base/startup/appspawn/appspawn.cfg    2026-03-19 15:00:02.028421412 +0800
+++ a/base/startup/appspawn/appspawn.cfg    2026-03-19 15:56:23.418598810 +0800
@@ -34,7 +34,7 @@
                       "--sandbox-switch on --bundle-name com.ohos.appspawn.startup --app-operate-type operate ",
                       "--render-command command --app-launch-type singleton --app-visible true"],
             "importance" : -20,
-            "critical" : [1, 4, 240],
+            "critical" : [0, 0, 240],
             "uid" : "root",
             "gid" : ["root"],
             "writepid" : ["/dev/memcg/perf_sensitive/cgroup.procs"],

坑点1：关闭selinux

6.1r关闭selinux通过设置build_selinux为true来实现,但是编译会遇到报错问题，笔者将其修复并且提交至社区主干仓库 https://gitcode.com/openharmony/startup_appspawn/pull/2652/diffs 。然后关闭之后发现foundation服务会crash,然后笔者参考了北方大佬的修改并修复提交社区主干仓库 https://gitcode.com/openharmony/security_selinux_adapter/pull/7673/diffs

或者这么写，也能关闭selinux (从北方大佬那里咨询的)

  "build_selinux": true,
  "subsystems": [
    {
      "subsystem": "security",
      "components": [
        {
          "component": "selinux_adapter",
          "features": [
          "selinux_adapter_enforce = false",
          "selinux_adapter_mcs_enable = false"        
          ]
        }
      ]
    },

坑点2：kernel 5.10 sys-prod、chip-prod、updater、userdata、chip_ckm、resource等分区无法被创建指向块设备文件的符号链接,导致后面Mount挂载失败

OpenHarmony系统中文件系统挂载的流程大致分成四个阶段

• Bootloader阶段，U-Boot从eMMC加载内核和ramdisk，并告诉内核要挂载哪些分区。
• 内核识别阶段，内核启动，解析bootargs中的ohos.required_mount.*参数，MMC驱动初始化，读取eMMC的GPT分区，为每个分区创建块设备节点（mmcblk0p1~p15），发送uevent事件到用户空间（包含PARTNAME分区名）

  [    6.042763]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15
  

• ueventd处理阶段，ueventd接收内核通知，为每个分区创建 /dev/block/by-name/XXX 符号链接

  symlink /dev/block/mmcblk0p7->/dev/block/platform/ff870000.mmc/by-name/system
  symlink /dev/block/mmcblk0p7->/dev/block/by-name/system
  

• init挂载阶段，init根据fstab分区表配置，解析cmdline中的ohos.required_mount.*参数 ,等待必需分区设备就绪（通过ueventd创建的符号链接）,按顺序执行挂载操作。

  GPT分区名 → 内核设备节点 → 符号链接 → 系统挂载点
  ─────────    ──────────    ───────    ────────
  system   →   mmcblk0p7  →  by-name/system → /usr
  vendor   →   mmcblk0p8  →  by-name/vendor → /vendor
  userdata →   mmcblk0p15 →  by-name/userdata → /data
  

同样的内核启动参数和分区文件 rk3562 6.6 内核 6.1r正常创建指向块设备文件的符号链接 ，且正常挂载

同样的内核启动参数和分区文件 rk3562 5.10 内核 6.1r 无法正常创建指向块设备文件的符号链接

笔者使用的内核挂载参数：

        bootargs = "earlycon=uart8250,mmio32,0xff210000 console=ttyFIQ0 root=PARTUUID=614e0000-0000 ohos.boot.eng_mode=on hardware=rk3562 default_boot_device=ff870000.mmc rw rootwait ohos.required_mount.system=/dev/block/platform/ff870000.mmc/by-name/system@/usr@ext4@ro,barrier=1@wait,required ohos.required_mount.vendor=/dev/block/platform/ff870000.mmc/by-name/vendor@/vendor@ext4@ro,barrier=1@wait,required ohos.required_mount.chip_ckm=/dev/block/platform/ff870000.mmc/by-name/chip_ckm@/chip_ckm@ext4@ro,barrier=1@wait ohos.required_mount.sys-prod=/dev/block/platform/ff870000.mmc/by-name/sys-prod@/sys_prod@ext4@ro,barrier=1@wait ohos.required_mount.chip-prod=/dev/block/platform/ff870000.mmc/by-name/chip-prod@/chip_prod@ext4@ro,barrier=1@wait ohos.required_mount.userdata=/dev/block/platform/ff870000.mmc/by-name/userdata@/data@ext4@discard,noatime,nosuid,nodev@wait,check,quota ohos.required_mount.misc=/dev/block/platform/ff870000.mmc/by-name/misc@none@none@none@wait,required rcupdate.rcu_expedited=1 rcu_nocbs=all";


参数解析：
earlycon=uart8250,mmio32,0xff210000 console=ttyFIQ0 root=PARTUUID=614e0000-0000 
ohos.boot.eng_mode=on
hardware=rk3562 default_boot_device=ff870000.mmc rw rootwait 

ohos.required_mount.system=/dev/block/platform/ff870000.mmc/by-name/system@/usr@ext4@ro,barrier=1@wait,required 
        
ohos.required_mount.vendor=/dev/block/platform/ff870000.mmc/by-name/vendor@/vendor@ext4@ro,barrier=1@wait,required 

ohos.required_mount.chip_ckm=/dev/block/platform/ff870000.mmc/by-name/chip_ckm@/chip_ckm@ext4@ro,barrier=1@wait 

ohos.required_mount.sys-prod=/dev/block/platform/ff870000.mmc/by-name/sys-prod@/sys_prod@ext4@ro,barrier=1@wait 

ohos.required_mount.chip-prod=/dev/block/platform/ff870000.mmc/by-name/chip-prod@/chip_prod@ext4@ro,barrier=1@wait 

ohos.required_mount.userdata=/dev/block/platform/ff870000.mmc/by-name/userdata@/data@ext4@discard,noatime,nosuid,nodev@wait,check,quota 

ohos.required_mount.misc=/dev/block/platform/ff870000.mmc/by-name/misc@none@none@none@wait,required rcupdate.rcu_expedited=1 rcu_nocbs=all

笔者的分区表,注意userdata分区修改为了ext4格式

# fstab file.
#<src>                                                  <mnt_point> <type>    <mnt_flags and options>                              <fs_mgr_flags>
/dev/block/platform/ff870000.mmc/by-name/system               /usr       ext4     ro,barrier=1  wait,required
/dev/block/platform/ff870000.mmc/by-name/vendor              /vendor        ext4     ro,barrier=1  wait,required
/dev/block/platform/ff870000.mmc/by-name/chip_ckm            /chip_ckm        ext4      ro,barrier=1  wait
/dev/block/platform/ff870000.mmc/by-name/sys-prod              /sys_prod        ext4     ro,barrier=1  wait
/dev/block/platform/ff870000.mmc/by-name/chip-prod              /chip_prod        ext4     ro,barrier=1  wait
/dev/block/platform/ff870000.mmc/by-name/userdata               /data       ext4     discard,noatime,nosuid,nodev  wait,check,quota
/dev/block/platform/ff870000.mmc/by-name/misc /misc none none wait,required

只有带有 required 标志的分区才会被加入 devices 列表 ，ueventd 才会优先处理它们。

笔者使用的5.10内核在6.1r中需要显式添加匹配，base/startup/init/ueventd/ueventd.c中添加缺失的分区名匹配：

            strstr(uevent->partitionName, "userdata") != NULL ||
            strstr(uevent->partitionName, "updater") != NULL ||
            strstr(uevent->partitionName, "resource") != NULL ||
            strstr(uevent->partitionName, "chip_ckm") != NULL ||
            strstr(uevent->partitionName, "sys-prod") != NULL ||
            strstr(uevent->partitionName, "chip-prod") != NULL ||

这样才能解决文件系统的挂载问题

坑点3 SELinux 未加入 LSM 链导致系统反复重启

具体内容

需要在内核配置中修改 CONFIG_LSM 参数：

• 原配置：CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,bpf"
• 修改后：CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"

故障链路

如果不将 SELinux 加入 LSM 链，会引发以下连锁反应：

1. load_policy 失败 → SELinux 策略未能加载到内核
2. set secon u:r:watchdog_service:s0 失败（错误22，EINVAL）
3. watchdog_service 无法设置正确的 SELinux 上下文
4. 服务启动后立即退出（退出码21）
5. Init 进程检测到关键服务反复启动失败
6. 触发系统重启恢复机制

结论

这是一个内核配置问题，5.10 版本内核需要显式将 SELinux 相关模块加入 LSM 链，否则 SELinux 策略无法正常加载，导致关键服务启动失败并引发系统重启循环。

具体查看：5.10版本内核watchdog_service启动失败log

作为对比：6.6版本内核watchdog_service启动正常log

---

总结

本文详细记录了 rk3562 芯片从 OpenHarmony 5.0.3 升级至 6.1r 版本的完整过程，核心要点如下：

升级策略

• 内核选择：考虑到 5.10 内核已投入大量适配工作，选择保持内核不变，仅升级 board、soc、vendor 三个目录。
• 渐进式适配：优先实现系统点亮和图形显示，再逐步完善其他功能。

关键步骤

1. 获取源码：使用 6.1r 发布时的 tag 版本，注意编译环境需 Ubuntu 22.04。
2. 升级 vendor 配置：重点同步 config.json、hdf_config 等关键配置文件。
3. 分阶段调试：先关闭关键服务确保文件系统正常挂载，再逐步启用。

主要坑点

坑点	问题原因	解决方案
SELinux 关闭失败	编译报错、foundation crash	修复代码并提交社区，或设置 selinux_adapter_enforce = false
分区符号链接创建失败	5.10 内核 ueventd 分区名匹配缺失	在 ueventd.c 中添加缺失的分区名匹配
系统反复重启	SELinux 未加入 LSM 链	修改 CONFIG_LSM 添加 selinux 等模块