当前位置：首页 > news >正文

拥抱鸿蒙 - 在展讯T606平台上的探索与实践

news 2025/7/7 15:26:00

前言

自OpenHarmony 问世后受到了社会各界的广泛关注，OpenHarmony 的生态系统在如火如荼的发展。

酷派作为一家积极拥抱变化的公司，经过一段时间的探索与实践，成功实现将OpenHarmony 系统接入到展讯平台上，我们相信这是一个重要的里程碑，标志着我们在推动OpenHarmony 的发展环节取得了重要进展。

本文基于的软硬件信息如下：

1.展讯 T606 Android 13(Kernel5.4)2.OpenHarmony v3.2.2 Release

本文受限于篇幅，将着重介绍GPU Mesa 开源方案在展讯平台上的适配。

图形架构

官方图形子系统的架构如下图:

GPU 的适配主要关注框架层的Render Service (渲染服务)，代码仓位于: //foundation/graphic/graphic_2d/。

Mesa 适配方案

在介绍详细的适配过程之前，我们先看下整体开发适配的架构图，如下：

我们在图形栈上的Mesa 适配工作主要包括用户层的Mesa 3D 以及Kernel 层的GPU 驱动 (panfrost)这两个方面。

此外需要注意的是，适配之前需要先将OpenHarmony 图形系统的gpu 配置项使能，如下：

      "subsystem": "graphic","components": [{"component": "graphic_standard","features": ["graphic_standard_feature_ace_enable_gpu = true","graphic_standard_feature_rs_enable_eglimage = true"]}]

Mesa 3D Library

T606 采用Mali-G57 GPU，OpenHarmony v3.2.2 的三方mesa3d 不支持，需要从上游版本移植，Mesa 22.2 开始支持。

一. 方案选择

我们认为有三个方案可选：

方案一：基于原有版本，参考Mesa上游合入Mali-G57 支持；

方案二：自行升级Mesa 版本至少到22.2，并添加OpenHarmony 支持；

方案三：直接使用4.0 的Mesa3d 仓，2023.8.30已经升级到22.4；

考虑到方案一相对方案二可能有较多的工作量，我们选择了方案二。不过，在经历方案二的一些波折后，我们发现官方已经升级了mesa3d，所以索性我们就直接切到方案三上，其实方案三的问题也不少。

二. 编译Mesa

我们的编译主机是Ubuntu 18.04, meson 版本是0.61.5。

首先我们希望Mesa 能跟随系统一起编译。可是，我们发现ohos/BUILD.gn 有如下部分：

action("mesa3d_build") {inputs = deps_inputsscript = "build_mesa3d.py"

有个输入依赖deps_inputs，是在ohos/dependency_inputs.gni 里定义的：

  21 declare_args() {22   deps_inputs = [23     "../CODEOWNERS",24     "../OAT.xml",25     "../VERSION",26     "../meson.build",27     "../meson_options.txt",...
6976     "../subprojects/libelf.wrap",
6977     "../subprojects/perfetto.wrap",
6978     "../subprojects/zlib.wrap",
6979   ]
6980 }

好家伙，接近7000行，看上去是包含所有的源码文件。那升级Mesa 版本肯定有一堆文件变动，难道我们要手动编辑这个gni文件？或是做个脚本统计？没必要。我们放弃这种编译方式，直接使用build_ohos.py，并把生成的库文件按ohos_prebuilt_shared_library打包到镜像里。

为了解耦system 和vendor，我们把所有的库文件都放到vendor 侧:

     run_build_cmd += '-Dplatforms=ohos -Degl-native-platform=ohos -Ddri-drivers= -Dgallium-drivers=panfrost \
-                      -Dvulkan-drivers= -Dgbm=enabled -Degl=enabled -Dcpp_rtti=false -Dglx=disabled -Dtools=panfrost -Ddri-search-path=/system/lib '
+                      -Dvulkan-drivers= -Dgbm=enabled -Degl=enabled -Dgles1=enabled -Dgles2=enabled -Dcpp_rtti=false -Dglx=disabled -Dtools= -Ddri-search-path=/vendor/lib64/chipsetsdk '

同时，gn 打包的安装路径要保持一致否则会找不到库：

  install_images = [ chipset_base_dir ]relative_install_dir = "chipsetsdk"

另外，编译过程生成的临时目录build-ohos，里面不仅仅存放着obj，还有一些重要文件，这是后话，先卖个关子，这正印证了没有实践就没有发言权。

编译过程会遇到一些错误，有的是本地环境导致，比如：

../src/util/u_endian.h:97:3: error: "UTIL_ARCH_LITTLE_ENDIAN and/or UTIL_ARCH_BIG_ENDIAN were unset."
# error "UTIL_ARCH_LITTLE_ENDIAN and/or UTIL_ARCH_BIG_ENDIAN were unset."

可以参考defined(ANDROID)分支添加大小端定义即可：

--- a/src/util/u_endian.h
+++ b/src/util/u_endian.h
@@ -89,6 +89,10 @@#endif+#define UTIL_ARCH_LITTLE_ENDIAN 1
+#define UTIL_ARCH_BIG_ENDIAN 0

编译成功后会生成如下so：

build-ohos/install/lib/libEGL.so.1.0.0
build-ohos/install/lib/libgbm.so.1.0.0
build-ohos/install/lib/libGLESv2.so.2.0.0
build-ohos/install/lib/libGLESv1_CM.so.1.1.0
build-ohos/install/lib/libglapi.so.0.0.0
build-ohos/src/gallium/targets/dri/libgallium_dri.so
build-ohos/install/lib/dri/panfrost_dri.so

Mesa GPU Driver

ARM 官方本身提供了kbase 驱动，但由于其闭源，且采用私有so 进行交互的方式，所以无法应用到OpenHarmony 上。

在展讯平台上，我们选择了Panfrost 这一ARM Mali 系列的GPU 开源驱动，panfrost 主要用于Midgard 和Bifrost 架构的GPU。与kbase 不同，panfrost 接入了Linux drm 框架，从原生层面提供了Linux GPU 驱动体验。

一. 功能移植

由于我们本次适配的展讯平台是基于Kernel 5.4，在5.4 版本上自带的panfrost 还没有支持Mali-G57，所以需要从上游移植panfrost。

关于panfrost 的移植过程可以分为三部分：

1.移植对Mali-G57 平台的支持，从上游backport patch set drm/panfrost: Valhall (JM) support。2.移植上游支持Mali-G57 之前，对其他平台提供的支持。避免丢失某些 Mali-G57 依赖的其他平台的特性。比如 bifrost 平台，以及其他一些 quirk。3.移植对Mali-G57 平台的漏洞修复。

Panfrost 无法解析基于Kbase 的dts，需要手动修改gpu-supply，interrupt-names 等项目。

二. SPRD** 客制化

Dts 中，除了基础的 compatible，寄存器，电源，中断，Sprd 还自定义了一些项目，比如动态调频的控制器和频率，GPU 状态寄存器，时钟等。为了让 GPU 正常工作，需要正确地设置时钟，并对一些必要的寄存器初始化。

在驱动层面，Sprd 在 kbase 驱动的基础上，封装了三组基于平台的接口：

1.平台初始化和退出2.power manager callback。这些接口注册后，kbase 会在合适的时候调用，比如 suspend/resume。3.动态调频接口，通过嵌入到 kbase 调频流程中发挥作用。

这部分是 sprd 针对 kbase 驱动单独添加的内容。如需要相关功能，需要移植到 panfrost 中。这里介绍一种能够启动 GPU 的最小化方案：移植平台初始化代码。

平台初始化代码主要负责频率获取，时钟使能。频率和时钟的信息都定义在 dts 中，最终解析结果如下：

gpu_dvfs_ctx.clk_gpu_i                  <&aonapb_gate CLK_GPU_EB>
gpu_dvfs_ctx.clk_gpu_core_eb            <&g1_pll CLK_RPLL_26M>
gpu_dvfs_ctx.clk_gpu_mem_eb             <&g5l_pll CLK_TGPLL_76M8>
gpu_dvfs_ctx.clk_gpu_sys_eb             <&g5l_pll CLK_TGPLL_153M6>
gpu_dvfs_ctx.gpu_clk_src [<&g5l_pll CLK_TGPLL_384M><&g5l_pll CLK_TGPLL_512M><&g5r_pll CLK_GPLL><&g5r_pll CLK_GPLL_850M>  // clk_set_rate(..., 650000_000)
]gpu_dvfs_ctx.freq_list = [384000512000614400650000
]

将平台初始化代码移植到panfrost ，基本可以使 GPU 正常工作。但是因为缺失了电源和频率模块，相关功能都不可用。我们尝试通过 /sys/class/devfreq 获取 GPU 频率，但只获取到一个错误的值（26M），跟踪相关代码发现 panfrost 将时钟绑定到了<&aonapb_gate CLK_GPU_EB> 上，但真正用于GPU 工作的是后四个clock，即 384M，512M，614M，650M。

调试验证

在调试Mesa 前需用三方modetest 测试图形显示是否正常。

Step1: 测试前需要先停掉render_service

service_control stop render_service

Step2: 使用atomic 方式来测试sprd 的图形驱动

# 指定 mode: connector_id=92, crtc_id=83, mode=720x1520
# 指定 plane: plane_id=31, crtc_id=83, weight*height=720*1520
modetest -a -M sprd -s 92@83:720x1520 -P 31@83:720x1520

正常的出图效果如下：

下面来看我们遇到的问题，在Mesa 适配完刷机后我们就发现系统在反复重启，内核能看到如下错误：

[   32.857012]c7 [ T1615] CPU: 7 PID: 1615 Comm: render_service Tainted: G S

主要是render_service 配置了critical 字段：

// graphic.cfg"services" : [{"name" : "render_service","path" : ["/system/bin/render_service"],"critical" : [1, 5, 60],

参考官方对critical 字段的说明：

其实就是服务重启次数过多了就重启系统，为了便于调试，我们可以设置为0 先不使能。

抓取到的render_service crash 栈如下:

能看出来渲染主线程Init 挂掉了，在添加日志后发现死在opengl_wrapper 的glGetString()，这个接口按理说是openGL 提供的标准接口，所以对于堆栈挂在这个接口上，我们一开始并没有太多的头绪。

随着通过不断加日志debug 梳理上下文的调用关系，最终定位是由于一个比较隐蔽的平台差异性问题导致，这里受限于篇幅就不详细展开了。

如下图，正常运行时的render_service crashCnt 是0，status 是running：

我们还未来得及欣喜，却又遇到如下crash:

死在Mesa 的libEGL 上，没有什么能阻挡我们前进的步伐，我们再次跟踪Mesa，也修复了此问题。

调试过程中hilog 可以使用-D 过滤日志:

-D , --domain= Show specific domain/domains logs with format: domain1,domain2,doman3 Don’t show specific domain/domains logs with format: ^domain1,domain2,doman3 Max domain count is 5.

图形domain ID 定义如下：

29 // The "0xD001400" is the domain ID for graphic module that alloted by the OS.30 constexpr OHOS::HiviewDFX::HiLogLabel LABEL_RS = { LOG_CORE, 0xD001400, "OHOS::RS" };31 constexpr OHOS::HiviewDFX::HiLogLabel LABEL_ROSEN = { LOG_CORE, 0xD001400, "OHOS::ROSEN" };

使用如下命令启动渲染服务时只抓图形log并存于本地：

hdc shell "hilog -D 0xD001400 & service_control start render_service" > hilog-rs.txt

另外，可以用一个gl_test 来验证，正常情况如下图，屏幕左上角会出现一个三角形：

性能分析

我们在移植结束后遇到了这样的一个问题，现象是：拖动桌面图标时界面卡顿。

熟悉Android 性能问题分析的小伙伴都知道，Android 提供了抓取trace 的atrace 工具，那么在OpenHarmony 平台上是否也有现成的抓取trace 功能呢？

其实OpenHarmony 提供了名为bytrace 的工具，借助这个工具我们可以抓取一份Ftrace ，命令如下：

echo > /sys/kernel/debug/tracing/trace
echo 90096 > /sys/kernel/debug/tracing/saved_cmdlines_size
bytrace -t 20 -b 90096 --overwrite ohos zimage zmedia zcamera zaudio ability distributeddatamgr graphic freq irq mdfs workq  mmc idle notification sync pagecache ace app > /data/Launcher.ftrace
echo > /sys/kernel/debug/tracing/trace

Ftrace 的抓取步骤和Android 平台是一样的，导出的Ftrace 文件用前端工具打开。

如下图所示：

很快，我们在Launcher 所在进程区域发现了异常，那就是当Launcher 界面卡顿时，应用的绘制和渲染侧都是空白的(红圈处)，所以自然而然也就没有帧送到屏幕上。

那么对于应用侧没有出帧的情况，根据我们以往的经验，通常是由于主线程被某个事务阻塞，导致没有办法响应Vsync 的callback。

结合Hilog 观测到如下片段持续高频的输出：

[js_progress.cpp(SetCircularStyle)-(1)] circular Style error. now use default scaleWidth

此时可以认定是由于Launcher 在调用框架接口SetCircularStyle 时陷入了循环调用中，另一方面也说明了应用自身的容错能力存在问题。

接下来的工作主要是跟着代码搜寻SetCircularStyle这一函数调用场景及排查报错的原因，最终我们解决了该问题，受限于篇幅不详细展开。

结语

在移植适配Mesa 到展讯平台的过程中，除了文中提到的问题，我们还遇到了许多棘手的问题，有图形领域相关的，也有不少平台兼容性的问题。

在解决这些问题的过程中，我们深感图形领域的错综复杂。未来，我们将不断地补齐短板，继续探索深耕图形领域，为OpenHarmony 的生态发展贡献我们的绵薄之力。

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

《鸿蒙 (Harmony OS)开发学习手册》

入门必看：https://qr21.cn/FV7h05

应用开发导读(ArkTS)
应用开发导读(Java)

HarmonyOS 概念：https://qr21.cn/FV7h05

系统定义
技术架构
技术特性
系统安全

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

基本概念
构建第一个ArkTS应用
构建第一个JS应用
……

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

应用基础知识
配置文件
应用数据管理
应用安全管理
应用隐私保护
三方应用调用管控机制
资源分类与访问
学习ArkTS语言
……

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

Ability开发
UI开发
公共事件与通知
窗口管理
媒体
安全
网络与链接
电话服务
数据管理
后台任务(Background Task)管理
设备管理
设备使用信息统计
DFX
国际化开发
折叠屏系列
……

前 言