RK-Forge为我们移植的Linux 7.1 补上那块属于我们的板级设备树之前我们把主线 U-Boot 在板上跑起来了这章我们往这块底座上塞内核。主线 Linux 对 RK3506 的 clk、pinctrl、reset 驱动其实早就在了可偏偏连这颗 SoC 的设备树都没有——这块板级 DT 正是 rk-forge 的核心贡献。这章我们把它补出来一行行解码 bootlog直到 earlycon 亮起、console 真正接管。走完这一章boot 系列的三块硬骨头工具链 → U-Boot → 内核到 console就全部啃下来了。rk-forge 已经开源带你从零把一颗几乎没人理的 RK3506用主线 Linux7.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 分区都是走 cmdlineubi.mtd...而不是 DT 节点。换句话说对齐 vendor能对齐的并不多——迁移的真身是补上 vendor 省略掉的那些主线板级 DT。具体补的rk3506.dtsiSoC 级核心是 cru时钟、grf/grf_pmu寄存器、iocIO 控制器、pinctrl 加 gpio0-4、uart0、gic、timer、otp以及 sfcSPI Flash 控制器节点。clock-ID 这块和 vendor 共用同一套rockchip,rk3506-cru.h所以适配量不大。然后在板级rk3506b-aes.dts里启用sfc、挂上flash0那颗 Winbond W25N04KV SPI-NAND再配 fixed-partitions 把 7 个分区uboot/misc/vnvm/recovery/boot/rootfs/userdata按我们自己的 parameter 表摆好。这里有个省心的点W25N04KV 主线的drivers/mtd/nand/spi/winbond.c本来就支持芯片 idaa,234Gb不用我们写一行 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 降到 50MHz50MHz 下读就稳了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 earlyconuart8250,mmio32,0xff0a0000 consolettyS0,1500000 bootm 0x04000000把 kernel FIT 从 boot 分区读到0x04000000设好 bootargs然后 bootm。0x04000000这个数后面会反复出现记住它就是避开 kernel load 区的暂存点。坑之三console 卡住了其实是波特率没带内核好不容易起来了Starting kernel ...也打出来了结果 earlycon 把控制权交接给真正的 ttyS0 console 之后屏幕就没动静了——看着像内核卡死其实人家在好好跑只是你看不见。这是 RK 的 DW 8250 console 的一个通病bootargs 里consolettyS0如果不跟波特率console 接管后波特率不对输出就乱了。正解是必须带波特率consolettyS0,1500000。上面那行 bootargs 里已经带上了。这种坑最磨人——你盯着一个卡死的串口排查半天内核结果根因在 bootargs 漏了几个字符。成功长这样四个坑爬完内核终于在板上起来了。下面这段是从内核 bringup 的定型 logboot-sdl-stage-end-of-kernel-uboot-202606151100里截的一个字没合成Starting kernel ... [ 0.000000] Linux version 7.0.12-dirty ... #1 SMP Sun Jun 14 22:13:58 CST 2026 [ 0.000000] OF: fdt: Machine model: AES RK3506B Board [ 0.000000] earlycon: uart8250 at MMIO32 0xff0a0000 (options ) [ 0.000000] Kernel command line: earlyconuart8250,mmio32,0xff0a0000 consolettyS0,1500000 ... [ 0.271255] printk: legacy console [ttyS0] enabled ... [ 1.054644] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)每一行都是一座里程碑Starting kernel说明 U-Boot 把内核成功交下来了Linux version 7.0.12是主线内核不是 vendor 的 6.1Machine model: AES RK3506B Board这一行最让人踏实——内核认出了我们亲手写的那份板级设备树earlycon和ttyS0 enabled说明 console 通了。最后那个panic: Unable to mount root fs不是 bug是预期——我们这章压根没配 rootfs它自然挂不上根文件系统。走到这里boot 系列三章走完PLAN §5 那个硬里程碑——“RK3506 用主线 Linux 启动到 UART”——算是实打实拿下了。你能从一根空的 SPI-NAND 或一张 SD 卡出发编出主线 U-Boot、补上板级设备树、把主线内核引到 console 亮起。这整条链除了那个暂时绕不开的 rkbin DDR blob从 U-Boot 到内核每一行都是主线源码、能追、能改、能 bisect。至于内核起来之后那行panic: Unable to mount root fs怎么消掉——怎么让 rootfs 真正持久地落进 SPI-NAND、怎么把外设一个个点亮——那是后续篇章的事不在 boot 系列里。boot 这三块硬骨头啃完了给板子拍张照撒花不过分。