📚 课程目录第4章开发环境搭建

4. 开发环境搭建

RK3588 的 rootfs 定制与优化，第一步不是改文件，而是把“能编译、能下载、能启动、能调试”的闭环搭起来。开发环境一旦不完整，后续所有优化都会变成盲调。本章围绕交叉编译工具链、SDK 获取与编译、串口与网络调试、烧录工具与镜像生成流程四条主线，给出一套可直接落地的环境搭建方法。

一、核心原理：为什么 RK3588 必须用交叉编译

RK3588 是 ARM64 架构（Cortex-A76/A55 大小核），而开发主机通常是 x86_64。宿主机上的 gcc 生成的是 x86 指令，无法在 RK3588 上运行。因此需要一套“在 x86 上运行、生成 ARM64 代码”的交叉编译工具链。它由 binutils、gcc、glibc（或 musl）、gdb 等组成，核心是 aarch64-none-linux-gnu- 前缀。

交叉编译的难点不在编译器本身，而在“三套路径”的隔离：宿主机头文件、目标机 sysroot、目标机运行库。如果 sysroot 指向错误，会出现“编译通过、运行报 GLIBC 版本不符”的典型问题。因此工具链必须与 SDK 中 rootfs 的 libc 版本匹配。

关键原则：工具链、内核头文件、rootfs 三者必须来自同一 SDK 版本，混用是绝大多数“莫名段错误”的根源。

二、SDK 获取与编译流程

RK3588 官方 SDK 通常以 repo 多仓库方式管理，包含 u-boot、kernel、buildroot/debian、device/rockchip 等目录。获取后先看 device/rockchip/rk3588/ 下的配置文件，它决定了启动介质、rootfs 类型和分区布局。

# 1. 获取 SDK（示例）
repo init -u https://github.com/rockchip-linux/manifests -b master
repo sync -j8

# 2. 选择板级配置
./build.sh lunch
# 选择 rk3588_evb7_v11_defconfig 或自定义配置

# 3. 全量编译
./build.sh all

# 4. 单独编译 rootfs（buildroot 为例）
./build.sh buildroot

# 5. 打包固件
./build.sh firmware

编译产物集中在 rockdev/ 目录，典型文件包括 uboot.img、boot.img、rootfs.img、parameter.txt 和 update.img。其中 parameter.txt 定义了分区偏移，是烧录能否成功的关键。

三、串口与网络调试

串口是 RK3588 的“生命线”。即使系统无法启动，U-Boot 和内核日志仍会从调试串口输出。典型连接为 USB-TTL 转接板，TX/RX 交叉，GND 共地，波特率 1500000（部分板卡为 115200）。

# Linux 下使用 minicom
sudo minicom -D /dev/ttyUSB0 -b 1500000

# 或使用 picocom
sudo picocom -b 1500000 /dev/ttyUSB0

网络调试用于传输文件、挂载 NFS 和远程登录。推荐用网线直连或同一交换机，配置静态 IP 避免 DHCP 波动：

# 目标板设置静态 IP
ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up

# 宿主机挂载 NFS，便于快速替换 rootfs 文件
sudo mount -t nfs 192.168.1.10:/nfs/rootfs /mnt -o nolock

调试顺序建议：先串口确认 U-Boot 能进，再确认内核能挂载 rootfs，最后才用网络传文件。顺序颠倒会浪费大量时间。

四、烧录工具与镜像生成流程

RK3588 支持多种烧录方式：Windows 下用 RKDevTool，Linux 下用 upgrade_tool，量产可用 SD 卡或 USB 量产工具。烧录前需让板卡进入 MaskROM 或 Loader 模式。

工具/方式	适用场景	关键点
RKDevTool（Windows）	单板调试、分区烧录	需安装驱动，识别 Loader/MaskROM
upgrade_tool（Linux）	脚本化、CI 集成	命令行烧录 update.img 或分区
SD 卡启动	快速验证、不破坏 eMMC	需正确写 boot 与 rootfs 分区
USB 量产	批量生产	依赖 update.img 与配置

镜像生成的核心是“分区表 + 各分区镜像 + 打包”。parameter.txt 决定分区起止地址，update.img 则是把 uboot、boot、rootfs 等按规则打包成一个可整体烧录的文件。修改 rootfs 后，通常只需重新生成 rootfs.img 并单独烧录该分区，无需全量重烧。

# Linux 下烧录示例
sudo upgrade_tool ld          # 进入 Loader 模式
sudo upgrade_tool wl 0 rootfs.img   # 烧录 rootfs 到对应分区
sudo upgrade_tool rd          # 重启设备

五、案例与常见误区复盘

某项目在优化 rootfs 后出现“系统能启动但应用报 GLIBC_2.34 not found”。排查发现：应用是用宿主机自带 aarch64 工具链编译的，而 SDK rootfs 使用的是较旧 glibc。解决方法是改用 SDK 自带工具链，并显式指定 sysroot。

export CROSS_COMPILE=aarch64-none-linux-gnu-
export SYSROOT=$PWD/buildroot/output/rockchip_rk3588/host/aarch64-buildroot-linux-gnu/sysroot
$CROSS_COMPILE"gcc" --sysroot=$SYSROOT -o app app.c

常见误区还包括：串口波特率设错导致乱码；烧录时未进入 MaskROM 导致工具不识别；修改 parameter.txt 后未重新打包导致分区错位；NFS 挂载时未加 nolock 导致卡死。这些问题的共同点是“环境未闭环”，而非代码本身。

每次修改分区或 rootfs 后，务必先确认 parameter.txt 与镜像一致，再执行烧录；否则可能覆盖 U-Boot 导致板卡无法启动。

把上述四步串起来，就形成了“编译—调试—烧录—验证”的完整闭环。环境搭建的目标不是一次装好，而是让每次修改 rootfs 后都能在十分钟内完成重新打包、烧录和启动验证。只有闭环稳定，后续的 rootfs 裁剪、启动优化和体积压缩才有可靠的实验基础。