1. 项目背景与核心痛点为什么偏偏选 RK3568 Linux 4.19先交代一下背景。最近手头一个工业控制类项目主控从全志切到了瑞芯微 RK3568。这颗芯片在国产化替代浪潮里算是明星选手了四核 Cortex-A55主频最高能到 2.0GHz内置 Mali-G52 GPU还有独立的 NPU0.8TOPs在做边缘计算、工业 HMI、电力网关这类产品时非常合适。更重要的是这颗芯片的官方 BSP 支持相当丰富从老内核 4.19 到新内核 5.10、6.1 都有适配不同业务场景可以选不同的内核版本。我这次选择的 Linux 4.19 内核原因很清楚稳定性和生态兼容性优先。项目里需要跑 EtherCAT 主站IgH、自研的实时采集线程还牵扯到一堆老设备的驱动程序。4.19 是长期维护版本工业设备厂商的驱动适配基本都是在这个版本上验证过的而且这个版本下瑞芯微的 SDK 非常成熟不像 5.10 和 6.1 那样在部分外设驱动上还需要自己折腾补丁。不过话说回来4.19 内核的默认配置是针对瑞芯微官方评估板EVB来的真拿到自己的板子上直接烧官方镜像大概率起不来或者起来之后网络不通、显示异常、触摸乱飘——这些都是做硬件定制时最常见的问题。整篇博文我会围绕最实际的场景来写从 SDK 环境准备到手动配置内核、编译镜像、处理设备树再到把板子真正跑起来全程用我这次调试 RK3568 的真实记录来还原整个流程。先给这篇文章的受众定个位正在做 RK3568或者其他瑞芯微平台定制底板开发、需要自己编译内核和设备树的嵌入式工程师以及刚从单片机切到嵌入式 Linux、想搞懂内核镜像构建全流程的初学者。我会尽量把每个操作步骤背后的原理讲明白而不只是丢一堆命令行让你照着抄。2. 开发环境搭建与 SDK 源码准备2.1 主机环境要求和基本依赖安装手动构建 RK3568 内核第一步不是下载源码而是把宿主机环境准备好。我的开发机是 Ubuntu 20.04 x86_64编译 RK3568 的 4.19 内核依赖的工具链和库说多不多但漏掉一个就能让编译报错而且错误信息往往很唬人容易浪费时间。必备依赖如下sudo apt-get update sudo apt-get install -y git gnupg flex bison build-essential zip \ curl zlib1g-dev libc6-dev-i386 x11proto-core-dev \ libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils \ xsltproc unzip fontconfig libncurses-dev \ device-tree-compiler bc cpio rsync几个容易忽略的点libncurses-dev必须装否则make menuconfig会直接报错终端图形配置界面打不开。device-tree-compiler是编译设备树必需的因为设备树的源文件.dts最终会被 dtc 工具编译成 .dtb。bc这个工具看起来不起眼但内核编译脚本里有用到缺了之后某些配置阶段会静默失败排查起来非常痛苦。如果经常编译 32 位相关的工具或者交叉工具链建议把lib32z1-dev和libc6-dev-i386一起装上避免后期 SDK 里有些辅助工具编译不过去。2.2 获取 RK3568 SDK 源码和交叉编译工具链瑞芯微的 SDK 目前主流是从官方 git 仓库拉取以 4.19 内核分支为例仓库地址是https://github.com/rockchip-linux/kernel分支名通常是develop-4.19。这个仓库里不只是内核源码还包含了设备树、编译脚本和配置文件。我这次是从一个已经初始化好的 SDK 目录开始的但在那之前标准的拉取方式是git clone https://github.com/rockchip-linux/kernel.git -b develop-4.19 rockchip-kernel cd rockchip-kernel内核交叉编译工具链瑞芯微推荐的方案是用prebuilts/gcc/linux-x86/aarch64/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/。这个 6.3.1 工具链在 4.19 内核编译上表现最稳定。如果你不想从 SDK 里提取工具链也可以用系统自带的交叉编译工具链sudo apt-get install -y gcc-aarch64-linux-gnu但说实话我建议优先用瑞芯微 SDK 自带的工具链。因为内核版本和工具链版本之间有个匹配问题用太新的 GCC 编译老内核有时候会出现编译告警变报错的情况得加额外参数才能过。比如 GCC 10 编译 4.19 内核时偶尔会因为某些结构体对齐或内联函数的问题报错而用 linaro 6.3.1 就屁事没有。2.3 理解 SDK 目录结构和镜像输出位置这里要先对 SDK 目录有个整体概念不然编译完找不到产物位置会非常懵。以官方 SDK 为例核心目录包括kernel/存放内核源码、设备树文件、配置文件。u-boot/存放 U-Boot 源码快速启动相关。device/rockchip/存放板级配置、分区表、镜像打包脚本。build.sh顶层编译/打包脚本一条命令生成完整镜像。output/编译输出固件的默认目录。我这次手动构建基本操作都在kernel/目录下面做最后把编译好的boot.img包含内核、dtb、ramdisk或者单独的kernel.img和resource.img提取出来再通过瑞芯微的打包工具烧写。简单解释一下RK3568 的 boot 镜像可以有两种形态一种是官方 SDK 默认的boot.img里面打包了内核和 dtb另一种是传统形态kernel.img放内核resource.img放 dtb 和 logo 图片。这个后面会展开讲。3. 内核配置的完整流程从默认配置到定制裁剪3.1 默认配置的选择rockchip_linux_defconfig 还是 board 级配置进入内核目录后第一步就是确定基础配置文件。RK3568 在 4.19 分支下最常用的默认配置是arch/arm64/configs/rockchip_linux_defconfig。这里有两个选择路径# 方式一使用常用默认配置推荐 make ARCHarm64 rockchip_linux_defconfig # 方式二使用某款评估板的完整配置 make ARCHarm64 rk3568-evb1-ddr4-v10-linux_defconfig区别在于rockchip_linux_defconfig覆盖了一整类 RK3568 开发板打开了很多通用驱动选项而rk3568-evb1-ddr4-v10-linux_defconfig是针对官方 EVB1 板型的会关闭一些无关模块编译更快但如果你换成自己设计的底板就得手动增删不少驱动。我的经验是先用 rockchip_linux_defconfig 把系统跑起来再谈裁剪和优化。直接用 evb 的配置很容易出现“板子型号差异导致某个外设驱动没被编进去”的问题。先用通用配置确认整体没问题再做增量修改会省掉大量排查时间。3.2 menuconfig 中必须检查的关键配置项当你执行make ARCHarm64 menuconfig进入图形配置界面后有几个关键位置必须过一遍Device Drivers - DMA Engine Support要确保 DMA 相关的框架打开因为 RK3568 的很多外设比如 SPI、I2S、Ethernet MAC依赖 DMA 传输。Device Drivers - Network device support需要确认千兆网卡驱动RTL8211F、YT8531、KSZ9031等 PHY 芯片驱动是否编译为模块或内建。如果你的底板是自定义 PHY这里特别容易漏。File systems如果你的根文件系统是 ext4这里默认基本没问题但如果用 SquashFS 做只读根文件系统就必须手动打开CONFIG_SQUASHFS。Device Drivers - Graphics supportRK3568 的 display 驱动依赖于 DRM/KMS 框架要确保CONFIG_DRM_ROCKCHIP被选中否则 HDMI 和 MIPI DSI 屏幕都不会亮。Kernel Features - Preemption Model如果你要做实时性要求比较高的应用比如 EtherCAT可以考虑把默认的 voluntary 抢占改成CONFIG_PREEMPT低延迟抢占。但不能盲目开某些驱动在抢占内核下会出现时序问题需要实测。3.3 裁剪配置的实战思路轻量化与实时性平衡很多新手一上来就想把内核配置裁到最小觉得“模块少了就稳定”其实这是误区。内核裁剪的目的是满足功能、体积和实时性三者之间的平衡而不是追求小。我这次的实际裁剪思路是关闭用不到的网卡驱动。RK3568 的 GMAC 只走 RGMII 接口只要保留对应 PHY 驱动即可其他 PHY 驱动全部关闭。关闭无线网络相关支持。如果产品不需要 WiFi/BT直接关闭CONFIG_CFG80211、CONFIG_MAC80211以及蓝牙协议栈能省掉几十个模块编译速度和镜像体积都有明显改善。保留 debugfs 和内核日志但生产版本可以关掉CONFIG_DEBUG_INFO减少内核符号文件大小。打开CONFIG_IKCONFIG_PROC这样内核起来之后可以在/proc/config.gz里看到当前实际配置后续排查配置问题非常方便。3.4 配置保存和 diff 检查配置改完之后推荐把最终配置保存为自定义名字便于版本管理make ARCHarm64 savedefconfig cp defconfig arch/arm64/configs/rk3568_custom_defconfigsavedefconfig会生成一份最小化的 defconfig把没改动的选项都省略掉用来做代码评审和 diff 非常清晰。比如你后期想对比官方默认配置和自己改动过什么只需要diff arch/arm64/configs/rockchip_linux_defconfig arch/arm64/configs/rk3568_custom_defconfig这样就可以清清楚楚看到每一项改动不至于过了几个月自己都忘了当初动过哪些配置。4. 内核镜像编译的全过程与常见报错排查4.1 设置环境变量与多线程编译编译之前先设置好环境变量export ARCHarm64 export CROSS_COMPILE/path/to/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-然后开始编译make ARCHarm64 rockchip_linux_defconfig make ARCHarm64 rk3568_custom_defconfig make ARCHarm64 -j$(nproc) Image dtbs这里说明一下Image是未经压缩的内核镜像一般用于网络启动tftp或者后续打 boot.img 用如果你想要压缩格式的zImage在 arm64 上其实默认不再生成 zImage而是直接使用 Image然后通过打包工具压缩到 boot 镜像里。所以arm64 平台下主产物是 Image而不是 zImage这一点和 arm32 内核习惯不同。-j$(nproc)表示用满所有 CPU 核如果你的机器是 8 核 16 线程就是-j16。但遇到编译 OOM 时可以降级到-j4因为内核编译是内存密集型任务线程开太多如果内存不够反而更慢。4.2 构建 boot.img 并分析镜像内容瑞芯微官方推荐用make image或者通过顶层 build.sh 来生成 boot.img但这里我更推荐手动走一遍搞清楚每步干什么。一种方式是直接使用内核源码根目录下的make rockchip_boot_img前提是你已经配置了ROCKCHIP_BOOT_IMG环境变量指定输出路径export ROCKCHIP_BOOT_IMG../rockdev/boot.img make ARCHarm64 rockchip_boot_img这种方式会把 Image、dtb、ramdisk 打包成 boot.img。另一种方式是先手动把boot.img解包看看里面有什么mkimage -l boot.imgmkimage是 U-Boot 的工具也可以用来解析 ramdisk 和 boot.img 结构。通过这个命令可以清楚看到 boot.img 中包含的 Image 和 dtb 信息。理解这部分对排查启动失败非常有帮助因为很多情况下启动不了就是 dtb 在 boot.img 内与内核不匹配。4.3 常见编译错误与解决办法编译过程中最容易踩的坑我直接整理成快速排查表错误现象大概率原因解决办法fatal error: linux/compiler-gcc7.h: No such file or directory工具链版本太老或头文件不完整更换为 SDK 自带的 linaro 6.3.1 工具链Error: unknown pseudo-op: .arch_extension汇编器版本过旧不支持某些指令扩展升级 binutils 或用官方工具链undefined reference to ...内核配置裁剪过度某些依赖符号被关闭重新开启相关配置项或者恢复 defconfig 后再增量修改Kconfig: not found没有安装 ncurses 相关库执行sudo apt-get install libncurses-devmultiple definition of ...某些模块重复编译进内核清理编译产物make clean后重新编译Makefile: ... CONFIG_CC_VERSION_TEXT相关错误工具链和内核版本兼容性问题优先用 4.19 配套工具链避免高版本 GCC还有一个非常隐蔽的坑编译内核时使用了ccache缓存如果之前缓存了错误版本的编译产物即使你换了对的工具链编译报错依然会复现。遇到这种玄学问题建议先清掉 ccache 缓存ccache -C然后再重新编译。多次经验证明很多“明明没改任何代码但开始报错”的情况都是 ccache 在捣乱。4.4 模块编译与安装到根文件系统如果你开启了某些驱动为模块m还需要单独编译模块make ARCHarm64 modules -j$(nproc) make ARCHarm64 modules_install INSTALL_MOD_PATH/path/to/rootfs我建议场景允许的情况下关键驱动尽量直接编译进内核而不是用模块。原因有几个一是模块需要维护依赖关系内核升级后模块不匹配就会加载失败二是工业设备需要减少文件系统上的组件降低被误操作破坏的风险三是模块加载过程本身有额外开销对强实时性应用不友好。如果非要做成模块要注意depmod务必在安装模块后执行否则模块之间的依赖关系不会自动生成modprobe 时会报module not found。命令depmod -b /path/to/rootfs4.5 单独编译 dtb 并检查设备树合法性设备树编译是和内核编译分开进行的。先把 .dts 编译成 .dtbmake ARCHarm64 dtbs产物在arch/arm64/boot/dts/rockchip/目录下。我用到的具体文件是rk3568-evb1-ddr4-v10.dtb或者自定义板型的 .dtb。检查 dtb 是否合法可以用 fdtdump 或者 dtc 反编译fdtdump rk3568-evb1-ddr4-v10.dtb | less # 或者 dtc -I dtb -O dts rk3568-evb1-ddr4-v10.dtb -o decompiled.dts反编译后检查关键节点是否存在、地址是否正确。比如内存节点memory...、串口节点serialfe660000、网卡节点gmac0等。很多时候启动日志显示没有控制台输出就是因为串口设备树节点与内核配置不匹配。5. 设备树优化的实战细节从看懂 dts 到改对 dts5.1 设备树基本结构和 RK3568 特有节点设备树Device Tree对于从单片机转过来的开发者来说一开始很容易把它当成“高级配置文件”其实更准确地说它是硬件描述语言告诉内核“你的板子上有什么、分别接在哪个地址、电平怎么需求的”。RK3568 的 .dtsi 文件里有几个核心节点必须熟悉cpusCPU 核心信息A55 的四颗核心都是在这里描述。gmac0和gmac1双千兆网口通常在rk3568.dtsi中定义在板级 .dts 中通过gmac0追加描述 PHY、时钟、复位引脚等信息。i2c0~i2c5I2C 控制器触摸屏、摄像头、传感器大多挂在 I2C 上。spi0~spi3SPI 控制器接 SPI Flash、ADC、显示面板等。pinctrl引脚复用配置这是新手最容易懵的地方。一个 GPIO 可能同时被复用为 UART、I2C 或 PWM必须让 pinctrl 和实际外设匹配否则设备无法工作。以 RK3568 的串口为例在板级 .dts 中通常这样配置uart0 { status okay; pinctrl-names default; pinctrl-0 uart0_xfer; };这里的uart0_xfer是在rk3568-pinctrl.dtsi中定义的引脚复用组。如果你把uart0改成别的功能却忘了改 pinctrl就会出现引脚冲突这个需要非常小心。5.2 自定义底板设备树的推荐写法基于现有 dts 修改还是新建 dts瑞芯微官方 SDK 的板级 dts 文件名通常是rk3568-evb1-ddr4-v10.dts这类格式。如果自己画了底板最简单的方式是基于官方 EVB 的 dts 复制一份然后改差异部分。推荐做法cp arch/arm64/boot/dts/rockchip/rk3568-evb1-ddr4-v10.dts arch/arm64/boot/dts/rockchip/rk3568-myboard.dts然后在arch/arm64/boot/dts/rockchip/Makefile里添加该 dts 的编译目标dtb-$(CONFIG_ARCH_ROCKCHIP) rk3568-myboard.dtb接着修改 dts 里的内容。这里有个容易踩的坑不要只看最后一行 include 了哪个 .dtsi要搞清楚整棵设备树从哪里来的。RK3568 设备树有多层 include 嵌套比如#include rk3568.dtsi #include rk3568-evb.dtsi #include rk3568-linux.dtsi如果你改动了一个节点但不知道它是在rk3568-evb.dtsi里定义的可能改了板级 dts 里的值却被一层层的覆盖规则给吞掉了。建议改动之前先用 cpp 手动预处理器展开整个 dtscpp -nostdinc -I include -I arch/arm64/boot/dts -undef -D__DTS__ -x assembler-with-cpp arch/arm64/boot/dts/rockchip/rk3568-myboard.dts preprocessed.dts这样可以把所有 include 头文件展开出来方便确认节点最后生效的定义在哪层。我在实际调试中用过不少次排查节点值是否被覆盖这个办法真正能救命。5.3 常见外设的设备树配置要点LCD、TP、PHY、摄像头设备树改动的常见场景我挑几个高频外设讲LCD 屏幕MIPI DSI / LVDS / RGB对于 MIPI DSI 屏要重点关注panel节点中的 timing 参数hactive、vactive、clock-frequency、hback-porch、htotal等这些参数需要严格对照屏幕规格书。参数错了屏幕现象可能是闪屏、偏移、花屏甚至直接没有背光输出。调试时可以先用命令手动测试cat /sys/class/drm/card0-DSI-1/modes或者切换不同分辨率模式来验证内核是否识别到面板。触摸屏I2C 接口触摸屏设备树的核心是 I2C 节点、中断 GPIO 和复位 GPIO。比如i2c1 { status okay; gt911: touchscreen5d { compatible goodix,gt911; reg 0x5d; interrupt-parent gpio0; interrupts RK_PB5 IRQ_TYPE_LEVEL_LOW; reset-gpios gpio0 RK_PB4 GPIO_ACTIVE_LOW; touchscreen-inverted-x 1; touchscreen-inverted-y 1; status okay; }; };这里interrupt-parent和interrupts要特别注意如果你把触摸屏中断引脚接到了gpio0的B5而实际硬件不是这个引脚触摸就会完全没反应甚至上报错误中断风暴。以太网 PHY我这次用的 PHY 是裕太微的 YT8531跟瑞芯微 GMAC 匹配需要配置gmac1 { status okay; phy-mode rgmii; clock_in_out input; snps,reset-gpio gpio0 RK_PB6 GPIO_ACTIVE_LOW; snps,reset-active-low; snps,reset-delays-us 0 10000 50000; pinctrl-names default; pinctrl-0 gmac1_miim gmac1_rgmii_clk gmac1_rgmii_bus; phy-handle phy0; phy0: ethernet-phy0 { compatible ethernet-phy-ieee802.15-c22; reg 0x0; /* 如果 PHY 有特殊寄存器的初始化也可以加入 mdio 节点 */ }; };关键点是phy-mode必须是rgmii或rgmii-id根据 PHY 驱动要求phy-handle要指向一个 mdio 子节点且子节点的reg要与 PHY 芯片的 MDIO 地址一致。很多网卡不通排查半天最后发现就是 MDIO 地址错了。摄像头MIPI CSI / OV5695 / OV8858摄像头设备树比触摸屏更复杂需要配 I2C 地址、MIPI 通道、时钟频率、上下电时序等。以 OV5695 为例通常要在 sensor 设备节点里指定ov5695: ov569536 { compatible ovti,ov5695; reg 0x36; clocks cru CLK_MIPICAM_OUT; clock-names xvclk; pinctrl-names rockchip,camera_default; pinctrl-0 mipicsi_clk0; power-supply-regulator avdd; ... };摄像头调试的难点在于时序尤其是 reset 和 powerdown 引脚的时序顺序。如果上电时序不对sensor 大概率 I2C 读取不到 ID或者读到错误 ID。5.4 1600万像素级联用屏幕旋转实例理解设备树覆盖机制让我用最近群里经常有人问的“触摸竖屏改为横屏”来示例设备树的覆盖逻辑。正常情况下屏幕物理安装方向是横屏但为了 UI 友好软件层希望设备树默认报告横屏分辨率。这时候有两种做法在 DRM 面板驱动的display-timings中直接调整 active 宽高。在设备树中加rotation 90属性让内核知道 panel 应该旋转显示。rotation属性属于 DRM 通用属性具体写法是panel { rotation 90; };但这个写法在不同内核版本上行为有差异4.19 版本上对 panel 节点的 rotation 支持并不完美更可靠的做法是修改驱动层的drm_panel结构或者在用户空间用 libinput 配置旋转。从设备树角度最核心的就是理解status okay、status disabled这个开关机制。很多外设不工作就是因为某个父节点没开启而子节点开启了也没用。设备树覆盖机制的本质是子节点覆盖父节点的属性而不是叠加属性。所以当你发现某个属性的修改不生效注意去看看它的父节点是不是也加载了这个属性。5.5 设备树和内核配置的配合常见启动失败与排查设备树的问题很多时候是编译过了、系统也起来了但某个外设就是没反应。这时排查思路建议如下先看启动日志里有没有相关报错dmesg | grep -i i2c\|gpio\|phy\|panel。再看设备树是否被正确加载ls /proc/device-tree/可以查看当前运行内核实际使用的设备树节点。查看 GPIO 是否被正确占用cat /sys/kernel/debug/gpio确认引脚复用和方向是否正确。如果是 I2C 设备用i2cdetect -y bus号扫描地址确认设备有没有上电且地址正确。我有一个习惯每次编译完 dtb先在自己电脑上反编译一遍确认改动真的进了最终输出的 dtb再烧录到板子上。因为有过太多次“改了 dts 但没编译进去”的低级失误白烧了几十次。6. 常见坑位与调试技巧把 RK3568 从“起不来”调到“稳如老狗”6.1 boot 阶段无串口输出如何快速定位RK3568 的启动流程大致分为BootROM - U-Boot SPL - U-Boot - 内核。如果你上电后串口完全没有输出最可能的原因有这么几个串口调试工具的波特率不对。RK3568 的 debug 串口默认通常是 15000001.5M不是常见的 115200。我第一次调试时就用 115200 看一片空白差点以为板子坏了。U-Boot 中配置的 debug uart 引脚与你的底板不符。比如官方 EVB 用的是 uart2而你的底板把 debug 串口接到了 uart0那 U-Boot 阶段会没有输出只有内核起来后才有可能打印如果内核配置了正确的 console。电源不稳导致 BootROM 反复重启。这种情况可以测一下核心板各路电源是否正常特别是 VDD_CPU、VDD_LOGIC 这些。6.2 内核启动到一半卡死的排查思路如果串口有 U-Boot 输出但加载内核后打印到某一行就停住这种情况大致有两类原因第一类是内核崩溃但 console 还没来得及输出。可以在 U-Boot 中传递earlycon参数比如setenv bootargs consolettyS2,1500000n8 earlyconuart8250,mmio32,0xfe660000 saveenv boot这样内核早期调试信息会从最开头打印出来方便定位卡死位置。第二类是 dtb 和内核不匹配某些节点解析失败导致 panic。这时可以尝试用 U-Boot 的booti命令手动加载 Image 和 dtb而不经过 boot.img 打包层从而缩小问题范围load mmc 0:1 0x2000000 Image load mmc 0:1 0x3000000 rk3568-myboard.dtb booti 0x2000000 - 0x30000006.3 设备树改动后不生效的隐蔽原因除了前面提到的 include 层级覆盖问题还有一个很容易忽略的编译 dtb 时用的 .dtsi 可能被缓存了。瑞芯微的 SDK 里dtb 编译会依赖多个 .dtsi 文件如果你改了某个 .dtsi却只编译单个 dtb某些构建系统会因为时间戳判断没有重新生成。稳妥的做法是find arch/arm64/boot/dts/rockchip/ -name *.dtb -delete make ARCHarm64 dtbs强制重新编译所有 dtb。包括 .dtbo设备树叠加层文件也是如此。若你用了 overlaid dtbo还要注意fdtoverlay的加载顺序建议直接咨询参考代码里的 dto 加载机制。6.4 内核配置与性能调优的一点点经验最后说一下配置层面影响性能的几个点内核 HZ 值4.19 默认 HZ 通常是 100 或 250实时任务建议确认 HZ 配置与实时抢占选项是否匹配但不要盲目开高 HZ因为会增加内核调度开销。CPU 调频策略RK3568 默认支持 cpufreqdevice tree 中opp表如果没配对CPU 频率会锁在低档。查看当前频率cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq如果频率不变化检查 OPP 表是否与芯片型号匹配。DMA 一致性如果你的外设 DMA 分配有问题多半是 dtb 中dma-coherent属性配错了。这个属性不能随便加必须参考内核文档和硬件是否支持。7. 最终烧录与验证确保镜像真的能跑起来7.1 烧录工具选择和分区说明RK3568 支持多种烧录方式USB 线刷Loader 模式、SD 卡启动、EMMC 烧录、网络启动等。我这次主要用的是瑞芯微官方工具RKDevTool在 Linux 上也可以用upgrade_tool烧录。烧录前先确认分区表。RK3568 SDK 里的分区表在device/rockchip/rk3568/parameter.txt里定义常用分区包括uboot分区存放 U-Boot 二进制。misc分区存放启动模式标志。boot分区存放 boot.img包含 Image 和 dtb。rootfs分区存放根文件系统镜像。如果你只是单独编译了内核不需要整个系统重新烧可以只烧 boot 分区upgrade_tool db loader.bin upgrade_tool di -b boot.img这种方式比整包烧写快很多也方便调试。7.2 启动验证清单烧录完成后建议按以下顺序验证系统是否正常串口输出是否有内核打印最后是否能进入 login 终端。uname -a确认内核版本号是否正确。cat /proc/device-tree/model确认设备树与硬件模型是否匹配。检查网络是否通ip link、ping。检查显示是否正常HDMI 输出、LCD 背光和画面。检查关键外设触摸、网口、串口、摄像头等。每一项都通过才算这一轮内核和设备树调试完成。7.3 长期维护视角配置管理和版本标识内核和设备树不是一次性工作产品生命周期内必然要改 bug、加功能。建议在一开始就把版本管理做好内核源码用 git 管理每次改动前打 tag 或者 commit。设备树文件与内核代码一起提交避免“同一套内核配了四五份 dtb 却不知道哪份对应哪个硬件版本”的尴尬局面。在 dts 的注释里写明硬件版本信息例如/* HW-V1.2: 修改 LCD reset 引脚从 GPIO4_C0 改为 GPIO4_C2 */这种注释对后来接手的人太友好了。我还习惯把最终的.config也提交到仓库里并配套一份README记录编译命令。这个东西看起来不起眼但过了半年你再回头编译时能省下大把时间。8. 小结与一点个人体会写到这里整个 RK3568 手动构建 Linux 4.19 内核镜像与设备树优化的主流程都过了一遍。从环境准备、内核配置、镜像编译、设备树编写到烧录验证和问题排查每个环节都有一些看似很小但非常影响效率的坑。我个人在实际调试中最深刻的体会有三点。第一不要跳过 boot.img 的分析环节。很多人只会一条命令打包出了问题完全没思路。把 boot.img 解包、确认内核和 dtb 是否正确写入往往能在一分钟内定位到“烧了旧镜像”这类低级问题。第二设备树改动务必养成 diff 的习惯。内核是通用工程设备树才是真正绑定你硬件的部分。设备树改错了轻则外设不工作重则内核 panic而且错误信息常常不明显。有意识地用dtc反编译和 git diff 来审查改动能让你少烧很多次板子。第三不要迷信裁剪配置能带来多大性能提升。对 RK3568 这种四核 A55 的平台大多数应用的性能瓶颈不在内核大小而在驱动效率和业务逻辑。把内核裁到很小功能全没了是得不偿失的。真正需要关注的是实时性配置、DMA 效率、中断处理这些与业务相关的点。最后再分享一个小技巧调试阶段把 console 的 loglevel 调高一些加上ignore_loglevel启动参数可以避免漏掉早期关键报错信息。等到产品定型之后再把 verbose 关掉既方便调试又不影响最终体验。希望对正在折腾 RK3568 的朋友们有帮助。如果有类似经验或更好的思路欢迎评论区一起交流。
