手上这块 RK3568 核心板出厂预装的系统是 Buildroot。刚拿到手的时候我还挺满意启动快、镜像小、没有一堆用不上的服务堪称所见即所得。可等我真的把它当成一台日常 Linux 用起来憋屈感就上来了——想装个 pip 包麻烦想跑 Node 服务更麻烦想让 Docker 跑起来几乎做梦。忍了两周我决定刷机把 Buildroot 换成 Debian。刷机本身不算难难的是一路踩出来的深坑。其中最有代表性的就是那个一度把我搞到崩溃的“重启手配 IP”问题每次 reboot 之后网络接口要么没有地址要么地址和上次不一样必须重新手动配一次 IP 才能连上。这篇文章就完整走一遍怎么从 Buildroot 刷到 Debian以及怎么根治这个“重启手配 IP”的顽疾。1. 为什么我决定把 Buildroot 换成 Debian1.1 Buildroot 没错只是它在等一个不适合它的场景先说清楚一点Buildroot 不是一个发行版而是一套“构建嵌入式系统”的方法论。你通过 menuconfig 配置内核、库和应用最后 make 出一整个带 rootfs 的固件镜像。它的核心哲学是静态裁剪为了体积小、启动快把不需要的东西全部剪掉。这种思路对量产设备非常友好镜像稳定、维护简单、开发者不会因为“多装一个软件”破坏现场环境。但它的代价也在这里rootfs 里没有真正的包管理能力。所谓“没有 apt”不只是少一条命令而是你整个软件交付模式回到了石器时代。我想要 python3-pip得重新配置 Buildroot 包选项然后整体 make我想要 Node.js 跑个服务npm 依赖链一展开几十个包全部手动管理我甚至想装个 sqlite3 边缘工具都要重新编译一份交叉编译工具链。对于做产品的人这可能无所谓但对我来说这块板子是拿来开发调试、跑应用的不是在产线上重复烧录的。Buildroot 再香也扛不住“软件变更频率高”的场景。真正压垮我的最后一根稻草是 Docker。Buildroot 里跑 Docker 不是不行但要凑齐一堆容器运行时的依赖比我从零刷一个 Debian 还要费时间。既然 RK3568 本身是一颗正经的 ARM64 四核处理器内存普遍配 2GB 到 8GB给它一个完整、有生态的 Debian 才是合理的归宿。1.2 我的真实需求清单在决定刷 Debian 之前我把自己接下来的需求列了个清单逐条对比 Buildroot 和 Debian 的满足成本需求Buildroot 的满足成本Debian 的满足成本Python 推理服务 pip 安装依赖需自定义 package反复 makeapt install python3-pip即可Node.js / npm 项目依赖链管理极痛苦apt install nodejs npmDocker / Compose要手动凑运行时依赖apt install docker.io docker-compose-pluginNAS / 存储服务需要手动移植源码编译apt 直接装 samba、zfsutils 等外接摄像头调试MIPI-CSI设备树还是要自己调工具少devicetree 调试工具齐全配合 v4l2 工具链方便得多对比完基本上没悬念。Buildroot 适合单功能、存储小、启动要求高的量产设备Debian 适合让我这种“什么都想装一装”的开发者快速做验证和交付。要注意的是Debian 官网并不直接发布 RK3568 的官方镜像它只是提供 rootfs 和软件仓库板级适配仍然要自己搞定 U-Boot、内核和设备树。这正是刷机这件事真正的门槛所在。1.3 顺手说下 RK3568 和 RK3566 的选型差异相关热搜词里一直有“rk3568、rk3568 3566区别”这里也提一嘴防止有人买错板子。RK3568 和 RK3566 的 CPU 核心、NPU 算力基本一致都是四核 Cortex-A55 0.8TOPS 的 NPU真正的差异在接口丰富度上。RK3568 支持 PCIe3.0、SATA3.0、双千兆 GMAC、USB3.0 OTG扩展性明显更强RK3566 主打低成本便携接口更少通常不带 SATA/PCIe 或者只保留部分适合平板、机顶盒、低成本边缘盒子这类场景。如果你和我一样想做一台带 NVMe、多网口的小服务器直接盯住 RK3568。如果只是做一个低成本的显示终端或者轻量采集盒子RK3566 也够用。两者的刷机路径基本一致都是 Maskrom 模式 RK 工具烧录但内核设备树、电源设计不同不能混用固件。这也是很多新手刷机失败的原因之一——拿了 3566 的板子硬刷 3568 镜像自然起不来。2. 准备阶段不要直接开刷先想清楚三件事2.1 弄清楚三种模式Maskrom / Loader / 正常启动刷 RK 平台的芯片第一个要弄明白的就是模式。RK3568 有几种运行状态其中和我们刷机相关的有三种Maskrom 模式芯片内置 ROM 引导eMMC 是空盘或者已经损坏也能进入。此时芯片不加载任何外部固件只通过 USB 等待主机下发命令。这是刷机最安全的入口。Loader 模式U-Boot 正常跑起来之后进入的升级模式也叫 RockUSB 模式。系统正常时执行reboot loader可以进入或者上电前按住 Loader 按键。普通启动模式正常加载 U-Boot → 内核 → rootfs不参与刷机。进 Maskrom 的常见方法是短接 eMMC 的 CLK 引脚到 GND或者按住板子上的 Maskrom 按钮同时上电。不同板子按键位置不同我建议看自己板子原理图不要凭感觉短接万一把电源引脚短了就是真烧板子。进对模式之后USB 连接电脑工具里会识别到一颗“Rockchip Device”或“Loader Device”识别不到就检查驱动和 USB 线。2.2 固件从哪来自己编译还是直接用现成镜像刷机不能空手刷先准备好固件。RK3568 的 Debian 固件通常由这几部分组成U-Bootloader/bootloader、内核 设备树boot.img 或 dtb 分区、rootfsrootfs.img以及一个描述分区布局的 parameter.txt。固件来源我给三个路线按省事程度排序Armbian 现成镜像社区维护非常活跃对 RK3568/RK3566 的支持很成熟内核通常用 mainline 6.x设备树覆盖大量开发板。适合不想折腾底层、拿回来就想跑的人。缺点是如果你想深度定制 U-Boot 和内核还是要自己重新编译。厂家 SDK 提供的 Debian 镜像很多 RK3568 方案商或开发板厂商会直接发 Debian 镜像驱动和适配最全省去一大部分调板子的时间。但要注意厂家镜像的 Debian 版本可能偏旧仓库里的包管理方式也未必标准。自建 rootfs用 debootstrap 生成一份 Debian rootfs再用自己编译的 U-Boot 内核 设备树组合。灵活性最高但坑最多。我这次走的是第三条路线用 SDK 的 U-Boot内核自己编译 mainline 6.1 LTSrootfs 用 debootstrap 生成 bookworm。这套组合的好处是软件版本可控出问题时我至少知道每一层是谁。如果你不想第一天就陷进交叉编译建议先用 Armbian 把板子跑起来再逐步换掉其中某个组件这样更稳。2.3 备份与供电刷机失败最常见的原因刷机前有两件事被严重低估备份原厂固件和供电质量。备份这件事不要偷懒。在原来的 Buildroot 系统还活着的时候先把整个 eMMC 备份出来。方法很简单dd if/dev/mmcblk0 of/backup/emmc_backup.img bs4M convsync,noerror这个命令会把整块 eMMC 原样 dump 出来包含原有分区表、U-Boot、内核和 rootfs。我因为是开发板eMMC 只有 16GB备份两个多小时完成。备份文件放到 U 盘或者通过网络传到电脑上万一后面刷挂了能用dd写回去救砖。如果你不想整盘备份也可以只备份根分区和 boot 分区但整盘备份最保险。供电问题真的会杀人。RK3568 板子普遍需要 12V 或 5V 电源如果你为了省事直接用一个 USB 口给板子供电同时用另一个 USB 口做刷机数据线烧录到一半电流不足工具直接报错断开轻则刷一半重则把 eMMC 分区表写到一半损坏。我亲眼见过群友因为 USB Hub 供电不足刷机中断后板子直接变砖最后只能拆 flash 用编程器救。所以请务必用原装电源供电单独数据线接电脑并且尽量别把刷机 USB 插在机箱前面板。3. 刷机实操由 Buildroot 换成 Debian3.1 进入 Maskrom 与安装工具我用的板子有 Maskrom 按键操作是断电、按住 Maskrom 键、上电、松开然后 USB 线连接电脑。Linux 下我用的工具是upgrade_tool瑞芯微官方 Linux 刷机工具和它的老版本兄弟rkdeveloptool。安装依赖后编译或直接下载预编译版本然后先看能不能识别设备sudo upgrade_tool d如果输出类似Found USB 3.0 device: 001说明设备已经识别到了。识别不到时先检查 USB 线再检查设备权限可以试试sudo chmod 666 /dev/bus/usb/$(lsusb | grep Rockchip | awk {print $2})/$(lsusb | grep Rockchip | awk {print $4} | tr -d :)Windows 用户用 RKDevTool 更方便但有一个坑Win8 以上系统装瑞芯微驱动时经常撞上驱动签名必须重启进入“禁用驱动签名强制”模式再装。这个不处理好工具会一直提示没有发现设备十有八九都是驱动安全问题。3.2 分步烧录要点进入 Maskrom 之后刷机顺序非常关键。第一步永远是下载 Loader让设备从 Maskrom 切换到 Loader 模式否则后面写分区是不可用的。sudo upgrade_tool db Loader.binLoader 下载成功后再执行全量烧写。如果你手里是官方整包 update.img直接sudo upgrade_tool UL update.img这个命令会按照 update.img 里的 parameter.txt 把 U-Boot、dtb、boot、rootfs 等分区一次性写完。个人经验能用全量包一次写完就不要手贱一个分区一个分区写少出问题。如果你要自己定制分区大小比如把 rootfs 从默认 2GB 扩到 8GB就需要先修改 parameter.txt 中的 partition 定义再分别烧写各分区。RK 平台的分区概念和 PC 上不太一样它不依赖 GPT 而是用 parameter 文件描述大小和起始位置。改分区表之前想清楚改完后面还要重新格式化 rootfs 并写入镜像。烧写完成后不要立刻高兴先拔掉刷机 USB 线用串口线连接板子的调试串口一般波特率 1500000少部分板子是 115200再上电观察启动日志。为什么一定要接串口因为很多问题屏幕不显示、网络不通只有串口里能看到 U-Boot 到内核的完整日志。没接串口等于瞎猜。3.3 第一次启动与验证正常进系统后第一件事不是急着配软件而是验证基础项uname -a cat /etc/os-release lsblk ip -br link如果lsblk能看到 mmcblk0 的多个分区说明 eMMC 布局符合预期ip -br link能看到网卡接口名称可能是 eth0也可能是 enP2p1s0 这类可预测命名说明设备树里 GMAC 节点已经被内核识别。第一登录默认 root 无密码立刻passwd改掉再用hostnamectl set-hostname改主机名。这些小事做在前面后面少折腾。然而等我把这些验证完一个诡异的问题很快浮现第一次启动网络是通的重启之后就完全没 IP 了。这就进入了本文的重头戏。4. “重启手配 IP”从偶发现象到根因的完整排查4.1 现象记录重启必丢 IP手动配号就好第一次进 Debian 时网络其实好得很我甚至顺手apt update更新了几百 MB 包。然后我 reboot噩梦开始。重启之后ip -br a输出只有 loeth0 上干干净净没有任何地址。手动执行ip addr add 192.168.1.100/24 dev eth0 ip link set eth0 up网络立刻通了能 ping 网关能 ssh。这说明硬件没坏、线缆没问题、网卡驱动也已经加载问题出在“启动阶段没有自动完成网络配置”这一层。我当时第一反应是哦rootfs 里没装 NetworkManager那 20 分钟就能装好解决。事实证明我太天真。4.2 刚开始的误判以为是缺 NetworkManager用 debootstrap 生成的 rootfs 默认不会安装 NetworkManager、ifupdown、wpa_supplicant 这些网络管理组件这一点我很清楚。所以我先启动 systemd-networkd准备用 systemd 自己的网络管理来接管systemctl enable --now systemd-networkd重启再ip -br a还是空的。这时候我开始觉得不对。systemd-networkd 只是没有收到配置不是没有启用所以我开始怀疑接口名。4.3 继续挖接口名压根不叫 eth0跑一下ls /sys/class/net发现接口叫enP2p1s0不是 eth0。这是 systemd 的可预测命名规则根据 PCI 总线位置生成名字。问题来了我配置 networkd 时写的 Match 条件是Nameeth0但它实际叫enP2p1s0Match 不上自然也就不会执行 DHCP。这一步算是有进展我把 networkd 的 Match 改成NameenP2p1s0再写了一份 udev 规则把接口固定成 eth0SUBSYSTEMnet, ACTIONadd, ATTR{address}xx:xx:xx:xx:xx:xx, NAMEeth0重启之后接口名确实稳定成了 eth0但 IP 还是不来。此时我有点上头了——配置已经对了为什么还是不行于是决定不再猜直接看内核日志。4.4 转折点dmesg 里的 PHY attach 失败每次重启后我都先抓日志dmesg | grep -iE gmac|stmmac|phy终于看到关键信息could not attach PHY、stmmac: no PHY found。这行字的意思是GMAC 驱动虽然探测到了但没能成功连接板载 PHY 芯片。再跑ethtool eth0显示Link detected: no。物理链路根本没起来那就算 DHCP 请求发出去也收不到回应网络自然不通。为什么会 attach 不上 PHY查板子原理图发现这颗 PHY 是千兆芯片而 SDK 默认设备树里写的phy-mode rgmii但实际走线对 RGMII 的 TX/RX delay 处理方式要求的是rgmii-id。从根本上说MAC 侧和 PHY 侧对延迟处理的理解不一致导致 PHY 协商失败链路永远起不来。这个问题改设备树就能解决但我当时还没意识到这只是第一层坑。改完 DTB 之后ethtool eth0显示Link detected: yes链路正常了但新的问题马上浮现——DHCP 依然拿不到 IP而且 MAC 地址每次重启都不一样。4.5 隐藏最深的坑MAC 地址每次重启都在漂移每次重启后我都会看一眼ip a微信上陆续记录了四五组 MAC 地址没有一组是相同的。这一步让我意识到大事不好板子的 U-Boot 里没有烧录固定以太网 MAC 地址U-Boot 每次启动都会随机生成一个 MAC然后通过设备树传给 Linux。DHCP 的工作原理是“按 MAC 分配租约”MAC 一变路由器里为旧 MAC 保留的 IP 就全部作废新 MAC 重新发起 DHCP 请求租约池里又可能给你分一个完全不同的 IP。这就是为什么我手动 配好 IP 能上网、一重启又全没了——因为整个链路层身份都在漂。你可能会问那我手动静态配置本地 IP不依赖 DHCP不就行了确实可以但静态配的 192.168.1.x 和路由器网关、DNS、掩码必须手写全而且多台设备一多就冲突。更重要的是如果 MAC 不稳定路由器上做 DHCP 静态绑定、防火墙按 MAC 限速这些全部失效。所以 MAC 漂移这个问题必须治。4.6 排查结论不是单一原因而是四层叠加回头看这个“重启手配 IP”根本不是某一个 bug而是四个问题叠加后的综合症状网络管理服务缺失/未启用启动阶段没人跑 DHCP接口名因可预测命名规则变化配置文件 Match 不上设备树 phy-mode 配置和实际 PHY 不匹配物理链路起不来MAC 地址每次重启都不同DHCP 租约和绑定全部失效。只修其中任何一条问题都不会好。我之前“改了系统配置但没用”的原因就在这里你修对了 A但 B 和 C 还烂在原地系统依然表现出“没网”的状态。所以遇到这种综合性问题不要期望一行配置能解决必须一层一层查按链路 → 驱动 → 接口 → 地址的顺序排查。5. 根治方案让网络在启动阶段自己长出来5.1 先固定 MAC把身份定下来第一步也是最重要的一步是在 U-Boot 里设置固定 MAC。我的板子在 U-Boot 控制台里直接执行setenv ethaddr 00:11:22:33:44:55 saveenv这里要注意两点MAC 地址不要用全 0也不要用多播地址最好在多个板子之间规划一个“网卡 MAC 段”避免两台板子撞 MAC 造成 DHCP 混乱。设置好之后重启确认ip link里 MAC 已经固定。有些 SDK 会从 eMMC 特定分区读取 MAC 并在启动脚本里覆盖ethaddr如果设置不生效就要去查 U-Boot 启动环境变量里的bootcmd或者平台相关脚本。U-Boot 层固定是最彻底的办法比 Linux 里用 systemd service 去改 MAC 干净得多。5.2 固定接口名让 eth0 永远叫 eth0MAC 固定之后接口名也要固定。如果你不在乎叫什么直接把 networkd 的[Match]改成实际接口名也可以但对后续维护来说固定的 eth0 更直观、更好写脚本。两种方式任选udev 规则方式写在/etc/udev/rules.d/70-net-name.rulesSUBSYSTEMnet, ACTIONadd, ATTR{address}00:11:22:33:44:55, NAMEeth0或者 systemd link 方式写在/etc/systemd/network/10-eth0.link[Match] MACAddress00:11:22:33:44:55 [Link] Nameeth0实测两种都能生效。不要两套规则同时写否则可能会出现规则竞争导致接口名时对时错。改完之后udevadm test /sys/class/net/*或者直接重启验证。5.3 选一个网络管家并且只留一个网络管理服务是最容易踩“多个管家抢网口”坑的地方。我的建议有有线场景选 systemd-networkd有 WiFi 场景选 NetworkManager传统习惯可以选 ifupdown但无论如何只启一个。三者对比如下方案优点缺点适用场景systemd-networkd轻量、无依赖、配置简单Debian 默认自带管理 WiFi 麻烦基本要配合 wpa_supplicant纯有线、服务器、嵌入式NetworkManagerWiFi 管理强、有 nmcli/图形界面方便切换依赖多在无桌面环境显得重开发板当桌面/移动设备用ifupdown老派但稳定/etc/network/interfaces 一次配好缺乏动态管理能力切换网络不便固定配置的工业设备我最后选了 systemd-networkd。配置文件写成# /etc/systemd/network/10-eth0.network [Match] Nameeth0 [Network] DHCPyes # 如果要用静态 IP注释掉 DHCP改成下面三行 # Address192.168.1.100/24 # Gateway192.168.1.1 # DNS223.5.5.5然后启用systemctl enable --now systemd-networkd如果你选 NetworkManager则apt install network-manager systemctl enable --now NetworkManager nmcli device set eth0 managed yes这里特意要强调绝对不要同时开着 systemd-networkd 和 NetworkManager两个服务会抢网口甚至出现“NM 把网口 unmangednetworkd 又接管不了”的死循环。我排错时遇到过一次整整多花一个小时。5.4 修正设备树里的 PHY 配置如果你和我一样遇到Link detected: no那就要动设备树了。RK3568 的 GMAC 节点一般在设备树里叫gmac0、gmac1配置要点是status、phy-mode、phy-handle和 PHY 子节点的reg地址。我的板子需要把phy-mode从rgmii改成rgmii-idgmac0 { status okay; phy-mode rgmii-id; phy-handle phy0; }; mdio0 { phy0: ethernet-phy0 { reg 0; compatible ethernet-phy-idXXXX; }; };reg 0必须和板载 PHY 的 MDIO 地址一致这个地址查板子原理图不会猜。phy-mode的四种常见值rgmii、rgmii-id、rgmii-txid、rgmii-rxid分别对应是否在 MAC 或 PHY 侧加入 delay具体选哪个要看走线长度和 PHY 芯片手册。改好设备树后重新编译 DTB烧到dtb分区或者直接替换 boot.img 里的 resource.img。如果用的是设备树 overlay修改起来更方便不用反复烧整个 boot 分区。5.5 十连重启验证配置全部就位后不能只重启一次就宣布成功我写了一个暴力验证脚本放在 root 目录连续重启十次每次重启后检查 IP 和网关#!/bin/bash for i in $(seq 1 10); do echo ---- reboot test $i ---- sleep 15 ip -br a ping -c 1 -W 2 192.168.1.1 || echo ping failed systemctl reboot done注意这个脚本每次重启后不会自动继续需要你手动登录后重新执行否则它只跑一轮就结束了。我实际上每次登录都手动跑一次脚本记录十次重启的结果八次在开机 30 秒内拿到 DHCP 地址最慢的两次等了大约 5 秒DHCP 超时重传导致没有任何一次需要手动配 IP。这时候才敢说“重启手配 IP”这个问题真正根治了而不是碰巧生效。6. 换到 Debian 之后我额外处理的三件事6.1 更新源与 apt 提速rootfs 默认的/etc/apt/sources.list指向官方国际源在国内下载速度非常感人。我把源切换到了清华或者阿里镜像。以 bookwormDebian 12为例cat /etc/apt/sources.list EOF deb http://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm main contrib non-free non-free-firmware deb-src http://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm main contrib non-free non-free-firmware EOF如果你是 Debian 13trixie把 bookworm 全部替换成 trixie 即可。然后执行apt update apt full-upgrade顺手把系统升到最新。这里提醒一点不要贪心同时加多个镜像源不同源的同步进度不一样混着写很容易产生依赖不一致的问题。用一个源写清楚优先级清楚就够了。6.2 WiFi 作为备用网络我的板子刚好带一个 SDIO WiFi 模组刷完 Debian 后默认没有装 wpa_supplicantWiFi 形同虚设。既然选了 NetworkManager 或者只想要个备用网络就装apt install network-manager wpasupplicant systemctl enable --now NetworkManager nmcli device wifi connect 你的SSID password 你的密码这里有一个很实在的坑Debian 的 WiFi 固件包缺了通常会静默失败连ip link都看不到 wlan0。遇到这种情况先查内核模块是否加载lsmod | grep rkwifi dmesg | grep -i wifi如果确实支持再补装固件包如firmware-brcm80211或对应芯片厂的兼容固件。WiFi 在有线断开时能救命但别把它当成主力网络稳定性始终不如有线。6.3 时区、NPU 与散热这几个属于顺手处理的细节但都价值很高。时区不改的话日志时间全是 UTC排查问题会想骂人timedatectl set-timezone Asia/ShanghaiRK3568 的 NPU 是 0.8TOPS如果你想在 Debian 里跑 RKNN 模型需要安装 rknpu2 用户态库librknnrt.so并且注意用户态版本和内核里的 NPU 驱动版本要匹配否则推理会报版本不匹配错误。这个没有捷径要盯着官方的 Release 版本号对。散热一定要重视。我一开始图省事没放散热片跑 NPU 推理大约五分钟核心温度就飙到 85 度以上然后明显降频整个推理速度肉眼可见地掉一截。后来加了个几块钱的铝散热片加小风扇温度稳定在 60 度以下才算真正能用。这段折腾下来我的最大体会是刷机本身很简单真正复杂的是把系统从“能用”变成“好用”。尤其是嵌入式系统里你能拿到的 rootfs 往往默认没有网络管理、没有桌面、连基本服务都是裸奔状态。所以我现在拿到一块新板子的习惯是先看/proc/cmdline再看/etc/os-release然后立刻装齐网络管理组件最后才考虑业务软件。这样能避开一大半的坑。如果你手头的板子也遇到了重启后 IP 丢失的问题按我第 4 章的顺序一步步排查别一上来就改配置文件——大部分时候答案藏在 dmesg 里。
RK3568刷机从Buildroot到Debian：根治重启后IP丢失的完整排查指南
手上这块 RK3568 核心板出厂预装的系统是 Buildroot。刚拿到手的时候我还挺满意启动快、镜像小、没有一堆用不上的服务堪称所见即所得。可等我真的把它当成一台日常 Linux 用起来憋屈感就上来了——想装个 pip 包麻烦想跑 Node 服务更麻烦想让 Docker 跑起来几乎做梦。忍了两周我决定刷机把 Buildroot 换成 Debian。刷机本身不算难难的是一路踩出来的深坑。其中最有代表性的就是那个一度把我搞到崩溃的“重启手配 IP”问题每次 reboot 之后网络接口要么没有地址要么地址和上次不一样必须重新手动配一次 IP 才能连上。这篇文章就完整走一遍怎么从 Buildroot 刷到 Debian以及怎么根治这个“重启手配 IP”的顽疾。1. 为什么我决定把 Buildroot 换成 Debian1.1 Buildroot 没错只是它在等一个不适合它的场景先说清楚一点Buildroot 不是一个发行版而是一套“构建嵌入式系统”的方法论。你通过 menuconfig 配置内核、库和应用最后 make 出一整个带 rootfs 的固件镜像。它的核心哲学是静态裁剪为了体积小、启动快把不需要的东西全部剪掉。这种思路对量产设备非常友好镜像稳定、维护简单、开发者不会因为“多装一个软件”破坏现场环境。但它的代价也在这里rootfs 里没有真正的包管理能力。所谓“没有 apt”不只是少一条命令而是你整个软件交付模式回到了石器时代。我想要 python3-pip得重新配置 Buildroot 包选项然后整体 make我想要 Node.js 跑个服务npm 依赖链一展开几十个包全部手动管理我甚至想装个 sqlite3 边缘工具都要重新编译一份交叉编译工具链。对于做产品的人这可能无所谓但对我来说这块板子是拿来开发调试、跑应用的不是在产线上重复烧录的。Buildroot 再香也扛不住“软件变更频率高”的场景。真正压垮我的最后一根稻草是 Docker。Buildroot 里跑 Docker 不是不行但要凑齐一堆容器运行时的依赖比我从零刷一个 Debian 还要费时间。既然 RK3568 本身是一颗正经的 ARM64 四核处理器内存普遍配 2GB 到 8GB给它一个完整、有生态的 Debian 才是合理的归宿。1.2 我的真实需求清单在决定刷 Debian 之前我把自己接下来的需求列了个清单逐条对比 Buildroot 和 Debian 的满足成本需求Buildroot 的满足成本Debian 的满足成本Python 推理服务 pip 安装依赖需自定义 package反复 makeapt install python3-pip即可Node.js / npm 项目依赖链管理极痛苦apt install nodejs npmDocker / Compose要手动凑运行时依赖apt install docker.io docker-compose-pluginNAS / 存储服务需要手动移植源码编译apt 直接装 samba、zfsutils 等外接摄像头调试MIPI-CSI设备树还是要自己调工具少devicetree 调试工具齐全配合 v4l2 工具链方便得多对比完基本上没悬念。Buildroot 适合单功能、存储小、启动要求高的量产设备Debian 适合让我这种“什么都想装一装”的开发者快速做验证和交付。要注意的是Debian 官网并不直接发布 RK3568 的官方镜像它只是提供 rootfs 和软件仓库板级适配仍然要自己搞定 U-Boot、内核和设备树。这正是刷机这件事真正的门槛所在。1.3 顺手说下 RK3568 和 RK3566 的选型差异相关热搜词里一直有“rk3568、rk3568 3566区别”这里也提一嘴防止有人买错板子。RK3568 和 RK3566 的 CPU 核心、NPU 算力基本一致都是四核 Cortex-A55 0.8TOPS 的 NPU真正的差异在接口丰富度上。RK3568 支持 PCIe3.0、SATA3.0、双千兆 GMAC、USB3.0 OTG扩展性明显更强RK3566 主打低成本便携接口更少通常不带 SATA/PCIe 或者只保留部分适合平板、机顶盒、低成本边缘盒子这类场景。如果你和我一样想做一台带 NVMe、多网口的小服务器直接盯住 RK3568。如果只是做一个低成本的显示终端或者轻量采集盒子RK3566 也够用。两者的刷机路径基本一致都是 Maskrom 模式 RK 工具烧录但内核设备树、电源设计不同不能混用固件。这也是很多新手刷机失败的原因之一——拿了 3566 的板子硬刷 3568 镜像自然起不来。2. 准备阶段不要直接开刷先想清楚三件事2.1 弄清楚三种模式Maskrom / Loader / 正常启动刷 RK 平台的芯片第一个要弄明白的就是模式。RK3568 有几种运行状态其中和我们刷机相关的有三种Maskrom 模式芯片内置 ROM 引导eMMC 是空盘或者已经损坏也能进入。此时芯片不加载任何外部固件只通过 USB 等待主机下发命令。这是刷机最安全的入口。Loader 模式U-Boot 正常跑起来之后进入的升级模式也叫 RockUSB 模式。系统正常时执行reboot loader可以进入或者上电前按住 Loader 按键。普通启动模式正常加载 U-Boot → 内核 → rootfs不参与刷机。进 Maskrom 的常见方法是短接 eMMC 的 CLK 引脚到 GND或者按住板子上的 Maskrom 按钮同时上电。不同板子按键位置不同我建议看自己板子原理图不要凭感觉短接万一把电源引脚短了就是真烧板子。进对模式之后USB 连接电脑工具里会识别到一颗“Rockchip Device”或“Loader Device”识别不到就检查驱动和 USB 线。2.2 固件从哪来自己编译还是直接用现成镜像刷机不能空手刷先准备好固件。RK3568 的 Debian 固件通常由这几部分组成U-Bootloader/bootloader、内核 设备树boot.img 或 dtb 分区、rootfsrootfs.img以及一个描述分区布局的 parameter.txt。固件来源我给三个路线按省事程度排序Armbian 现成镜像社区维护非常活跃对 RK3568/RK3566 的支持很成熟内核通常用 mainline 6.x设备树覆盖大量开发板。适合不想折腾底层、拿回来就想跑的人。缺点是如果你想深度定制 U-Boot 和内核还是要自己重新编译。厂家 SDK 提供的 Debian 镜像很多 RK3568 方案商或开发板厂商会直接发 Debian 镜像驱动和适配最全省去一大部分调板子的时间。但要注意厂家镜像的 Debian 版本可能偏旧仓库里的包管理方式也未必标准。自建 rootfs用 debootstrap 生成一份 Debian rootfs再用自己编译的 U-Boot 内核 设备树组合。灵活性最高但坑最多。我这次走的是第三条路线用 SDK 的 U-Boot内核自己编译 mainline 6.1 LTSrootfs 用 debootstrap 生成 bookworm。这套组合的好处是软件版本可控出问题时我至少知道每一层是谁。如果你不想第一天就陷进交叉编译建议先用 Armbian 把板子跑起来再逐步换掉其中某个组件这样更稳。2.3 备份与供电刷机失败最常见的原因刷机前有两件事被严重低估备份原厂固件和供电质量。备份这件事不要偷懒。在原来的 Buildroot 系统还活着的时候先把整个 eMMC 备份出来。方法很简单dd if/dev/mmcblk0 of/backup/emmc_backup.img bs4M convsync,noerror这个命令会把整块 eMMC 原样 dump 出来包含原有分区表、U-Boot、内核和 rootfs。我因为是开发板eMMC 只有 16GB备份两个多小时完成。备份文件放到 U 盘或者通过网络传到电脑上万一后面刷挂了能用dd写回去救砖。如果你不想整盘备份也可以只备份根分区和 boot 分区但整盘备份最保险。供电问题真的会杀人。RK3568 板子普遍需要 12V 或 5V 电源如果你为了省事直接用一个 USB 口给板子供电同时用另一个 USB 口做刷机数据线烧录到一半电流不足工具直接报错断开轻则刷一半重则把 eMMC 分区表写到一半损坏。我亲眼见过群友因为 USB Hub 供电不足刷机中断后板子直接变砖最后只能拆 flash 用编程器救。所以请务必用原装电源供电单独数据线接电脑并且尽量别把刷机 USB 插在机箱前面板。3. 刷机实操由 Buildroot 换成 Debian3.1 进入 Maskrom 与安装工具我用的板子有 Maskrom 按键操作是断电、按住 Maskrom 键、上电、松开然后 USB 线连接电脑。Linux 下我用的工具是upgrade_tool瑞芯微官方 Linux 刷机工具和它的老版本兄弟rkdeveloptool。安装依赖后编译或直接下载预编译版本然后先看能不能识别设备sudo upgrade_tool d如果输出类似Found USB 3.0 device: 001说明设备已经识别到了。识别不到时先检查 USB 线再检查设备权限可以试试sudo chmod 666 /dev/bus/usb/$(lsusb | grep Rockchip | awk {print $2})/$(lsusb | grep Rockchip | awk {print $4} | tr -d :)Windows 用户用 RKDevTool 更方便但有一个坑Win8 以上系统装瑞芯微驱动时经常撞上驱动签名必须重启进入“禁用驱动签名强制”模式再装。这个不处理好工具会一直提示没有发现设备十有八九都是驱动安全问题。3.2 分步烧录要点进入 Maskrom 之后刷机顺序非常关键。第一步永远是下载 Loader让设备从 Maskrom 切换到 Loader 模式否则后面写分区是不可用的。sudo upgrade_tool db Loader.binLoader 下载成功后再执行全量烧写。如果你手里是官方整包 update.img直接sudo upgrade_tool UL update.img这个命令会按照 update.img 里的 parameter.txt 把 U-Boot、dtb、boot、rootfs 等分区一次性写完。个人经验能用全量包一次写完就不要手贱一个分区一个分区写少出问题。如果你要自己定制分区大小比如把 rootfs 从默认 2GB 扩到 8GB就需要先修改 parameter.txt 中的 partition 定义再分别烧写各分区。RK 平台的分区概念和 PC 上不太一样它不依赖 GPT 而是用 parameter 文件描述大小和起始位置。改分区表之前想清楚改完后面还要重新格式化 rootfs 并写入镜像。烧写完成后不要立刻高兴先拔掉刷机 USB 线用串口线连接板子的调试串口一般波特率 1500000少部分板子是 115200再上电观察启动日志。为什么一定要接串口因为很多问题屏幕不显示、网络不通只有串口里能看到 U-Boot 到内核的完整日志。没接串口等于瞎猜。3.3 第一次启动与验证正常进系统后第一件事不是急着配软件而是验证基础项uname -a cat /etc/os-release lsblk ip -br link如果lsblk能看到 mmcblk0 的多个分区说明 eMMC 布局符合预期ip -br link能看到网卡接口名称可能是 eth0也可能是 enP2p1s0 这类可预测命名说明设备树里 GMAC 节点已经被内核识别。第一登录默认 root 无密码立刻passwd改掉再用hostnamectl set-hostname改主机名。这些小事做在前面后面少折腾。然而等我把这些验证完一个诡异的问题很快浮现第一次启动网络是通的重启之后就完全没 IP 了。这就进入了本文的重头戏。4. “重启手配 IP”从偶发现象到根因的完整排查4.1 现象记录重启必丢 IP手动配号就好第一次进 Debian 时网络其实好得很我甚至顺手apt update更新了几百 MB 包。然后我 reboot噩梦开始。重启之后ip -br a输出只有 loeth0 上干干净净没有任何地址。手动执行ip addr add 192.168.1.100/24 dev eth0 ip link set eth0 up网络立刻通了能 ping 网关能 ssh。这说明硬件没坏、线缆没问题、网卡驱动也已经加载问题出在“启动阶段没有自动完成网络配置”这一层。我当时第一反应是哦rootfs 里没装 NetworkManager那 20 分钟就能装好解决。事实证明我太天真。4.2 刚开始的误判以为是缺 NetworkManager用 debootstrap 生成的 rootfs 默认不会安装 NetworkManager、ifupdown、wpa_supplicant 这些网络管理组件这一点我很清楚。所以我先启动 systemd-networkd准备用 systemd 自己的网络管理来接管systemctl enable --now systemd-networkd重启再ip -br a还是空的。这时候我开始觉得不对。systemd-networkd 只是没有收到配置不是没有启用所以我开始怀疑接口名。4.3 继续挖接口名压根不叫 eth0跑一下ls /sys/class/net发现接口叫enP2p1s0不是 eth0。这是 systemd 的可预测命名规则根据 PCI 总线位置生成名字。问题来了我配置 networkd 时写的 Match 条件是Nameeth0但它实际叫enP2p1s0Match 不上自然也就不会执行 DHCP。这一步算是有进展我把 networkd 的 Match 改成NameenP2p1s0再写了一份 udev 规则把接口固定成 eth0SUBSYSTEMnet, ACTIONadd, ATTR{address}xx:xx:xx:xx:xx:xx, NAMEeth0重启之后接口名确实稳定成了 eth0但 IP 还是不来。此时我有点上头了——配置已经对了为什么还是不行于是决定不再猜直接看内核日志。4.4 转折点dmesg 里的 PHY attach 失败每次重启后我都先抓日志dmesg | grep -iE gmac|stmmac|phy终于看到关键信息could not attach PHY、stmmac: no PHY found。这行字的意思是GMAC 驱动虽然探测到了但没能成功连接板载 PHY 芯片。再跑ethtool eth0显示Link detected: no。物理链路根本没起来那就算 DHCP 请求发出去也收不到回应网络自然不通。为什么会 attach 不上 PHY查板子原理图发现这颗 PHY 是千兆芯片而 SDK 默认设备树里写的phy-mode rgmii但实际走线对 RGMII 的 TX/RX delay 处理方式要求的是rgmii-id。从根本上说MAC 侧和 PHY 侧对延迟处理的理解不一致导致 PHY 协商失败链路永远起不来。这个问题改设备树就能解决但我当时还没意识到这只是第一层坑。改完 DTB 之后ethtool eth0显示Link detected: yes链路正常了但新的问题马上浮现——DHCP 依然拿不到 IP而且 MAC 地址每次重启都不一样。4.5 隐藏最深的坑MAC 地址每次重启都在漂移每次重启后我都会看一眼ip a微信上陆续记录了四五组 MAC 地址没有一组是相同的。这一步让我意识到大事不好板子的 U-Boot 里没有烧录固定以太网 MAC 地址U-Boot 每次启动都会随机生成一个 MAC然后通过设备树传给 Linux。DHCP 的工作原理是“按 MAC 分配租约”MAC 一变路由器里为旧 MAC 保留的 IP 就全部作废新 MAC 重新发起 DHCP 请求租约池里又可能给你分一个完全不同的 IP。这就是为什么我手动 配好 IP 能上网、一重启又全没了——因为整个链路层身份都在漂。你可能会问那我手动静态配置本地 IP不依赖 DHCP不就行了确实可以但静态配的 192.168.1.x 和路由器网关、DNS、掩码必须手写全而且多台设备一多就冲突。更重要的是如果 MAC 不稳定路由器上做 DHCP 静态绑定、防火墙按 MAC 限速这些全部失效。所以 MAC 漂移这个问题必须治。4.6 排查结论不是单一原因而是四层叠加回头看这个“重启手配 IP”根本不是某一个 bug而是四个问题叠加后的综合症状网络管理服务缺失/未启用启动阶段没人跑 DHCP接口名因可预测命名规则变化配置文件 Match 不上设备树 phy-mode 配置和实际 PHY 不匹配物理链路起不来MAC 地址每次重启都不同DHCP 租约和绑定全部失效。只修其中任何一条问题都不会好。我之前“改了系统配置但没用”的原因就在这里你修对了 A但 B 和 C 还烂在原地系统依然表现出“没网”的状态。所以遇到这种综合性问题不要期望一行配置能解决必须一层一层查按链路 → 驱动 → 接口 → 地址的顺序排查。5. 根治方案让网络在启动阶段自己长出来5.1 先固定 MAC把身份定下来第一步也是最重要的一步是在 U-Boot 里设置固定 MAC。我的板子在 U-Boot 控制台里直接执行setenv ethaddr 00:11:22:33:44:55 saveenv这里要注意两点MAC 地址不要用全 0也不要用多播地址最好在多个板子之间规划一个“网卡 MAC 段”避免两台板子撞 MAC 造成 DHCP 混乱。设置好之后重启确认ip link里 MAC 已经固定。有些 SDK 会从 eMMC 特定分区读取 MAC 并在启动脚本里覆盖ethaddr如果设置不生效就要去查 U-Boot 启动环境变量里的bootcmd或者平台相关脚本。U-Boot 层固定是最彻底的办法比 Linux 里用 systemd service 去改 MAC 干净得多。5.2 固定接口名让 eth0 永远叫 eth0MAC 固定之后接口名也要固定。如果你不在乎叫什么直接把 networkd 的[Match]改成实际接口名也可以但对后续维护来说固定的 eth0 更直观、更好写脚本。两种方式任选udev 规则方式写在/etc/udev/rules.d/70-net-name.rulesSUBSYSTEMnet, ACTIONadd, ATTR{address}00:11:22:33:44:55, NAMEeth0或者 systemd link 方式写在/etc/systemd/network/10-eth0.link[Match] MACAddress00:11:22:33:44:55 [Link] Nameeth0实测两种都能生效。不要两套规则同时写否则可能会出现规则竞争导致接口名时对时错。改完之后udevadm test /sys/class/net/*或者直接重启验证。5.3 选一个网络管家并且只留一个网络管理服务是最容易踩“多个管家抢网口”坑的地方。我的建议有有线场景选 systemd-networkd有 WiFi 场景选 NetworkManager传统习惯可以选 ifupdown但无论如何只启一个。三者对比如下方案优点缺点适用场景systemd-networkd轻量、无依赖、配置简单Debian 默认自带管理 WiFi 麻烦基本要配合 wpa_supplicant纯有线、服务器、嵌入式NetworkManagerWiFi 管理强、有 nmcli/图形界面方便切换依赖多在无桌面环境显得重开发板当桌面/移动设备用ifupdown老派但稳定/etc/network/interfaces 一次配好缺乏动态管理能力切换网络不便固定配置的工业设备我最后选了 systemd-networkd。配置文件写成# /etc/systemd/network/10-eth0.network [Match] Nameeth0 [Network] DHCPyes # 如果要用静态 IP注释掉 DHCP改成下面三行 # Address192.168.1.100/24 # Gateway192.168.1.1 # DNS223.5.5.5然后启用systemctl enable --now systemd-networkd如果你选 NetworkManager则apt install network-manager systemctl enable --now NetworkManager nmcli device set eth0 managed yes这里特意要强调绝对不要同时开着 systemd-networkd 和 NetworkManager两个服务会抢网口甚至出现“NM 把网口 unmangednetworkd 又接管不了”的死循环。我排错时遇到过一次整整多花一个小时。5.4 修正设备树里的 PHY 配置如果你和我一样遇到Link detected: no那就要动设备树了。RK3568 的 GMAC 节点一般在设备树里叫gmac0、gmac1配置要点是status、phy-mode、phy-handle和 PHY 子节点的reg地址。我的板子需要把phy-mode从rgmii改成rgmii-idgmac0 { status okay; phy-mode rgmii-id; phy-handle phy0; }; mdio0 { phy0: ethernet-phy0 { reg 0; compatible ethernet-phy-idXXXX; }; };reg 0必须和板载 PHY 的 MDIO 地址一致这个地址查板子原理图不会猜。phy-mode的四种常见值rgmii、rgmii-id、rgmii-txid、rgmii-rxid分别对应是否在 MAC 或 PHY 侧加入 delay具体选哪个要看走线长度和 PHY 芯片手册。改好设备树后重新编译 DTB烧到dtb分区或者直接替换 boot.img 里的 resource.img。如果用的是设备树 overlay修改起来更方便不用反复烧整个 boot 分区。5.5 十连重启验证配置全部就位后不能只重启一次就宣布成功我写了一个暴力验证脚本放在 root 目录连续重启十次每次重启后检查 IP 和网关#!/bin/bash for i in $(seq 1 10); do echo ---- reboot test $i ---- sleep 15 ip -br a ping -c 1 -W 2 192.168.1.1 || echo ping failed systemctl reboot done注意这个脚本每次重启后不会自动继续需要你手动登录后重新执行否则它只跑一轮就结束了。我实际上每次登录都手动跑一次脚本记录十次重启的结果八次在开机 30 秒内拿到 DHCP 地址最慢的两次等了大约 5 秒DHCP 超时重传导致没有任何一次需要手动配 IP。这时候才敢说“重启手配 IP”这个问题真正根治了而不是碰巧生效。6. 换到 Debian 之后我额外处理的三件事6.1 更新源与 apt 提速rootfs 默认的/etc/apt/sources.list指向官方国际源在国内下载速度非常感人。我把源切换到了清华或者阿里镜像。以 bookwormDebian 12为例cat /etc/apt/sources.list EOF deb http://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm main contrib non-free non-free-firmware deb-src http://mirrors.tuna.tsinghua.edu.cn/debian/ bookworm main contrib non-free non-free-firmware EOF如果你是 Debian 13trixie把 bookworm 全部替换成 trixie 即可。然后执行apt update apt full-upgrade顺手把系统升到最新。这里提醒一点不要贪心同时加多个镜像源不同源的同步进度不一样混着写很容易产生依赖不一致的问题。用一个源写清楚优先级清楚就够了。6.2 WiFi 作为备用网络我的板子刚好带一个 SDIO WiFi 模组刷完 Debian 后默认没有装 wpa_supplicantWiFi 形同虚设。既然选了 NetworkManager 或者只想要个备用网络就装apt install network-manager wpasupplicant systemctl enable --now NetworkManager nmcli device wifi connect 你的SSID password 你的密码这里有一个很实在的坑Debian 的 WiFi 固件包缺了通常会静默失败连ip link都看不到 wlan0。遇到这种情况先查内核模块是否加载lsmod | grep rkwifi dmesg | grep -i wifi如果确实支持再补装固件包如firmware-brcm80211或对应芯片厂的兼容固件。WiFi 在有线断开时能救命但别把它当成主力网络稳定性始终不如有线。6.3 时区、NPU 与散热这几个属于顺手处理的细节但都价值很高。时区不改的话日志时间全是 UTC排查问题会想骂人timedatectl set-timezone Asia/ShanghaiRK3568 的 NPU 是 0.8TOPS如果你想在 Debian 里跑 RKNN 模型需要安装 rknpu2 用户态库librknnrt.so并且注意用户态版本和内核里的 NPU 驱动版本要匹配否则推理会报版本不匹配错误。这个没有捷径要盯着官方的 Release 版本号对。散热一定要重视。我一开始图省事没放散热片跑 NPU 推理大约五分钟核心温度就飙到 85 度以上然后明显降频整个推理速度肉眼可见地掉一截。后来加了个几块钱的铝散热片加小风扇温度稳定在 60 度以下才算真正能用。这段折腾下来我的最大体会是刷机本身很简单真正复杂的是把系统从“能用”变成“好用”。尤其是嵌入式系统里你能拿到的 rootfs 往往默认没有网络管理、没有桌面、连基本服务都是裸奔状态。所以我现在拿到一块新板子的习惯是先看/proc/cmdline再看/etc/os-release然后立刻装齐网络管理组件最后才考虑业务软件。这样能避开一大半的坑。如果你手头的板子也遇到了重启后 IP 丢失的问题按我第 4 章的顺序一步步排查别一上来就改配置文件——大部分时候答案藏在 dmesg 里。
