4. 环境搭建与工具链准备

RK3568文件系统优化与Buildroot裁剪工作，本质上是在一个受控的交叉编译环境中，将目标系统所需的软件包、库文件、配置脚本和内核模块，按照预定义的规则组合成可烧录的根文件系统镜像。环境搭建的质量直接决定了后续裁剪工作的效率与可重复性。一个混乱的宿主环境，往往会导致编译错误、依赖冲突甚至最终镜像无法启动。本章将系统讲解从零搭建RK3568开发环境的核心步骤，包括Buildroot依赖安装、SDK获取、交叉编译工具链配置以及构建环境的完整验证流程。

4.1 宿主系统要求与Buildroot依赖安装

核心原理：Buildroot本身是一个基于Makefile和Kconfig的构建系统，它会在宿主机上执行编译、打包、符号链接等操作，然后生成目标平台（ARM64）的可执行文件。因此，宿主机的软件包版本、Python解释器、Perl模块以及编译工具链的版本，都会直接影响构建过程的稳定性。RK3568 SDK通常基于Ubuntu 20.04或22.04 LTS进行验证，使用更新的发行版（如Ubuntu 24.04）时，可能会遇到GCC版本过高导致的兼容性问题。

操作流程：首先确认宿主系统版本，然后安装Buildroot所需的全部依赖包。以下命令适用于Ubuntu 20.04/22.04：

# 检查系统版本
cat /etc/os-release

# 更新软件源
sudo apt update

# 安装Buildroot核心依赖
sudo apt install -y git wget cpio unzip rsync bc \
    build-essential gcc-multilib libncurses5-dev \
    libssl-dev python3 python3-pip python3-distutils \
    file tree lzop libelf-dev

# 安装repo工具（用于管理多仓库SDK）
sudo apt install -y repo

# 安装其他常用工具
sudo apt install -y dosfstools mtools mtd-utils \
    device-tree-compiler u-boot-tools

4.2 RK3568 SDK下载与分支选择

核心原理：RK3568 SDK由Rockchip官方维护，采用repo工具管理多个Git仓库，包括内核（kernel）、U-Boot、Buildroot、Rockerchip平台脚本以及各种驱动和固件。SDK的完整性和分支一致性是后续构建成功的前提。如果直接使用git clone拉取单个仓库，会缺少必要的子模块和预编译二进制文件。

操作流程：推荐使用Rockchip官方提供的repo初始化脚本。以下以国内用户常用的镜像源为例：

# 创建SDK工作目录
mkdir -p ~/rk3568_sdk && cd ~/rk3568_sdk

# 初始化repo仓库（使用Rockchip官方manifest）
repo init -u https://gitlab.com/firefly-linux/manifests.git -b master

# 或者使用Rockchip官方源（需VPN）
# repo init -u https://github.com/rockchip-linux/manifests.git -b master

# 同步全部仓库（耗时较长，约30-60分钟）
repo sync -j8 -c

# 切换内核分支（RK3568默认使用linux-5.10）
cd kernel
git checkout linux-5.10
cd ..

案例拆解：某团队在拉取SDK时，直接使用git clone --depth 1克隆了buildroot仓库，但忽略了device/rockchip目录下的板级配置。结果在执行make rockchip_rk3568_defconfig时，提示找不到board/rockchip/rk3568目录。这是因为SDK的板级配置、内核补丁和U-Boot配置分散在多个仓库中，必须通过repo sync完整拉取。正确的做法是始终使用repo工具，并确保repo sync无报错。

4.3 交叉编译工具链配置

核心原理：交叉编译工具链是连接宿主机与目标板的桥梁。RK3568 SDK默认使用aarch64-linux-gnu-前缀的GCC工具链，该工具链可以在宿主机上编译出ARM64架构的可执行文件。SDK中通常已经预置了工具链路径，但需要手动将其加入PATH环境变量，并确保sysroot指向正确的库目录。

操作流程：SDK中通常包含预编译工具链，路径为prebuilts/gcc/linux-x86/aarch64/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/。配置环境变量如下：

# 编辑用户环境变量
vim ~/.bashrc

# 在文件末尾添加以下内容
export PATH=$PATH:~/rk3568_sdk/prebuilts/gcc/linux-x86/aarch64/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin
export ARCH=arm64
export CROSS_COMPILE=aarch64-none-linux-gnu-

# 使环境变量生效
source ~/.bashrc

# 验证工具链
aarch64-none-linux-gnu-gcc -v

4.4 构建环境验证与最小系统编译

核心原理：环境验证的目的是在正式裁剪之前，确认工具链、SDK、依赖包三者之间能够协同工作。最有效的方式是执行一次最小化的Buildroot构建，生成一个基础的根文件系统镜像。这个过程会调用交叉编译器、下载源码包、执行配置和编译，能够暴露绝大多数环境问题。

操作流程：进入Buildroot目录，选择RK3568的默认配置，然后执行构建：

cd ~/rk3568_sdk/buildroot

# 加载RK3568默认配置
make rockchip_rk3568_defconfig

# 执行构建（首次构建约需30-60分钟，取决于网络和CPU）
make -j$(nproc)

# 检查构建产物
ls -lh output/images/
# 应至少看到 rootfs.ext2、rootfs.ext4 或 rootfs.squashfs

案例拆解：某工程师在验证环境时，执行make后立即报错：/bin/bash: line 1: bison: command not found。这是因为Buildroot在编译U-Boot时需要bison和flex。虽然build-essential已安装，但bison并不包含在内。解决方法是补装依赖：sudo apt install -y bison flex。另一个常见问题是make: *** [output/build/host-gcc-final/.stamp_built] Error 1，这通常是由于宿主机的GCC版本过新（如GCC 13）导致host-gcc编译失败，此时需要手动指定使用SDK自带的GCC作为宿主GCC，或者降级宿主机GCC。

4.5 常见误区与总结复盘

误区一：使用root用户直接构建。Buildroot官方明确不建议在root用户下执行构建，因为某些软件包的编译脚本在检测到root权限时会改变行为，导致生成的文件属主异常。正确做法是使用普通用户，并将SDK目录属主改为该用户。

误区二：忽略磁盘空间。Buildroot在构建过程中会下载大量源码包（约2-3GB），并生成中间产物（约10-20GB）。如果/home分区空间不足，构建会在解压或编译阶段报错No space left on device。建议预留至少100GB空间。

误区三：修改.config后直接构建。在裁剪过程中，如果手动修改了.config文件，必须执行make olddefconfig来同步依赖关系，否则可能出现Kconfig依赖不一致导致的编译错误。