第2篇：我把一块跑 Android 11 的开发板,换成了 OpenHarmony先说结论:我手上有一块 RK3568

本文是《从零到一:把一块 RK3568 开发板移植到 OpenHarmony 6.1 全记录》系列的第 2 篇(开篇),讲清楚"移植"这件事的全貌。零基础也能看懂。

先说结论:我手上有一块 RK3568 开发板,原厂系统是 Android 11。过去几周,我在把它改造成一台跑 OpenHarmony 6.1 的设备。这不是"刷机",刷机只是换现成包;移植是从底层开始,让一个操作系统"认识"一块它从没见过的硬件。

这篇文章不讲细节,只建全貌。看完你会知道:移植总共要做哪几件事、每件事是干嘛的、为什么缺一不可。

一、一个操作系统要认识硬件,需要五份"资料"

把操作系统想象成一个刚入职的新员工,要接手一台他没见过的新机器。他需要:

资料	比喻	项目里的实体
硬件说明书	机器图纸:有哪些零件、怎么接线	设备树文件(*.dtsi)
操作手册	每个零件怎么操作	驱动(内核驱动 + HDF 驱动)
功能清单	哪些功能开关打开	defconfig 内核配置
工位档案	这台设备在公司里的位置	板级目录 + 产品目录
出厂设置	硬盘怎么分区、开机口令	分区表、参数文件、init 脚本

这次移植,这五份资料全部重做或适配了一遍。后面每篇技术文,其实都在写这五份资料之一。

二、为什么 PC 装系统不用"移植",开发板要?

普通 PC 装 Windows/Linux 几乎"零适配",因为 PC 行业有统一标准:BIOS/UEFI 会自动汇报硬件清单(几根内存、什么显卡、多大硬盘),操作系统即插即知。

而嵌入式开发板没有这套机制:

每块板的接线都不一样——同样是 RK3568 芯片,A 厂的板子屏幕接第 1 路 MIPI 接口,B 厂可能接第 2 路
没有"自动汇报",系统必须被事先告知硬件在哪、怎么接
所以每块新板子都要写一份专属的"硬件说明书"

这份说明书就是设备树(Device Tree),它是整个移植工作中工作量最大的部分。第 5、6 篇会专门讲它。

三、移植的六大块工作

① 环境准备 ──→ ② 板级/产品建档 ──→ ③ 内核适配(说明书+开关)
     │                                      │
     └──────→ ④ 驱动适配(HDF) ──→ ⑤ 多模组变体框架
     (并行)        │
                   └──────────→ ⑥ 编译 + 烧写验证

① 环境准备:磨刀不误砍柴工

下载 21GB 编译工具链 + 6.8GB 预编译 SDK,修掉 11 个系统兼容性坑(上一篇全记录了)。没有这步,后面全是空中楼阁。

② 板级/产品建档:给设备"上户口"

OpenHarmony 的规矩:每块板子、每个产品都要有自己的目录:

device/board/chishi/cheshit10/          ← 板级档案:这台设备怎么组装
vendor/chishi/cheshit10_standard/       ← 产品档案:这台设备卖什么配置

不建档,构建系统根本不知道这台设备的存在。这一步是从官方参考板复制改造的(工程上叫 fork),而不是从零写。

③ 内核适配:写说明书 + 开开关

这是主战场。两件事:

写设备树:把这台板子的硬件信息(屏幕 1024x600、触摸 TW3106、网卡 RTL8201F、双摄像头...)写成内核能读的说明书
配 defconfig:打开需要的功能开关(4G 上网、触摸驱动、音频驱动...)

④ 驱动适配:配操作手册

OpenHarmony 有自己的驱动框架 HDF。这步做了三件事:

屏幕驱动"参数化":官方驱动把屏参写死在代码里,我改成启动时读设备树——以后换屏只改说明书不改代码
新写 TW3106 触摸驱动:官方没有这颗芯片的驱动,我从 Android 源码翻译协议,按 HDF 模板写了一版
接通 4G 通路:让系统能自动认出插的是哪款 4G 模组

⑤ 多模组变体框架:一块板,多副面孔

业务上,这块板子以后会搭配不同的屏幕、触摸芯片、4G 模组。如果每个组合一套固件,3 屏 × 4 触摸 × 3 模组 = 36 套,维护噩梦。于是设计了变体框架(第 9 篇详讲):

分辨率不同 → 编译期一个参数切换
同尺寸的触摸/屏供应商不同 → 一个固件自动探测适配
4G 模组不同 → 永远自动识别

⑥ 编译 + 烧写:临门一脚

把源码变成能烧进板子的镜像(boot_linux.img / system.img / vendor.img...),烧进 eMMC,真机验证。这部分目前还在进行,后续会在系列里同步结果。

四、这次移植最关键的三个认知

1. 硬件没变,变的是说明书的"方言"。 这块板的硬件信息,在 Android 源码里已经有一份说明书(Android 的 DTS)。移植的大部分工作是把它"翻译"成 OpenHarmony 内核能读的版本——比如内核从 4.19 换到了 6.6,同样的内容要用新语法重写。

2. OpenHarmony 不是从零造轮子。 它的内核还是 Linux,所以"认识硬件"的底层机制(设备树、驱动)和 Android 是同一套思想。鸿蒙特有的部分是 HDF 驱动框架和板级/产品目录结构。

3. 移植 = 大量"对照翻译" + 少量"从零新写"。 大部分工作是翻译(屏幕初始化序列逐字节照抄),小部分是 OH 没有、必须新写的(比如 TW3106 的 HDF 驱动)。

写在最后

如果你也是嵌入式方向的新人,我的建议是:找一块真板子,做一次真移植。教程看十遍不如动手改一次设备树——你会被迫理解内核、驱动、构建系统的每一层,而这些知识是看文档永远看不出来的。

这篇是全貌,下一篇开始拆零件:零基础认识一块 RK3568 开发板上的每一个部件。

📚 本系列文章导航

《从零到一:把一块 RK3568 开发板移植到 OpenHarmony 6.1 全记录》