从RK3576 Linux SDK手动适配RK3568，省下时间又省钱

 

 

 

做 Rockchip 嵌入式开发的朋友，大概率都遇到过官方 SDK “卡脖子” 的问题 —— 申请流程动辄几周、授权费用随项目规模增加，偏偏项目上线时间不等人。最近我们团队就遇到了这样的情况：需要基于 RK3568 开发物联网设备，但官方 SDK 申请还在排队，于是决定从已有的 RK3576 Linux SDK 手动适配，最终成功编译出 RK3568 的镜像。今天就来拆解这个适配过程，告诉你 “为什么要这么操作”，以及背后的技术逻辑。

 

 

 

一、先搞懂：为什么选 RK3576 SDK 适配 RK3568？

 

不是随便找个 SDK 就能适配，选择 RK3576 作为“基底”，核心原因是两者同属 Rockchip（瑞芯微）家族，硬件架构与软件生态高度兼容：

 

 

•架构共性：RK3576 和 RK3568 均基于 ARMv8-A 架构，内核编译链（aarch64-linux-gnu-）可复用，无需重新搭建交叉编译环境；

 

 

•驱动复用：两者共享大量 Rockchip 自研驱动（如电源管理、SPI、I2C 等），只需调整硬件参数（如 IO 电压、时钟频率），无需从零开发驱动；

 

 

•编译系统一致：均采用 Rockchip 标准的 Linux SDK 编译框架（Makefile+Kconfig + 设备树），修改方向清晰，无需重构编译流程。

 

 

简单说：用 RK3576 SDK 适配 RK3568，本质是 “复用已有生态，修改差异部分”，比从头搭建 SDK 效率高 10 倍以上。

 

 

二、核心适配操作解析：每一步都有“目的性”

 

我们先看这次适配的核心修改（基于提供的 diff 代码），每个操作都对应着 “让编译系统识别 RK3568” 的关键需求，不是无意义的文件搬运。

 

 

1. 芯片标识：告诉编译系统 “目标是 RK3568”

 

第一个修改是device/rockchip/.chip文件：

 

 

- .chips/rk3576     + .chips/rk3566_rk3568

这行代码是编译系统的“指路标” ——Rockchip SDK 通过.chip文件定位当前目标芯片的配置目录。之前指向 RK3576 的配置，现在改为 RK3566/RK3568（两者硬件差异小，可共用基础配置），后续编译时会自动加载device/rockchip/.chips/rk3566_rk3568/下的芯片专属配置。

 

 

2. 配置文件迁移：复用基础参数，修改芯片标识

 

接下来是将 RK3576 的核心配置文件（如boot.its、parameter.txt）迁移到 RK3566_RK3568 目录，并修改芯片相关标识：

 

 

# parameter.txt（分区配置文件）     - MACHINE_MODEL: RK3576     - MANUFACTURER: RK3576     + MACHINE_MODEL: rk3566_rk3568     + MANUFACTURER: rk3566_rk3568

•parameter.txt是 RK 芯片的分区表与硬件信息配置文件，编译时会生成镜像的分区结构（如 boot、rootfs、vendor 分区大小）；

 

 

•修改MACHINE_MODEL和MANUFACTURER，是为了让 U-Boot 和内核启动时识别 “当前硬件是 RK3568”，避免加载错误的硬件驱动。

 

 

而boot.its（镜像打包配置）、rockchip_defconfig（基础内核配置）等文件直接复用，是因为这些文件定义的“镜像打包规则”“内核基础功能开关”（如是否启用 USB、网络）在 RK3576/RK3568 上一致，无需修改。

 

 

3. 新增 RK3568 专属内核配置：适配硬件差异

 

关键一步是新增rockchip_rk3568_evb1_v10_defconfig文件：

 

 

RK_UBOOT_SPL=y                  # 启用U-Boot SPL（二级引导）     RK_KERNEL_DTS_NAME="rk3568-evb1-ddr4-v10-linux"  # 指定RK3568的设备树     RK_USE_FIT_IMG=y                # 启用FIT镜像格式（支持多设备树打包）

这是针对 RK3568 硬件的 “定制化开关” ：

 

 

•RK_KERNEL_DTS_NAME指定内核加载的设备树（DTS），设备树是 “硬件描述文件”，会告诉内核 “RK3568 的 CPU 频率、IO 口位置、外设地址” 等关键信息；

 

 

•没有这个配置，内核会默认加载 RK3576 的设备树，导致硬件不识别（比如 USB 口没反应、屏幕不亮）。

 

 

4. 设备树修改：调整硬件资源参数

 

最后是修改 RK3568 的设备树（rk3568-evb.dtsi）：

 

 

&pmu_io_domains {         status = "okay";     +   pmuio1-supply = <&vcc3v3_pmu>;  # PMU IO1供电改为3.3V         pmuio2-supply = <&vcc3v3_pmu>;         vccio1-supply = <&vccio_acodec>;     -   vccio3-supply = <&vccio_sd>;     -   vccio4-supply = <&vcc_3v3>;     +   vccio2-supply = <&vcc_1v8>;     # IO2供电改为1.8V     +   vccio3-supply = <&vcc3v3_pmu>;     +   vccio4-supply = <&vcc_1v8>;         # 其他电压域调整...     };

这部分是解决硬件“电压不匹配” 的核心：

 

 

•RK3568 的 PMU（电源管理单元）IO 电压域与 RK3576 不同（比如部分 IO 需要 1.8V，而非 3.3V）；

 

 

•如果不修改，会导致外设（如 SD 卡、SPI 设备）供电异常，轻则设备不工作，重则烧毁硬件。

 

 

三、为什么要这么操作？核心是“降本提效”

 

回到最初的问题：明明可以等官方 SDK，为什么要手动适配？答案藏在 “时间成本” 和 “经济成本” 里：

 

 

1.省时间：官方 SDK 申请流程通常需要 1-4 周（需提交项目证明、签订协议），而手动适配只需 1-2 天（基于已有 SDK 修改），项目能提前上线；

 

 

2.省费用：部分官方 SDK 针对商业项目收取授权费（尤其带专有驱动的版本），手动适配基于开源代码（如 Linux 内核、U-Boot），无额外成本；

 

 

3.灵活可控：官方 SDK 可能捆绑不必要的功能（如冗余驱动、定制化工具），手动适配可按需裁剪（比如关闭不需要的卫星通信模块），减少镜像体积。

 

 

当然，这种操作的前提是“拥有 RK3568 的依赖文件”—— 比如必要的驱动源码（如 MIPI 屏幕驱动）、固件文件（如 WiFi / 蓝牙固件），否则适配后会出现 “编译通过但外设不工作” 的问题。

 

 

四、实操注意事项：避坑指南

 

如果你也想尝试类似适配，这 3 点一定要注意：

 

 

1.备份原 SDK：修改前先备份 RK3576 SDK，避免误操作导致原项目无法编译；

 

 

2.核对硬件参数：必须拿到 RK3568 的硬件手册，确认 IO 电压、时钟频率、外设接口等参数，否则设备树修改会出错；

 

 

3.分步测试：先编译 U-Boot（确保能引导），再编译内核（确保硬件识别），最后编译 rootfs（确保系统正常启动），分步定位问题。

 

 

五、总结：嵌入式开发的“主动适配” 思维

 

其实，这次 RK3576 适配 RK3568 的核心逻辑，本质是 “利用芯片家族的共性，解决硬件差异的个性”。在嵌入式开发中，“等官方” 往往不是最优解 —— 尤其是中小团队或创业公司，面对时间紧、预算有限的情况，基于已有资源手动适配，不仅能节省成本，还能更深入理解芯片的底层逻辑。

 

 

最后想问：你在适配 Rockchip 或其他芯片时，遇到过哪些 “卡脖子” 的问题？欢迎在评论区分享你的解决方案～