3. RK3568硬件与软件生态
在开始构建 rootfs 之前，必须先回答一个更基础的问题：RK3568 这颗芯片“能跑什么、怎么跑、用什么跑”。很多初学者一上来就急着编译 Buildroot 或烧写 Debian 镜像，结果在设备树、内核配置、启动参数上反复踩坑，根本原因是对 RK3568 的硬件架构与软件生态缺乏整体认知。本节从芯片架构、外设接口、官方 SDK 以及发行版选择四个维度，建立一张完整的“生态地图”，为后续 rootfs 构建与系统部署打下基础。
一、芯片架构：四核 A55 + NPU 的异构组合
RK3568 是瑞芯微（Rockchip）面向工业控制、边缘计算、商显和轻量 AI 场景推出的一颗中高端 SoC。其核心架构可以概括为“CPU + GPU + NPU + VPU”四类计算单元协同：
- CPU：四核 ARM Cortex-A55，主频最高约 2.0GHz，64 位 ARMv8-A 架构，支持 NEON 与 TrustZone。
- GPU：Mali-G52 2EE，支持 OpenGL ES 3.2、OpenCL 2.0、Vulkan 1.1，负责图形渲染与部分通用计算。
- NPU：0.8 TOPS 算力，支持 INT8/INT16，常用于轻量级 AI 推理，如人脸检测、目标识别。
- VPU：支持 4K H.264/H.265 解码与 1080P 编码，适合视频监控、播放器等场景。
这种异构架构决定了 rootfs 中必须包含对应的用户态驱动与库：GPU 需要 Mali 的 blob 或开源 Panfrost 驱动，NPU 需要 RKNN Runtime，VPU 需要 MPP（Media Process Platform）库。理解这一点，才能明白为什么不同发行版的镜像大小和依赖差异巨大。
二、外设接口：决定 rootfs 中需要哪些驱动与工具
RK3568 的外设接口非常丰富，常见的有：双千兆以太网、PCIe 3.0、USB 3.0、SATA、CAN FD、UART、I2C、SPI、PWM、MIPI-DSI/CSI、HDMI 2.0、eDP、LVDS 等。这些接口在 rootfs 层面会转化为三类需求：
- 内核驱动：如 CAN 需要 can-dev、can_raw 模块，WiFi 需要对应厂商的固件与 cfg80211 支持。
- 用户态工具：如 iproute2、can-utils、i2c-tools、usbutils、pciutils。
- 固件文件：如 WiFi 的 firmware、NPU 的 rknn_server、GPU 的 Mali blob。
因此，选择发行版时不能只看“能不能启动”，还要看它是否方便按接口裁剪。Buildroot 的优势正在于此：每个包都可以通过 menuconfig 精确控制。
三、官方 SDK：一切构建的起点
瑞芯微官方 SDK（通常称为 Linux SDK）是 RK3568 开发的基础。它包含 U-Boot、Kernel、设备树、Buildroot、Debian、Yocto 等多种构建目标，并提供统一的编译脚本。典型目录结构如下：
rk3568_sdk/
├── buildroot/ # Buildroot 构建目录
├── debian/ # Debian rootfs 构建脚本
├── yocto/ # Yocto 层与配方
├── kernel/ # Linux 内核源码
├── u-boot/ # U-Boot 源码
├── device/rockchip/ # 板级配置与设备树
├── external/ # 第三方库（RKNN、MPP 等）
└── build.sh # 统一编译入口官方 SDK 的最大价值是“一致性”：U-Boot、Kernel、rootfs 三者的版本与配置经过验证，能显著降低启动失败的概率。建议初学者先跑通官方默认配置，再逐步替换 rootfs。
四、发行版选择：Buildroot、Yocto、Debian 的取舍
这是本节最核心的决策点。三种主流方案各有适用场景，不能简单说谁“更好”。
| 对比维度 | Buildroot | Yocto | Debian |
|---|---|---|---|
| 构建方式 | Makefile + Kconfig，轻量直接 | BitBake + Layer，元数据驱动 | debootstrap + apt，包管理成熟 |
| 镜像体积 | 最小，可裁剪到几十 MB | 中等，取决于配方 | 较大，通常 1GB 以上 |
| 启动速度 | 快 | 较快 | 较慢 |
| 软件生态 | 需自行添加包 | 配方丰富，可复用 | apt 海量软件，开箱即用 |
| 适用场景 | 工业控制、量产设备、资源受限 | 多产品线、长期维护、定制化强 | 原型验证、AI 开发、桌面级应用 |
| 学习曲线 | 低 | 高 | 中 |
五、案例与误区复盘
案例：某团队用 Debian 镜像在 RK3568 上跑通了摄像头 + NPU 推理，但量产时发现启动要 25 秒、镜像 2.3GB，无法满足工业网关要求。后来切换到 Buildroot，只保留 MPP、RKNN、can-utils 和必要驱动，镜像降到 180MB，启动缩短到 6 秒。
常见误区：
- 误区一：认为 Debian 一定“更完整”。实际上 Debian 中大量包与嵌入式场景无关，反而增加攻击面和启动负担。
- 误区二：直接拿官方 Buildroot 配置不改就用。官方配置通常面向 EVB 开发板，实际产品需要修改设备树、裁剪包、调整分区。
- 误区三：忽略 GPU/NPU 用户态库的版本匹配。Mali 驱动、RKNN Runtime 与内核版本不匹配时，会出现“能启动但推理失败”的隐蔽问题。