3、开发环境搭建：配置交叉编译工具链、SDK、串口/网络调试环境，以及远程开发与部署流程

RK3568/RK3566 属于 ARM Cortex-A55 架构的应用处理器，其目标运行环境通常为嵌入式 Linux 系统，而开发主机多为 x86_64 架构的 Ubuntu 工作站。这种架构差异决定了我们无法直接在开发机上编译并运行目标程序，必须借助交叉编译工具链生成可在 ARM 平台上执行的二进制文件。同时，一个完整的工业 AI 网关开发环境还包含 SDK（Rockchip 提供的 Linux SDK）、串口调试终端、网络文件系统（NFS/TFTP）以及远程部署通道。本章将系统讲解从零搭建这套环境的核心步骤、关键参数与常见排障方法，帮助开发者建立一条高效、可复现的“编译—传输—调试—部署”流水线。

上图展示了整个开发环境的物理与逻辑拓扑。开发主机通过三条主要链路与目标板交互：串口用于底层引导与内核调试，以太网用于文件传输与远程登录，USB 用于系统镜像烧录。理解这三条链路的职责边界，是后续配置的基础。

3.1 交叉编译工具链的安装与验证

核心原理

交叉编译工具链由编译器、汇编器、链接器、C 库头文件及调试工具组成。针对 RK3568/RK3566，Rockchip 官方推荐使用基于 GCC 10.3 的 aarch64-linux-gnu- 前缀工具链。该工具链运行在 x86 主机上，但生成的是 ARMv8-A 架构的 64 位指令集代码。需要特别注意的是，工具链的 glibc 版本必须与目标板根文件系统的 glibc 版本兼容，否则会出现运行时 GLIBC_2.xx not found 的错误。

操作流程

1. 下载工具链：从 Rockchip 官方或 ARM 官网下载 gcc-arm-10.3-x86_64-aarch64-none-linux-gnu 压缩包。
2. 解压与路径配置：将工具链解压至 /opt/ 目录，并添加至 PATH 环境变量。

sudo mkdir -p /opt/arm-toolchain
sudo tar -xvf gcc-arm-10.3-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt/arm-toolchain
export PATH=/opt/arm-toolchain/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin:$PATH
echo 'export PATH=/opt/arm-toolchain/gcc-arm-10.3-x86_64-aarch64-none-linux-gnu/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

3. 验证编译：编写一个简单的 Hello World 程序，使用交叉编译器编译，并通过 file 命令确认生成的是 ARM 架构的 ELF 文件。

aarch64-none-linux-gnu-gcc hello.c -o hello_arm
file hello_arm
# 输出应包含: ELF 64-bit LSB executable, ARM aarch64

案例拆解：工具链版本不匹配导致的运行时崩溃

某项目在编译 RKNN 推理程序时，开发机使用 Ubuntu 20.04 自带的交叉编译器，编译过程无报错。但将可执行文件拷贝至目标板后，运行立即报错：./inference: /lib/aarch64-linux-gnu/libc.so.6: version 'GLIBC_2.33' not found。分析发现，目标板根文件系统为 Buildroot 构建，glibc 版本为 2.31，而主机工具链链接了更高版本的 glibc 符号。解决方法是重新下载 Rockchip SDK 配套的 gcc-arm-10.3 工具链，并清理 CMake 缓存后重新编译，问题解决。此案例说明，工具链与目标系统库的版本匹配是交叉编译的第一原则。

常见误区

• 误以为交叉编译后的程序可以在主机上直接运行测试。
• 忽略工具链的 sysroot 参数，导致头文件搜索路径错误。
• 在 Makefile 中硬编码编译器路径，导致团队协作时环境不一致。

3.2 Rockchip Linux SDK 的获取与目录结构

核心原理

Rockchip Linux SDK 是一个集成了 U-Boot、内核、Buildroot/Debian 根文件系统、以及众多板级配置的巨型代码仓库。它基于 repo 工具管理多个 Git 子仓库，确保各组件版本的一致性。SDK 不仅是编译固件的工具集，更是驱动开发、应用调试的参考基准。

SDK 目录结构速查表

操作流程

# 安装 repo 工具
mkdir -p ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
export PATH=~/bin:$PATH

# 初始化 SDK（以 RK3568 为例）
mkdir -p ~/rk3568_sdk && cd ~/rk3568_sdk
repo init -u https://github.com/rockchip-linux/manifests.git -b master -m rk3568_linux_release.xml
repo sync -j8

同步完成后，需要执行 source build/envsetup.sh 并选择板型配置文件，例如 lunch rk3568-evb1-ddr4-v10。这一步会设置编译所需的环境变量，包括交叉编译器路径、内核配置等。

常见误区

• 直接修改 SDK 中的文件而不使用 Git 分支管理，导致后续同步冲突。
• 忽略 device/rockchip 下的板级 dts 文件，导致编译出的内核无法匹配实际硬件。
• 在 Windows 或 macOS 上尝试编译 SDK，Rockchip 官方仅支持 Ubuntu 18.04/20.04 x86_64 环境。

3.3 串口与网络调试环境配置

核心原理

串口是嵌入式开发的生命线。RK3568 的调试串口默认使用 UART2，通过板载 USB 转串口芯片（如 CH340、CP2102）连接至开发机。串口不仅用于查看 U-Boot 和内核日志，还可在系统无法启动时进入 U-Boot 命令行进行恢复操作。网络调试则基于以太网接口，提供高带宽的文件传输（NFS、SCP）和远程登录（SSH）能力。

串口配置参数

操作流程

# 安装串口工具
sudo apt-get install minicom picocom

# 使用 picocom 连接（推荐，退出为 Ctrl+A Ctrl+X）
picocom -b 1500000 /dev/ttyUSB0

# 使用 minicom 连接
minicom -s  # 进入设置，选择 Serial port setup
# 设置 /dev/ttyUSB0，波特率 1500000，关闭流控

网络环境配置方面，开发机需要配置静态 IP，目标板通过 DHCP 或静态 IP 与开发机互通。推荐使用网线直连，并设置开发机 IP 为 192.168.1.100，目标板为 192.168.1.101。

# 开发机配置
sudo ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up

# 目标板（在串口终端中执行）
ifconfig eth0 192.168.1.101 netmask 255.255.255.0 up
ping -c 3 192.168.1.100

案例拆解：NFS 挂载根文件系统加速开发

在开发初期，频繁烧写根文件系统既耗时又容易损坏存储介质。更高效的做法是让目标板通过网络挂载开发机上的根文件系统。具体操作：在开发机安装 NFS 服务，导出 /srv/nfs/rootfs 目录，将 SDK 编译出的 rootfs 解压至此。然后在 U-Boot 中设置启动参数：

setenv bootargs 'console=ttyS2,1500000 root=/dev/nfs nfsroot=192.168.1.100:/srv/nfs/rootfs,v3 ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:off rw'
saveenv
boot

此方案的优势在于，开发机上的文件修改后目标板立即生效，无需重新烧写。但需要注意，NFS 挂载对网络稳定性要求较高，且不适合进行内核或驱动调试（因为内核本身仍在本地存储）。

常见误区

• 串口无输出时，首先检查 USB 转串口驱动是否安装（ls /dev/ttyUSB*），而非盲目怀疑板卡故障。
• 网络 ping 不通时，忽略防火墙设置。开发机需关闭 ufw 或放行 NFS/SSH 端口。
• 使用 NFS 时忘记指定 v3 协议，导致挂载失败。

3.4 远程开发与部署流程

核心原理

远程开发的核心思想是“代码在主机，编译在主机，运行在目标板”。通过 SSH 协议，开发者可以在 VSCode 等 IDE 中直接编辑目标板上的文件，或通过 Remote-SSH 插件将整个开发环境映射到本地窗口。部署流程则涉及将编译产物（可执行文件、动态库、模型文件）传输至目标板，并管理运行依赖。

推荐开发流程

1. 代码同步：使用 Git 管理代码，开发机作为远程仓库，目标板通过 git pull 拉取最新代码。
2. 交叉编译：在开发机上使用 CMake 或 Makefile 进行交叉编译，生成 ARM 可执行文件。
3. 文件传输：使用 scp 或 rsync 将产物拷贝至目标板。
4. 远程调试：通过 SSH 登录目标板，使用 gdbserver 配合主机侧的 gdb 进行远程调试。

# 编译（开发机）
cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..
make -j4

# 传输（开发机）
scp ./bin/vision_app root@192.168.1.101:/usr/local/bin/

# 远程运行（开发机）
ssh root@192.168.1.101 "/usr/local/bin/vision_app --model yolov5.rknn"

VSCode 远程开发配置

安装 Remote-SSH 插件后，配置 ~/.ssh/config 文件：

Host rk3568
    HostName 192.168.1.101
    User root
    Port 22
    IdentityFile ~/.ssh/id_rsa

连接后，VSCode 会在目标板上安装一个轻量级服务端，实现代码补全、断点调试等功能。对于交叉编译，可以配置 tasks.json 调用开发机上的编译命令，实现“编辑在远端，编译在本地”的混合模式。

案例拆解：基于 systemd 的自动部署与守护

某工业网关项目要求 AI 检测程序开机自启，并在异常退出后自动重启。开发团队编写了 systemd 服务单元文件 /etc/systemd/system/vision.service：

[Unit]
Description=AI Vision Gateway Service
After=network.target rknpu.service

[Service]
Type=simple
ExecStart=/usr/local/bin/vision_app --config /etc/vision/config.yaml
Restart=always
RestartSec=3
User=root
Environment="LD_LIBRARY_PATH=/usr/local/lib"

[Install]
WantedBy=multi-user.target

部署时，通过脚本将编译产物、配置文件、模型文件打包为 .tar.gz，使用 scp 传输后解压至目标路径，并执行 systemctl daemon-reload && systemctl enable vision。该方案将部署时间从手动操作的 10 分钟缩短至 30 秒，且提供了崩溃自动恢复能力。复盘发现，初期未设置 Environment 变量导致程序找不到 RKNN 运行时库，增加该行后问题解决。

常见误区

• 直接在目标板上编译源码，浪费 ARM 性能且依赖目标板安装完整工具链。
• 忽略 SSH 密钥配置，每次部署都输入密码，降低自动化效率。
• 部署后不验证运行状态，导致现场出现“编译通过但运行崩溃”的问题。

总结而言，一套成熟的开发环境应当具备三个特征：工具链版本可追溯、调试链路冗余（串口+网络）、部署流程自动化。建议团队将环境搭建过程写成 Shell 脚本或 Dockerfile，确保新成员能在 30 分钟内复现相同环境。在实际项目中，将交叉编译工具链、SDK 路径、NFS 挂载点等配置纳入版本控制，是避免环境漂移的有效手段。