跳到主要内容

建立 Avaota A1 的 Buildroot 板级配置

U-Boot 命令行出现后,还需要准备三个彼此配套的文件:Linux Image、Avaota A1 DTB,以及包含 /sbin/init 的根文件系统。分别构建这些文件并不困难,真正需要解决的是如何固定版本、工具链和输出路径,让它们能够重复生成并共同组成同一套系统。

Buildroot 负责保存这套构建关系:它在主机上选择交叉工具链,调用指定的 Linux 源码,制作用户空间,再把板级文件输出到 output/images/。TF-A 和 U-Boot 仍由各自工程构建;生成整盘镜像时,Buildroot 的镜像脚本再使用它们的产物。

创建 Avaota A1 板级目录

进入 mainline-a1/buildroot-2026.05.1

mkdir -p board/avaota/a1-mainline/rootfs-overlay/boot/extlinux
mkdir -p board/avaota/a1-mainline/rootfs-overlay/etc/init.d

本阶段最终形成的文件关系如下:

buildroot-2026.05.1/
├── configs/
│ └── avaota_a1_mainline_defconfig
├── board/avaota/a1-mainline/
│ ├── linux.fragment
│ ├── genimage.cfg
│ ├── post-build.sh
│ └── rootfs-overlay/
└── local.mk

configs/ 中的 defconfig 决定 Buildroot 选择什么;board/ 保存本板附加文件;local.mk 把 Linux 包指向同级源码工作树。

这三个位置的生命周期不同:

文件谁读取是否应进入发布补丁作用
configs/avaota_a1_mainline_defconfigBuildroot 配置系统保存可复现的最小选择
board/avaota/a1-mainline/Buildroot 各构建钩子保存板级文件、脚本和镜像规则
local.mk本地开发构建通常单独说明把某个包替换为正在修改的源码树

.config 是 defconfig 展开依赖后的完整结果,不适合手工长期维护;make savedefconfig 才会把有效选择压缩回可提交的 defconfig。

配置目标架构与交叉工具链

创建 configs/avaota_a1_mainline_defconfig,先写入:

BR2_aarch64=y
BR2_cortex_a55=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y
BR2_TOOLCHAIN_EXTERNAL_PATH="$(TOPDIR)/../../../out/toolchain/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="aarch64-none-linux-gnu"
BR2_TOOLCHAIN_EXTERNAL_GCC_10=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_20=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y

路径从 Buildroot 的 TOPDIR 计算到 Tina5 SDK 的 out/toolchain/,不包含用户名或主机绝对路径。先让 Buildroot 展开配置:

外部工具链配置不只是找到一个 gcc。Buildroot 还要知道目标架构、CPU、libc、C++ 支持和内核头版本,才能判断软件包依赖并生成与工具链 ABI 一致的用户空间。BR2_cortex_a55 影响编译优化,CUSTOM_GLIBC 和 headers 版本则影响程序可使用的系统调用与动态链接器。工具链路径正确但这些声明错误时,配置阶段可能通过,运行时仍会出现解释器缺失或符号版本不匹配。

make avaota_a1_mainline_defconfig
grep -E '^BR2_(aarch64|cortex_a55|TOOLCHAIN_EXTERNAL_PATH)=' .config

配置 Linux 源码与板级文件

继续在 defconfig 中加入:

BR2_TARGET_GENERIC_HOSTNAME="avaota-a1"
BR2_TARGET_GENERIC_ISSUE="Avaota A1 mainline Linux / Buildroot 2026.05.1"
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_SYSTEM_DHCP="eth0,eth1"
BR2_ROOTFS_OVERLAY="board/avaota/a1-mainline/rootfs-overlay"
BR2_ROOTFS_POST_BUILD_SCRIPT="board/avaota/a1-mainline/post-build.sh"
BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/avaota/a1-mainline/genimage.cfg"

BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="7.2"
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/avaota/a1-mainline/linux.fragment"
BR2_LINUX_KERNEL_IMAGE=y
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="allwinner/sun55i-t527-avaota-a1"

创建 local.mk

LINUX_OVERRIDE_SRCDIR = $(TOPDIR)/../linux-v7.2

Buildroot 仍把 Linux 当作受管理的软件包,但取源码时使用 mainline-a1/linux-v7.2。这样设备树修改和内核提交可以用原 Linux Git 工作树检查。

LINUX_OVERRIDE_SRCDIR 只改变 Linux 包的源码来源,不改变 Buildroot 记录的 Linux 配置、补丁阶段和输出目录。Buildroot 会把构建结果放入 output/build/linux-custom/;修改同级 linux-v7.2 后,需要执行 make linux-rebuild 或完整构建,不能在源码树中直接 make 后假设 Buildroot 已吸收新产物。

发布构建若不再依赖旁边的工作树,可以把补丁和固定版本纳入板级配置,从而去掉 local.mk。换一台机器时,最需要重新核对的是 override 路径和实际 Git 提交,而不是复制旧的 output/build

配置 ext4 根文件系统

在 defconfig 末尾加入:

BR2_PACKAGE_HOST_GENIMAGE=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="512M"
BR2_TARGET_ROOTFS_EXT2_LABEL="rootfs"
# BR2_TARGET_ROOTFS_TAR is not set

Buildroot 的选项名称仍叫 EXT2BR2_TARGET_ROOTFS_EXT2_4=y 会生成 ext4 特性的文件系统;产物文件名仍是 rootfs.ext2。extlinux 参数使用 root=LABEL=rootfs,因此这个卷标同时承担早期根设备定位,必须与 BR2_TARGET_ROOTFS_EXT2_LABEL="rootfs" 保持一致。

选择 ext4 而不是 tar 包,是因为 genimage 需要把一个已经格式化、可直接挂载的分区镜像放入整盘 raw。512 MiB 同时是文件系统容量和磁盘布局输入;增加软件包导致空间不足时,既要扩大这里,也要调整 genimage 中 rootfs 后的整盘尺寸。

重新展开配置并保存最小结果:

make avaota_a1_mainline_defconfig
make savedefconfig BR2_DEFCONFIG=configs/avaota_a1_mainline_defconfig
test -s .config

完成标志不是开始编译,而是 .config 中同时出现 AArch64 工具链、Linux 7.2、Avaota A1 DTB、rootfs overlay 和 genimage 脚本入口。

若更换 Linux 版本,需同时检查 Buildroot 的版本选择、LINUX_OVERRIDE_SRCDIR、配置片段兼容性和模块目录;若只更换 rootfs 软件包,则不应顺手重做 U-Boot。Buildroot 的价值就在于把这些输入关系显式化,而不是让一个大脚本无差别重编所有组件。

继续:配置主线 Linux