RK-Forge:为我们移植的Linux 7.1 补上那块属于我们的板级设备树

rk-forge 已经开源！带你从零把一颗几乎没人理的 RK3506，用主线 Linux（7.1）+ 主线 U-Boot 一路跑到 rk3506 login:——可按序打上去的补丁库、诚实的差距报告、完整 bringup 教程都在这。欢迎观摩，喜欢点个⭐！

仓库地址：https://github.com/Awesome-Embedded-Learning-Studio/rk-forge

静态网页：https://awesome-embedded-learning-studio.github.io/rk-forge/

有朋友反馈说希望有PDF渲染的版本，您可以戳戳：https://github.com/Awesome-Embedded-Learning-Studio/rk-forge/releases/tag/pdf%2F2026-06-23-1120，或者有其他更新的版本。因为我怕放百度网盘会被发文平台一脚踹飞，所以如果不方便上Github的朋友，可以私信我要一下百度网盘链接！

前言：主线有驱动的骨架，没有描述血肉的设备树

U-Boot 能跑了，下一步自然是内核。这里有个对项目定位极其关键的事实：主线 Linux 7.0.12 / 7.1 对 RK3506 是有驱动的——clk-rk3506、rst-rk3506、pinctrl-rk3506 这些早就合并进主线了。但驱动只是骨架，它还需要一份设备树告诉它"这颗 SoC 上有哪些控制器、各在什么地址、这块板子又启用了哪些"。而这份 DT，上游连 SoC 级的 rk3506.dtsi 都没有，更别提板级 dts。

这就是 Ch0 反复强调的那个结论落到实地：rk-forge 真正的贡献点，不是写驱动，而是补这块板级设备树，并且把它往上游推。这一章干的就是这件事——从 vendor 的 rk3502.dtsi 把 SoC 的描述搬过来、改成主线纯的，再给我们这块 AES 板写一份板级 dts。

补 SoC DT：从 vendor 搬，主线纯

搬 SoC 设备树这事，听起来像体力活，其实有个反直觉的发现能省不少事。我们把 vendor SDK 的板级 DT include 链一路扒下来，发现 vendor 对这块板的 DT 其实稀疏得很：io-domains 它根本不通过 DT 建模（loader 配 IO 电压），PMIC 它也不用（全 fixed regulator），连 MTD 分区都是走 cmdline ubi.mtd=... 而不是 DT 节点。换句话说，"对齐 vendor"能对齐的并不多——迁移的真身，是补上 vendor 省略掉的那些主线板级 DT。

具体补的 rk3506.dtsi（SoC 级），核心是 cru（时钟）、grf/grf_pmu（寄存器）、ioc（IO 控制器）、pinctrl 加 gpio0-4、uart0、gic、timer、otp，以及 sfc（SPI Flash 控制器）节点。clock-ID 这块和 vendor 共用同一套 rockchip,rk3506-cru.h，所以适配量不大。然后在板级 rk3506b-aes.dts 里启用 &sfc、挂上 flash@0（那颗 Winbond W25N04KV SPI-NAND），再配 fixed-partitions 把 7 个分区（uboot/misc/vnvm/recovery/boot/rootfs/userdata）按我们自己的 parameter 表摆好。这里有个省心的点：W25N04KV 主线的 drivers/mtd/nand/spi/winbond.c本来就支持（芯片 id aa,23，4Gb），不用我们写一行 NAND 驱动代码。

坑之一：SFC 读出来全是坏的——80MHz 裸奔的代价

DT 补好，内核一起来，SPI-NAND 读出来的数据却是坏的——bit 错、OOB 读坏，mtd bad 一查甚至报出过半"坏块"。笔者当时一度真以为这颗 NAND 出厂就半残，差点往坏块管理的方向深挖。

真因其实很朴素：主线那个 rockchip_sfc.c 驱动从来不写采样延迟线（DLL）的调谐，而 vendor 驱动是会的。80MHz 这么高的频率裸奔，没有 DLL 做采样窗口调谐，读到的 bit 是非确定性地翻的，OOO 也跟着读坏——那些"坏块"全是 80MHz 把 OOB 读坏造成的假象，块本身是好的。当时的解法是一行 DT：把 spi-max-frequency 从 80MHz 降到 50MHz，50MHz 下读就稳了，bringup 够用。

诚实交代一句后续：后来我们把 vendor 的 DLL 调谐移植进了主线 sfc 驱动（patches/linux/0002），扫出采样窗口，把读速拿回了 80MHz。完整 saga 见 pitfalls/04。但 bringup 那会儿，50MHz 是最快见效的路。

坑之二：bootm 把自己覆盖了

内核 FIT 准备好，在 U-Boot 的 => 提示符下把它读进内存、bootm 跳过去，听起来天经地义。但第一版笔者把 kernel FIT 暂存到了 0x02080000——这正是内核自己的加载地址。bootm 一边解压、一边往同一个地址写，自己把自己覆盖了，直接崩。

解法是换个不冲突的暂存地址：0x04000000。引导序列就成了这样：

=> mtd read boot 0x04000000 0 0xc00000
=> setenv bootargs 'earlycon=uart8250,mmio32,0xff0a0000 console=ttyS0,1500000'
=> bootm 0x04000000

把 kernel FIT 从 boot 分区读到 0x04000000，设好 bootargs，然后 bootm。0x04000000 这个数后面会反复出现，记住它就是"避开 kernel load 区的暂存点"。

坑之三：console "卡住"了，其实是波特率没带

内核好不容易起来了，Starting kernel ... 也打出来了，结果 earlycon 把控制权交接给真正的 ttyS0 console 之后，屏幕就"没动静"了——看着像内核卡死，其实人家在好好跑，只是你看不见。

这是 RK 的 DW 8250 console 的一个通病：bootargs 里 console=ttyS0 如果不跟波特率，console 接管后波特率不对，输出就乱了。正解是必须带波特率：console=ttyS0,1500000。上面那行 bootargs 里已经带上了。这种坑最磨人——你盯着一个"卡死"的串口排查半天内核，结果根因在 bootargs 漏了几个字符。

成功长这样

四个坑爬完，内核终于在板上起来了。下面这段是从内核 bringup 的定型 log（boot-sdl-stage-end-of-kernel-uboot-202606151100）里截的，一个字没合成：（PS，这个是开始，后续的话换成Linux 7.1了，没有冲突~）