RK3568 边缘计算网关项目从立项到小批量前后折腾了快半年。中途好几次想摔板子回头一看其实真正耽误进度的反而不是芯片本身而是方案选型阶段欠下的债。这篇文章就把踩过的坑一个个扒开连同最后的实操清单一起给出来评估选型 RK3568 做边缘计算网关的建议看完再动手。先交代一下背景。项目要做的是一个面向园区/工厂场景的边缘计算网关核心负载是视频流接入、Modbus/OPC UA 采集、本地推理告警和云端上送。CPU 跑 LinuxNPU 承担模型推理这是典型的 RK3568 应用区间。整体选型定的是 RK3568J 2GB DDR4 8GB eMMC 双千兆网口 4G 模块 若干 RS485/USB 的硬件形态。看似不复杂实际每一步都有讲究尤其是下面5个坑基本都是经验买回来的。1. 第一坑只盯着 CPU 算力忽略了 RK3568 的“周边配套”1.1 选型之初最容易犯的错误很多人在选边缘计算网关方案时习惯先看核心板参数表四核 A55、主频 2.0GHz、支持 4K 编解码、NPU 0.8TOPS、DDR4 等等。RK3568 在这些纸面参数上很漂亮和上一代 RK3288/RK3399 相比也更“现代”。但边缘网关不是开发板你要的不是“能跑 demo”而是“稳定跑 3 年”。只看算力选型后面会有很多隐形问题。第一个容易踩的点是外设接口复用冲突。RK3568 的 PCIe 3.0、SATA、USB3.0 之间有多路复用关系核心板厂家做引脚分配时也各有取舍。你想象中“又要有 PCIe 接 4G 模组或 AI 加速卡、又要有 SATA 接存储、又要 USB3.0 口”在单颗 RK3568 上很可能同時没法全满足。很多核心板只引出了其中一组选型时没看引脚复用说明等到布线或软件适配阶段才发现某个外设根本点不亮那就很被动了。另外容易被忽略的是PMIC 与供电设计。RK3568 虽然功耗比 RK3588 低不少但网关设备往往要支持 9-36V 宽压输入、掉电保护、温宽 -20℃ 到 70℃ 甚至更严苛。如果只买一个性能强但不带电源管理优化、没有做过宽温验证的“准工业级”核心板在整机测试时会出现高温死机、电源纹波干扰外设的问题那个返工成本远超过你一开始多花的几百块。1.2 要实用的接口矩阵检查清单我在第二版选型时换了个思路先把整机接口需求列成表再拿这张表去挨个核对开发板/核心板的引脚分配而不是先看算力。功能模块接口需求RK3568 对应资源关键注意点4G 模块PCIe 或 USB3.0PCIe 2.0/USB3.0确认与 SATA 是否复用避免冲突视频输入4 路 AHD/网络摄像头MIPI CSI / 以太网MIPI 只支持有限路数网络摄像头更省资源本地存储128GB SSD 或大容量 eMMCSATA / SDIO / eMMC选 SATA 时需评估 PCIe 复用关系工业接口RS485/RS232/CANUART/SPI/CAN检查核心板引出的 UART 数量是否足够调试口1 路调试串口UART0/UART2确认默认调试口是否为 TTL 电平规格加密芯片SPI/I2CSPI/I2C确认 I2C 总线没有被摄像头或 EEPROM 占用这次复盘的经验是选 RK3568 方案时先把外设资源冲突表拉出来挨个打勾再谈性能。很多时候核心板厂家方案里藏着“这个不能用、那个要飞线”的坑早发现早换板真到贴片阶段想改都难。2. 第二坑设备树从网上东拼西凑越调越乱2.1 核心问题是没搞懂“这棵设备树是给谁用的”RK3568 相关的开源资料非常多尤其是 OpenHarmony、Ubuntu、Debian、Buildroot 生态下各家的设备树文件满天飞。很多人的习惯是“先拿一份能启动的 dts然后往里面加自己要的外设节点”。听起来没问题但实际上一旦你同时要调摄像头、RS485、4G 模块、加密芯片就会发现网上 A 版本的 dts 和 B 版本的 dtsi 根本对不上同一个外设的节点在 A 里叫camera0在 B 里叫ov5695这类不一致极其浪费调试时间。更麻烦的是RK3568 官方设备树分了两个层级SoC 级公共 dtsi如rk3568.dtsi和板级 dts如rk3568-evb.dtsi。从网上下载的很多设备树已经经过板厂二次修改你并不知道它基于哪个 BSP release。直接拿过来用导致内核里 device 节点与驱动不匹配启动时deferred probe一屏一屏刷外设一个都枚举不出来。比较稳妥的做法是以官方 SDK 为基线只改板级 dts不碰 SoC 级 dtsi。所有外设差异全部通过 overlay 或板级 dts 增量节点描述。这样即便后面同步官方更新也只需要把增量部分重新 rebase 上去不会产生一堆不可控的黑魔法。2.2 设备树调试实操清单在项目里我是这样收敛设备树问题的先确认使用的是哪份 SDK。建议直接拉取 Rockchip 官方 SDK 或你核心板厂家维护的 SDK不要自己从 GitHub 东拼西凑。手势确认 SDK 的内核版本RK3568 一般基于内核 4.19 或 5.10两者 DMA、GPU、NPU 驱动都有差异。确认跑的是哪个系统。OpenHarmony 的 RK3568 设备树和 Linux 的不一样Ubuntu 如果使用的是通用内核很多外设驱动如 NPU 的 rknpu、VPU 的 mpp是缺失的只适合做应用验证不适合做网关量产。编译内核时建议把 dts 相关的 DEBUG 选项打开。在kernel/arch/arm64/boot/dts/rockchip/Makefile里确认目标 dts 是否被编译进去有用make dtbs只编 dts 的也有在menuconfig里开CONFIG_OF_OVERLAY的根据你的流程来。设备树文件基本可以这样定位rk3568.dtsiSoC 公共资源时钟、中断、pinctrl、i2c/uart 控制器定义。rk3568-evb.dtsiEVB 板级公共配置DDR 频率、PMIC、关键外设。你的板级 dtsrk3568-myboard.dts在这里差异化修改。每次修改 dts建议同步 grep 一下新加入的 GPIO 是否已经在别的节点里被占用。比如你要把某个 GPIO 用作 RS485 方向控制却在别处已经被定义为 LED 或按键这个很难一眼看出来。调试过程中我用得最多的命令# 启动后在板端查看设备树实际解析结果 ls /proc/device-tree/ cat /proc/device-tree/model # 查看某个节点的 status、compatible、reg 等关键属性 cat /proc/device-tree/soc/i2cfe5f0000/status # 查看哪些设备 probe 失败 dmesg | grep -E probe|fail|No such device # 查看中断、GPIO 申请情况 cat /proc/interrupts cat /sys/kernel/debug/gpio踩坑典型现象是改了 dts 后重新烧录内核发现外设还是没起来。此时不要习惯性怀疑 dts 没改对优先确认内核是否真的加载了新 dtb。很多人用的是 U-Boot 里固化的 dtb或者内核 FIT image 内嵌的 dtb而不是你编译出的那个 dtb。我建议把实际加载的 dtb 导出来与源码比对确认一致再继续调。3. 第三坑NFS 挂载 rootfs 调试卡在启动流程反复重启3.1 网口、IP、内核参数一个都不能少RK3568 在开发阶段我强烈建议直接用 NFS 挂载 rootfs这样调整 rootfs 里的程序、库、脚本都不需要反复烧写 eMMC开发效率能提升一大截。但 NFS 挂载本身就有几个很容易埋雷的点。先说网络拓扑。RK3568 开发板上如果有两个千兆口要注意哪个是eth0、哪个是eth1。很多调试都是从 U-Boot 设置环境变量然后在 kernel cmdline 里指定ipdhcp如果网线插的是另外一个网口NFS 自然起不来。我习惯固定一个网口作为调试口例如硬设eth0为静态 IP避免 U-Boot 和 kernel 之间拿到不同 IP。另一个非常隐蔽的坑是NFS 版本兼容性。主机侧如果用的是 Ubuntu 18.04 之后的系统默认的nfs-kernel-server可能只开着 NFSv4。而内核侧如果 busybox 或 initramfs 里的 NFS 客户端只支持 NFSv3两者握手不成功现象就是卡在Waiting for root device /dev/nfs...一直反复重启。那几个月里我把这个错误重复踩了不下十次。后面固定了一套比较稳的配置主机侧# 安装 NFS 服务 sudo apt install nfs-kernel-server # 编辑 /etc/exports # /srv/nfs/rootfs 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash) sudo exportfs -ra # 查看导出状态 showmount -e板端启动参数以 U-Boot 环境变量为例setenv bootargs root/dev/nfs nfsroot192.168.1.100:/srv/nfs/rootfs,vers4,tcp ip192.168.1.101:192.168.1.100:192.168.1.1:255.255.255.0::eth0:off rw init/sbin/init这里关键是vers4要和主机 NFS 服务版本对上。要是你的内核 NFS 客户端就是老版本可以在主机侧同时开启 NFSv3# /etc/default/nfs-kernel-server RPCNFSDCOUNT--nfs-vers 3,4另外no_root_squash很重要。如果不加板端 root 用户对 NFS 目录的写权限会被 squash 成 nobody很多程序在调试阶段就出现“没有权限”的诡异错误。3.2 启动卡住后的快速排查方法NFS 挂不上现象很统一控制台停在VFS: Cannot open root device nfs or unknown-block(0,0)或者一直打印Waiting for root device /dev/nfs。排查顺序建议是这样的先确认网络通不通。在 U-Boot 里ping 192.168.1.100如果不通先解决物理链路和 IP 配置。U-Boot 里能 ping 通但内核起不来多半是 kernel cmdline 的 IP 格式不对或者网卡驱动 probe 太晚、没来得及带上 IP。可以在 cmdline 里加ipdhcp试试DHCP 成功后再换回静态 IP。如果网络通、IP 也拿到了还是报 NFS 错误就在板端手动执行mount -t nfs 192.168.1.100:/srv/nfs/rootfs /mnt看看具体错误码。No such file or directory基本是 rootfs 路径不对Permission denied则是 export 权限或no_root_squash没有配好。最后排查防火墙。主机 ufw 如果开着记得放行 NFS 相关端口sudo ufw allow from 192.168.1.0/24 to any port nfs。NFS 调试还有个加分技巧把内核编译成CONFIG_ROOT_NFSyCONFIG_IP_PNP_DHCPy这样不需要 initramfs 也能直接挂 NFS省去很多 initramfs 打包的麻烦。4. 第四坑摄像头/外设调试死在 MIPI、I2C、GPIO 的组合拳下面4.1 OV5695 这类 sensor 调试先把电源和时钟理清楚项目里需要接入一路摄像头做视觉检测选的是 OV5695 这类常见 MIPI sensor。折进去的时间不少问题主要集中在几个方面I2C 地址探测不到、MIPI 通道无数据、图像颜色偏绿。i2cdetect检测不到 sensor 地址这是最常见的失败现象。此时大概率不是 dts 写错而是 sensor 的上电时序不满足。OV5695 这类 sensor 一般需要DVDD 1.2V、AVDD 2.8V、DOVDD 1.8V而且上电顺序有严格要求。如果你在板级 dts 里配置了 regulator但 regulator 的startup-delay-us不够sensor 内部没完成初始化I2C 就会一直 NACK。一个很管用的调试方法在驱动probe里临时加mdelay或者在 dts 中把pwdn-gpios、reset-gpios的延时加大i2c4 { status okay; ov5695: ov569536 { compatible ovti,ov5695; reg 0x36; pinctrl-names default; pinctrl-0 ov5695_pwdn ov5695_reset; reset-gpios gpio4 RK_PA4 GPIO_ACTIVE_LOW; pwdn-gpios gpio4 RK_PA5 GPIO_ACTIVE_HIGH; avdd-supply vcc2v8_cam; dvdd-supply vcc1v2_cam; dovdd-supply vcc1v8_cam; rockchip,camera-module-index 0; rockchip,camera-module-facing back; port { ov5695_out: endpoint { remote-endpoint mipi_in_ucam0; ># 主机侧模型转换 量化 rknn-toolkit2 from rknn.api import RKNN rknn RKNN() # 设置 dataloader 用于量化校准 ret rknn.load_pytorch(modelyolov5s.pt, input_size_list[[1, 3, 640, 640]]) ret rknn.build(do_quantizationTrue, dataset./dataset.txt) # dataset.txt 里放若干张代表真实场景的图片路径不要用一张纯黑图糊弄 rknn.export_rknn(yolov5s.rknn)然后板端推理# RK3568 上使用 librknnmrt.so from rknnlite.api import RKNNLite rknn_lite RKNNLite() rknn_lite.load_rknn(yolov5s.rknn) rknn_lite.init_runtime() outputs rknn_lite.inference(inputs[img])这里最容易犯的错是量化校准数据集太随意。如果你用五六张无关图片做校准模型精度会掉得很厉害。建议从实际部署场景中截取一两百帧覆盖不同光照、不同角度量化出来的模型才真的能用于现场。这也算是一个“选型阶段就要预留时间”的隐性成本很多人在排期时没有把模型转换和量化调优的时间算进去。5.2 容器、OTA 和量产烧录的坑边缘计算网关通常跑 Docker把采集、推理、上云等拆成不同容器但 RK3568 上跑容器要注意内核配置。官方内核默认可能没开CONFIG_MEMCG、CONFIG_BLK_CGROUP等 cgroup 相关配置Docker 启动时会报cannot enter cgroup namespace。这个在调应用前就要先确认内核.config不然等容器部署阶段才发现又得重编内核。OTA 更是容易被忽略的大问题。边缘网关往往分布在多个现场不可能每次升级都派工程师拿刷机线去弄。需要设计好 A/B 分区或 recovery 分区方案。RK3568 的 eMMC 启动流程一般是U-Boot - boot.img - rootfs升级时需要同时校验 boot 和 rootfs 签名避免中途断电变砖。我在早期方案里只做了 rootfs 的 OTA升级完才发现 kernel 没跟上驱动接口变了rootfs 起不来现场设备直接离线。最后改成 kerneldtbrootfs 一体升级才把这个隐患解决。量产烧录阶段RKDevTool 是官方工具但产线上一般用脚本化烧录。建议把整个烧录流程做成一条命令包括擦除、烧写、校验而且烧完后要自动跑一段自检脚本检查关键外设是否起来、MAC 地址是否唯一、NPU 节点是否存在。这些细节看起来简单但小批量生产时能省下大量返工时间。6. 配套附送选型校验实操清单最后把这次的复盘整理成一份可以直接用的校验清单做 RK3568 边缘计算网关选型时逐条过一遍能避开大部分我踩过的坑。阶段校验项通过标准方案选型CPU/NPU 算力是否满足最大负载跑通典型模型 留 30% 余量方案选型接口复用关系是否排查清楚4G/存储/摄像头/串口不冲突方案选型核心板温宽、供电、PMIC 是否满足工业场景-20~70℃ 和 9~36V 宽压软件基线是否使用官方 SDK 或核心板厂家维护 SDK内核、dtb、驱动版本可控设备树板级 dts 是否单独管理不随意改 dtsi增量节点清晰可回溯调试环境NFS 挂载 rootfs 是否验证过网络、NFS 版本、权限均正常外设调试sensor/摄像头是否完成出图测试I2C、MIPI、时钟均正常推理链路RKNN 模型是否用真实场景数据量化精度和帧率达到业务需求部署形态Docker/容器运行是否验证内核 cgroup 配置满足要求OTA 方案升级是否具备原子性、失败回滚kerneldtbrootfs 整体升级量产准备烧录流程是否脚本化是否带自检产线可一键烧录并自动校验我个人在实际项目里的体会是RK3568 本身是一个很适合边缘计算网关的芯片性能功耗比不错接口丰富生态也在持续完善。但它的“好”必须建立在严谨的选型评估和调试流程上。上面这些坑都是靠加班和现场返工换来的希望这份清单能帮你把这些弯路一次性绕过去。后面如果大家感兴趣我也可以把 NFS 调试的脚本、RKNN 模型的量化案例、以及 OTA 升级的具体方案分别展开写一写。