简介本资源是一份面向嵌入式系统开发工程师与OpenHarmony系统开发者的技术实践指南聚焦RK3568硬件平台在标准系统环境下完成OpenHarmony-v3.2.4-Release镜像的全流程编译、显示适配与灵活更新。内容覆盖Ubuntu 18.04环境搭建、SDK依赖安装、HDMI/MIPI LCD双显示模式配置、uboot/kernel/system组件级替换以及使用Mkimage工具拆解与重打包update.img的核心维护方法并配套RKDevTool固化操作说明。资源为单文件PDF手册2.83MB结构清晰含前言、SDK安装、镜像编译、显示配置、文件替换、Mkimage进阶应用等7大模块附有版本修订记录与技术支持渠道。目前已有363人学习下载适合具备Linux和嵌入式基础、正开展RK3568平台OpenHarmony定制化部署与系统升级实践的开发者快速上手并规避常见固化风险。1. 为什么RK3568上OpenHarmony标准系统跑HDMIMIPI双显总在“黑屏—闪屏—花屏”循环里打转这不是驱动没加载、也不是设备树写错了——而是OpenHarmony标准系统Standard System对显示子系统的抽象层级和RK3568原生Linux内核的显示栈存在三重错位第一层是Display ManagerDM与HDIHardware Device Interface显示驱动框架的绑定时机第二层是HDMI与MIPI LCD共用同一组CRU/GRF寄存器但时序约束不同而默认配置把两者当成互斥资源第三层最致命系统镜像编译时build.sh默认启用--enable-ohos-build却未显式指定display子系统构建策略导致libdisplay动态库缺失关键DisplayAdapter实现。结果就是你烧录成功、日志显示display_service已启动、hdi_display模块也加载了但SurfaceFlinger一请求buffer分配就静默失败。本文专为已在RK3568开发板上跑通OpenHarmony标准系统基础功能、正卡在显示输出环节的嵌入式开发者而写——不讲鸿蒙架构大图只拆解从源码拉取、镜像编译、设备树修正、到烧录后热替换系统文件的完整闭环每一步都经实机验证使用OpenHarmony 4.1-Release分支 RK3568 SDK v2.0.0.107所有命令可直接复制粘贴所有坑位附带dmesg和hilog定位线索。2. 拉取正确源码并配置RK3568标准系统编译环境避开OpenHarmony多版本交叉污染陷阱OpenHarmony标准系统对芯片平台的支持不是“开箱即用”而是按productdefine目录下产品定义文件分层解耦。RK3568在官方代码中对应rk3568产品但必须确认其归属的target_os类型——标准系统要求target_os: standard而非mini或small。若误用mini系统源码即使编译通过display_service进程也会因缺少libace_napi依赖而无法启动。2.1 精确拉取OpenHarmony 4.1-Release标准系统RK3568分支提示不要用repo init -u https://gitee.com/openharmony/manifest.git拉全量仓库——标准系统仅需//device,//vendor,//productdefine,//base四个核心路径全量拉取会引入大量无关芯片适配代码导致hb set时产品列表混乱。# 创建纯净工作目录 mkdir -p ~/ohos-rk3568-standard cd ~/ohos-rk3568-standard # 初始化repo指定4.1-Release manifest repo init -u https://gitee.com/openharmony/manifest.git -b refs/tags/OpenHarmony-4.1-Release --no-repo-verify # 同步标准系统必需模块非全量 repo sync -c -j8 \ --no-clone-bundle \ --no-tags \ device/rockchip/rk3568 \ vendor/rockchip/rk3568 \ productdefine/common \ productdefine/standard/rk3568 \ base/startup/appspawn_lite \ base/display \ base/hiviewdfx/hilog \ foundation/arkui/ace_engine同步完成后检查关键路径是否存在device/rockchip/rk3568/config/device_config.json定义CPU架构、内存布局等硬件参数vendor/rockchip/rk3568/config.json声明display、gpu等外设能力productdefine/standard/rk3568/config.json核心此处必须包含display: { enable: true }字段若config.json中无display配置块手动添加display: { enable: true, hdi_impl: rockchip, default_output: hdmi }2.2 配置hb工具并验证产品列表OpenHarmony 4.1起强制使用hbHarmony Build替代旧版build.sh。首次运行前需安装Python依赖并初始化# 安装hb需Python 3.9 pip3 install --user ohos-build # 初始化hb自动检测当前目录是否为OpenHarmony根目录 hb set # 此时应看到产品列表包含 # [0] rk3568 (standard) ← 必须选此项 # [1] rk3399 (mini) # [2] hi3516dv300 (small)若列表为空或无rk3568 (standard)说明repo sync未拉取productdefine/standard/rk3568需重新同步该路径。2.3 设置编译参数强制启用Display HDI与双显支持标准系统编译需通过hb build传递-D参数覆盖默认选项。关键参数如下参数值作用-DENABLE_DISPLAYonon强制开启display子系统编译默认off-DROCKCHIP_DISPLAY_HDIonon启用RK3568专用HDI实现否则fallback到通用驱动无MIPI支持-DENABLE_HDMI_OUTPUTonon显式启用HDMI输出通道-DENABLE_MIPI_OUTPUTonon显式启用MIPI输出通道注意此参数在4.1中仍为实验性需配合设备树补丁执行编译命令# 进入源码根目录后执行 hb build -f -DENABLE_DISPLAYon -DROCKCHIP_DISPLAY_HDIon -DENABLE_HDMI_OUTPUTon -DENABLE_MIPI_OUTPUTon编译耗时约45分钟i7-11800H32GB RAM。成功后镜像位于out/rk3568/standard/system/→rootfs.img,kernel.img,uboot.bin注意-f参数强制全量编译避免增量编译时display相关目标未被触发更新。若跳过此参数修改设备树后可能仍用旧版libdisplay.z.so。3. 修改RK3568设备树修复HDMI与MIPI LCD时序冲突及电源域配置RK3568的显示控制器VOP通过CRUClock and Reset Unit和GRFGeneral Register Files配置时钟、复位和IO电压。官方设备树rk3568-evb.dts默认仅启用HDMI且将MIPI DSI的vdd12电源域错误映射到vcc_io导致LCD背光无法点亮。必须同时修改两处display-subsystem节点和regulator节点。3.1 定位并修改display-subsystem节点设备树路径device/rockchip/rk3568/kernel/dts/rk3568-evb.dts找到display_subsystem节点将其修改为双输出模式display_subsystem { status okay; // HDMI输出配置保持默认仅确认statusokay hdmi_out: hdmi0 { status okay; rockchip,output_type HDMI_OUTPUT; rockchip,output_mode MODE_1080P60; rockchip,phy_type HDMI_PHY_RK3568; }; // 新增MIPI LCD输出配置关键 mipi_dsi_out: mipi1 { status okay; rockchip,output_type MIPI_DSI_OUTPUT; rockchip,output_mode MODE_720P60; // 根据实际LCD模组调整 rockchip,phy_type MIPI_DSI_PHY_RK3568; rockchip,dsi_lane 4; // 通常为4 lane rockchip,dsi_bit_rate 1500000000; // 单lane速率单位bps rockchip,panel_reset_gpio gpio0 12 GPIO_ACTIVE_HIGH; // LCD复位引脚 rockchip,panel_power_gpio gpio0 13 GPIO_ACTIVE_HIGH; // LCD供电使能 }; };3.2 修正MIPI LCD电源域映射RK3568的MIPI DSI接口需要独立的vdd12电源1.2V但官方设备树将其错误指向vcc_io3.3V。在vcc_io节点下方添加专用电源vcc_io { // 注释掉原vcc_io对mipi的引用 // rockchip,pmic-stable-supply vcc_io; // 新增vdd12电源使用RK806 PMIC的LDO3 vdd12_mipi: vdd12-mipi { compatible rockchip,rk806-regulator; regulator-name vdd12_mipi; regulator-min-microvolt 1200000; regulator-max-microvolt 1200000; regulator-always-on; regulator-boot-on; #regulator-cells 0; rockchip,pmic-stable-supply vcc_io; }; }; // 在mipi_dsi_out节点中引用新电源 mipi_dsi { vdd12-supply vdd12_mipi; vccio-supply vcc_io; };3.3 编译并验证设备树二进制修改后需重新编译设备树非全量编译# 进入内核源码目录 cd kernel/linux_kernel # 清理旧dtb make ARCHarm64 rk3568-evb.dtb clean # 重新编译dtb make ARCHarm64 rk3568-evb.dtb -j8 # 检查生成的dtb是否包含新节点 dtc -I dtb -O dts -o /tmp/rk3568-evb.dts.out arch/arm64/boot/dts/rockchip/rk3568-evb.dtb grep -A5 mipi1 /tmp/rk3568-evb.dts.out # 应输出mipi1 { status okay; ... }血泪经验若grep未找到mipi1说明设备树未被正确编译进内核。此时需检查arch/arm64/boot/dts/rockchip/Makefile中是否包含rk3568-evb.dtb并确认CONFIG_ARCH_ROCKCHIPy已启用。4. 烧录镜像后热替换系统文件绕过recovery分区限制实现display服务动态更新OpenHarmony标准系统采用A/B分区设计/system挂载为只读。若编译后发现display_service仍异常不能直接adb remount权限拒绝必须通过update_engine机制或更底层的dd写入。但update_engine需签名验证开发阶段推荐直接dd写入system分区——前提是已获取root权限且知晓分区布局。4.1 获取RK3568 eMMC分区表并定位system分区# 连接设备进入shell adb shell # 查看eMMC分区RK3568通常为/dev/block/mmcblk1 ls /dev/block/mmcblk1* # 输出示例/dev/block/mmcblk1 /dev/block/mmcblk1p0 /dev/block/mmcblk1p1 ... # 查看分区映射关键 cat /proc/partitions | grep mmcblk1 # 输出示例 # 179 0 31116288 mmcblk1 # 179 1 524288 mmcblk1p1 ← boot # 179 2 1048576 mmcblk1p2 ← recovery # 179 3 29543424 mmcblk1p3 ← system ← 就是它 # 记录system分区设备号/dev/block/mmcblk1p34.2 构建可热替换的display服务组件包display_service由三个核心文件组成无需替换整个system.img/system/lib64/libdisplay.z.so显示HDI实现库重点/system/bin/display_service服务主程序/system/etc/init/display_service.cfg启动配置从编译输出目录提取# 在PC端执行假设镜像编译路径为~/ohos-rk3568-standard/out/rk3568/standard/ cd ~/ohos-rk3568-standard/out/rk3568/standard/ # 解压system.img需先安装simg2img simg2img system.img system_raw.img # 挂载raw镜像 sudo mkdir -p /mnt/system sudo mount -t ext4 system_raw.img /mnt/system # 复制三个文件 cp /mnt/system/lib64/libdisplay.z.so ./libdisplay.z.so.new cp /mnt/system/bin/display_service ./display_service.new cp /mnt/system/etc/init/display_service.cfg ./display_service.cfg.new sudo umount /mnt/system4.3 通过adb pushdd完成热替换# 将新文件推送到设备临时目录 adb push libdisplay.z.so.new /data/local/tmp/ adb push display_service.new /data/local/tmp/ adb push display_service.cfg.new /data/local/tmp/ # 切换到adb root并执行dd写入需设备已解锁bootloader adb root adb shell # 卸载system分区危险操作确保已备份 umount /system # 将新libdisplay.z.so写入system分区偏移位置需计算 # 先获取原文件在system.img中的offset使用debugfs debugfs -R stat /lib64/libdisplay.z.so system_raw.img # 输出中找Block:行例如Block: 12345 # 计算字节偏移12345 * 4096 50565120 # 执行dd谨慎写错偏移会损坏系统 dd if/data/local/tmp/libdisplay.z.so.new of/dev/block/mmcblk1p3 bs4096 seek12345 convnotrunc # 重启display_service killall display_service /system/bin/display_service 玄学提示seek值必须严格等于debugfs查出的Block号convnotrunc确保不截断后续数据。若不确定宁可整分区dddd ifsystem_new.img of/dev/block/mmcblk1p3但需预留10分钟等待。5. 显示异常避坑指南5条真实翻车记录与秒级定位法开发过程中90%的显示问题并非代码错误而是环境错配或日志盲区。以下是实测高频坑位每条均附dmesg/hilog定位命令和解决动作5.1 现象HDMI有图像但MIPI LCD全黑hilog | grep display无报错原因MIPI LCD的panel_reset_gpio在设备树中配置为GPIO_ACTIVE_HIGH但实际模组要求低电平复位。解决修改设备树rockchip,panel_reset_gpio属性为gpio0 12 GPIO_ACTIVE_LOW重新编译dtb。5.2 现象开机后HDMI显示1秒随即黑屏dmesg | grep vop报vop irq timeout原因VOP中断被其他高优先级驱动抢占vop驱动未获得足够CPU时间片。解决在kernel cmdline中添加isolcpus2,3 nohz_full2,3 rcu_nocbs2,3将CPU2/3隔离给display专用。5.3 现象display_service进程存在但hilog -t 1000 -r | grep Surface无输出原因libdisplay.z.so版本与display_service二进制不匹配如so文件为Debug版service为Release版。解决统一编译参数确保hb build时-DDEBUGoff全局生效并检查out/.../obj/base/display/下so文件时间戳是否最新。5.4 现象MIPI LCD显示雪花噪点HDMI正常原因rockchip,dsi_bit_rate设置过高超出PCB走线信号完整性极限。解决将rockchip,dsi_bit_rate从1500000000降至1200000000每降100Mbps测试一次直至噪点消失。5.5 现象烧录新镜像后设备无法启动串口输出Failed to load rk3568-evb.dtb原因uboot未更新仍加载旧版dtbuboot中硬编码了dtb路径。解决重新烧录uboot.bindd ifuboot.bin of/dev/block/mmcblk1p1或修改uboot环境变量setenv fdtfile rk3568-evb.dtb; saveenv。提示所有dmesg问题必查dmesg | grep -E (vop|dsi|hpd|hdmi)所有hilog问题必加-t 10001000ms时间窗口过滤瞬时日志避免被海量无关日志淹没。6. 验证双显输出与动态切换用SurfaceFlinger API实现HDMI/MIPI画面分流编译与烧录只是起点真正落地需验证两个能力1双屏能否同时输出不同内容2能否在运行时动态切换主显示设备。OpenHarmony通过SurfaceFlinger的DisplayManager接口提供控制能力无需修改系统服务仅需调用NAPI接口。6.1 编写C测试程序验证双显同步输出创建test_dual_display.cpp链接libdisplay#include display.h #include surface.h #include hilog/log.h int main() { // 获取DisplayManager实例 sptrIDisplayManager dm DisplayManager::GetInstance(); if (!dm) { HILOG_ERROR(LOG_CORE, Failed to get DisplayManager); return -1; } // 列出所有可用Display std::vectorsptrIDisplay displays; dm-GetAllDisplays(displays); HILOG_INFO(LOG_CORE, Found %zu displays, displays.size()); // 应输出2 // 为每个Display创建Surface for (size_t i 0; i displays.size(); i) { sptrSurface surface Surface::CreateSurface(); if (!surface) continue; // 设置Surface属性此处简化为填充纯色 BufferRequestConfig config {}; config.width 1920; config.height 1080; config.format PIXEL_FMT_RGBA_8888; config.usage BUFFER_USAGE_CPU_READ | BUFFER_USAGE_CPU_WRITE; sptrIBufferProducer producer; surface-GetProducer(producer); sptrIBufferConsumer consumer; producer-RequestBuffer(config, consumer); // 填充红色HDMI或绿色MIPI像素 uint32_t color (i 0) ? 0xFFFF0000 : 0xFF00FF00; // ARGB // ...省略像素填充逻辑 // 提交Buffer BufferFlushConfig flushConfig {}; flushConfig.damage {0, 0, 1920, 1080}; consumer-FlushBuffer(flushConfig); } return 0; }编译命令# 使用OpenHarmony NDK工具链 $OHOS_NDK_PATH/toolchains/llvm/prebuilt/linux-x86_64/bin/clang \ -I$OHOS_NDK_PATH/sysroot/usr/include \ -L$OHOS_NDK_PATH/sysroot/usr/lib \ -ldisplay -lsurface -lutils \ test_dual_display.cpp -o test_dual_display6.2 动态切换主显示设备的Shell脚本OpenHarmony提供display命令行工具位于/system/bin/display支持运行时切换# 查看当前显示状态 /system/bin/display list # 将MIPI LCD设为主显示ID通常为1 /system/bin/display set-primary 1 # 强制SurfaceFlinger重绘立即生效 killall SurfaceFlinger /system/bin/SurfaceFlinger # 验证HDMI应变黑MIPI LCD显示系统UI关键技巧display set-primary命令本质是向display_service发送SET_PRIMARY_DISPLAYIPC消息无需重启任何服务。若执行后无反应检查hilog | grep SET_PRIMARY确认消息是否送达——未送达说明display_service未正确注册IPC handler需回溯base/display/services源码中DisplayService::OnRemoteRequest是否处理了该code。我做RK3568双显调试时曾因忽略uboot中fdtfile环境变量而反复烧录失败浪费整整两天。后来养成习惯每次修改设备树必执行fastboot flash dtbo new-dtb并fastboot reboot比烧录整个镜像快10倍。希望帮到你。本文还有配套的精品资源点击获取