深入浅出 Buildroot：构建嵌入式 Linux 系统的利器

agicy2026/4/17大约 16 分钟

深入浅出 Buildroot：构建嵌入式 Linux 系统的利器

在嵌入式开发领域，构建一个完整的定制化 Linux 系统往往是一个繁琐且极具挑战的任务。我们需要准备交叉编译工具链、编译 U-Boot、编译 Linux 内核，并且还需要从零开始构建一个根文件系统（Root Filesystem）。

而在众多构建工具中，Buildroot 以其“简单、高效、基于 Makefile”的特点，成为了很多嵌入式工程师的必备利器。本文将带你了解什么是 Buildroot，它与 Yocto 等其他构建工具有何区别，以及如何使用它来快速构建你的专属嵌入式 Linux 系统。

1. 什么是 Buildroot？

Buildroot 是一个简单、高效且易于使用的自动化构建框架，专门用于生成嵌入式 Linux 系统的交叉编译工具链、根文件系统、内核镜像和 Bootloader。

它本质上是一大堆 Makefile 和 Kconfig 脚本的集合。如果你曾经编译过 Linux 内核，你会对它的配置界面（make menuconfig）感到非常熟悉。通过图形化菜单，你可以轻松选择你需要的软件包（例如 BusyBox、Nginx、Python、SSH 服务等），然后执行一个 make 命令，Buildroot 就会自动从源码下载、编译并打包出可以直接烧录到开发板上的系统镜像。

2. 为什么选择 Buildroot？

在嵌入式 Linux 系统构建中，常用的方式主要有三种：

纯手工构建：自己一步步下载、配置和编译 GCC 交叉工具链、U-Boot、Kernel 和 RootFS。这种方法虽然有助于学习底层知识，但在实际工程中效率极低，且难以维护和复用。
Yocto Project (OpenEmbedded)：业界极为强大的构建系统，功能全面，支持精细化的定制，但学习曲线极其陡峭，基于 Python 和 BitBake，构建速度相对较慢。
Buildroot：介于两者之间，简单直观。基于开发者熟悉的 Make 语法，学习成本低，编译速度快。

Buildroot 的核心优势：

极简主义：核心只有 Makefile，对于 C/C++ 开发者非常友好。
配置直观：使用 make menuconfig 即可完成对目标架构、工具链、内核、软件包的全部配置。
开箱即用：官方内置了对几百种常见开发板（如 Raspberry Pi, BeagleBone, STM32MP1 等）的默认配置文件（defconfig）。
庞大的软件库：原生支持超过 3000 个开源软件包，可以轻松引入各种第三方库。

3. Buildroot 的工作原理与架构

当你运行 Buildroot 时，它通常会按照以下顺序进行工作：

构建交叉编译工具链 (Toolchain)：
如果你没有提供外部工具链，Buildroot 会从头开始为你构建一套（包括 Binutils, GCC, Glibc/uClibc/musl）。
构建第三方软件包 (Packages)：
根据你在 menuconfig 中的选择，自动下载各个开源软件的源码，应用 Buildroot 提供的 Patch，然后使用前面生成的交叉编译器进行编译。
构建内核与 Bootloader (Kernel & Bootloader)：
如果配置了编译内核和 Bootloader，Buildroot 会同步完成编译。
生成根文件系统 (RootFS)：
将编译好的二进制文件、库文件和配置文件按照 Linux 根目录结构（/bin, /etc, /usr 等）进行组装，最后打包成常见的镜像格式（如 ext4, squashfs, tar）。

核心目录结构

在使用 Buildroot 时，你会经常与以下几个目录打交道：

board/：存放特定开发板的相关文件（如启动脚本、分区配置 genimage.cfg）。
configs/：存放各个开发板的默认配置文件（即 xxx_defconfig）。
package/：存放所有支持的软件包配置和编译规则（每个包通常包含 Config.in 和 xxx.mk）。
output/：所有的编译产物都在这里。
- output/build/：解压后的源码和编译过程目录。
- output/host/：存放交叉编译工具链和主机所需的工具。
- output/target/：根文件系统的“骨架”，但千万不要直接修改这里，因为每次 make 可能会被覆盖。
- output/images/：最终烧录所需的文件（如 zImage, rootfs.ext4, u-boot.bin, sdcard.img）。

4. 快速上手：构建一个系统

让我们来看一个简单的流程：

下载源码

git clone git://git.buildroot.net/buildroot
cd buildroot

应用默认配置
假设你要为树莓派 4（Raspberry Pi 4）64位版本构建系统，你可以直接应用官方预设的配置：
```
make raspberrypi4_64_defconfig
```
定制化配置 (可选)
打开图形化菜单，添加你想要的软件包（比如添加 openssh 和 htop）：
```
make menuconfig
```
在菜单中，你可以依次进入 Target packages -> Networking applications 勾选 openssh。
一键编译
```
make
```
注意：Buildroot 在编译过程中会自动从网络下载大量源码，所以请确保网络畅通。整个过程视电脑性能和网络速度，可能需要几十分钟到数小时不等。
获取镜像
编译完成后，进入 output/images/ 目录，你会看到一个 sdcard.img，直接将其用 dd 命令或工具（如 Rufus, BalenaEtcher）烧录到 SD 卡中，插入树莓派即可启动！

5. 实战：在系统中添加常用性能与压力测试工具

在嵌入式开发中，我们不仅要让系统跑起来，还需要对其进行严格的性能和稳定性评估。除了基础的工具外，我们还可以加入展示工具以及各种深度的压力测试工具。在 make menuconfig 中，你可以随时通过按下 / 键来快速搜索这些包的名字。

下面列出了一些最常用的系统展示与压力测试工具及其配置路径：

1. 系统信息展示工具：neofetch

neofetch 是一个非常受欢迎的命令行系统信息展示工具，能在终端里输出带有 ASCII Logo 的系统信息，极具极客范儿。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Shell and utilities  --->
        [*] neofetch

2. 网络性能与压力测试：iperf3

iperf3 是一个主动测量 IP 网络上最大可用带宽的工具，非常适合用于测试板载以太网或 Wi-Fi 的极限吞吐量。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Networking applications  --->
        [*] iperf3

3. 综合系统压力测试：stress-ng

stress-ng 是一个极其强大的系统压力测试工具，可以用于对 CPU、内存、I/O 以及操作系统各种子系统施加各种类型的混合压力，是进行严苛烤机测试的首选。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Debugging, profiling and benchmark  --->
        [*] stress-ng

4. 磁盘与 I/O 压力测试：fio

fio (Flexible I/O Tester) 是业界最权威的磁盘 I/O 性能与压力测试工具，常用于测试 eMMC、SD 卡或 NVMe 固态硬盘的读写极限和长时间高负载下的稳定性。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Debugging, profiling and benchmark  --->
        [*] fio

5. 内存压力与稳定性测试：memtester

memtester 是一个专门用于测试内存子系统是否存在故障的工具。在硬件刚打样回来的 Bring-up 阶段，用它来跑高强度的内存压力测试是必不可少的环节。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Debugging, profiling and benchmark  --->
        [*] memtester

6. 多线程与数据库级压测：sysbench

sysbench 是一个模块化的、跨平台的多线程基准测试工具，主要用于评估系统在极限高并发负载下的核心性能（如 CPU、内存、线程调度等）。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Debugging, profiling and benchmark  --->
        [*] sysbench

7. 实时性与调度延迟测试：cyclictest (rt-tests)

在工业控制或机器人领域，我们通常非常关注 Linux 系统的实时性。cyclictest 是测量 Linux 系统调度延迟的最权威工具。它包含在 rt-tests 软件包中。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Debugging, profiling and benchmark  --->
        [*] rt-tests
            [*]   cyclictest

当你勾选了这些选项后，保存退出并执行 make，Buildroot 就会自动去下载它们的源码、完成交叉编译，并将其放入你的 RootFS 镜像的 /usr/bin 等目录下。启动开发板后，你就可以愉快地在终端敲下 neofetch 查看酷炫的系统状态，并使用 stress-ng --cpu 4 或 fio 进行严苛的烤机测试了！

6. 进阶：配置初始化系统与常用网络传输工具

在真实的商业级嵌入式项目中，仅仅跑起系统和测试是不够的。我们通常还需要更强大的系统服务管理能力，以及方便开发和维护的远程网络传输工具。下面将介绍如何在 Buildroot 中进行相关配置。

1. 切换初始化系统为 systemd

Buildroot 默认使用 BusyBox 自带的轻量级 init 系统，这对于极简系统足够了。但如果你需要复杂的系统服务依赖管理、日志管理（journalctl），或者你的应用高度依赖现代 Linux 生态，切换到 systemd 是非常有必要的。

在 make menuconfig 中按如下路径配置：

System configuration  --->
    Init system (systemd)  --->
        (X) systemd

注意：启用 systemd 通常需要内核开启相关的 cgroups 等特性。如果使用的是 Buildroot 默认的内核配置，它通常会自动处理好依赖关系；如果使用自定义内核配置，请确保开启了 systemd 所需的内核选项。

⚠️ 重要提示：配置 journalctl 日志持久化
在嵌入式系统中，systemd-journald 默认会将日志写入 /run/log/journal/（这通常是一个挂载在内存中的 tmpfs）。这意味着一旦开发板断电重启，所有日志都会丢失！为了排查死机、Kernel Panic 等偶发问题，你需要开启日志持久化。

在 make menuconfig 中，进入 systemd 的详细配置项并开启持久化存储：

Target packages  --->
    System tools  --->
        [*] systemd  --->
            [*] enable persistent storage

勾选后，Buildroot 会在打包根文件系统时自动创建 /var/log/journal/ 目录，并将日志配置为掉电保存。

2. 开启常用远程网络与文件传输工具

在开发调试阶段，我们经常需要通过网络与开发板进行交互、传输固件或日志文件。以下是几款必备工具的开启方法：

OpenSSH (支持 ssh, scp, sftp)

openssh 提供了安全的远程登录（ssh）和文件拷贝（scp、sftp）功能，是嵌入式开发板的标配。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Networking applications  --->
        [*] openssh

提示：开启 openssh 后，系统启动时会自动生成密钥并启动 sshd 服务。你可以通过修改 RootFS Overlay 来预置免密登录的公钥。

rsync

rsync 是一个极其高效的文件同步工具。相比于每次全量拷贝的 scp，rsync 能够进行增量同步，在频繁修改和推送大量文件的开发场景中能极大节省时间。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Networking applications  --->
        [*] rsync

tftp (通过 BusyBox 开启)

tftp（Trivial File Transfer Protocol）常用于 Bootloader（如 U-Boot）阶段通过网络拉取内核和设备树镜像，也可以在 Linux 系统内用于快速的文件互传。通常，最简单的方式是直接利用 BusyBox 自带的 tftp 客户端/服务端。
在 make menuconfig 中按如下路径开启：

Target packages  --->
    Networking applications  --->
        [*] tftp-hpa
            [*] Enable tftp server

(注：如果不需要完整版的 tftp-hpa，BusyBox 的默认配置中通常已经包含了基础的 tftp 命令，可以直接在终端使用。)

3. 基础网络配置与 HTTP 下载工具 (ifconfig, curl, wget)

在调试阶段，让开发板连上网并从服务器拉取测试文件或固件是非常常见的操作。

ifconfig (由 BusyBox 提供)

对于基础的 IP 地址配置和网卡状态查看（如 ifconfig eth0 192.168.1.100），你通常不需要额外安装任何东西。因为 Buildroot 默认集成的 BusyBox 已经包含了轻量级的 ifconfig、ping 和 route 等命令。开机即用。

curl 与 wget (以及为什么需要 OpenSSL)

如果你需要从网上下载文件或者测试 RESTful API，curl 和 wget 是必不可少的。
⚠️ 避坑指南：HTTPS 支持
现在互联网上几乎所有的下载链接（如 GitHub Release、各种包管理器的源）都是 https:// 开头的。如果你的系统里没有加密库，curl 或 wget 遇到 HTTPS 链接时就会直接报错退出！
因此，在开启这两个工具时，我们强烈建议同时开启 OpenSSL 支持，赋予它们解析 TLS/SSL 加密流量的能力。

在 make menuconfig 中按如下路径配置：

Target packages  --->
    Networking applications  --->
        [*] curl
            [*] curl supports SSL (OpenSSL)  # 确保勾选以支持 HTTPS
        [*] wget
            [*] wget supports SSL (OpenSSL)  # 确保勾选以支持 HTTPS

提示：勾选 SSL 支持后，Buildroot 会自动将 openssl 或 mbedtls 库编译进系统，并让 curl/wget 链接到它们。这样你就可以愉快地在板子上执行 curl -O https://example.com/test.bin 了。

当你配置好 systemd 和这些强大的网络工具后，你的嵌入式 Linux 系统就具备了现代化的服务管理能力，并且可以通过网络进行极其高效的固件更新和远程调试了！

7. 进阶：如何将自己的配置文件放入系统 (RootFS Overlay)

在使用 Buildroot 时，一个最常见的痛点是：“我有一个自己写好的网络配置文件 /etc/network/interfaces，或者一个开机自启脚本 /etc/init.d/S99myapp，我该怎么把它放进最终的镜像里？”

千万不要去修改 Buildroot output/target/ 目录下的文件，因为每次执行 make clean 或者重新编译时，那个目录都会被清空覆盖！

正确的做法是使用 Buildroot 提供的 RootFS Overlay（根文件系统覆盖） 功能：

创建一个本地目录：在你的 Buildroot 源码外（或源码内新建一个目录），比如建立一个 board/my_board/rootfs_overlay/ 文件夹。
保持目录结构存放文件：在这个文件夹里，完全按照 Linux 根目录的结构放置你的文件。
例如，你想替换 /etc/hostname，就创建一个 board/my_board/rootfs_overlay/etc/hostname 文件，并在里面写上你想要的主机名。

在 Buildroot 中指定该目录：
打开 make menuconfig，配置如下：

System configuration  --->
    Root filesystem overlay directories
        (board/my_board/rootfs_overlay)  # 填入你刚才创建的目录路径

配置好后，当你再次执行 make 打包生成镜像时，Buildroot 会在最后一步，把这个 rootfs_overlay 目录里的所有文件直接“盖”到生成的 RootFS 上。如果有同名文件（比如覆盖了系统默认的配置），你的文件优先级最高。这是实现系统高度定制化最优雅、最推荐的方式。

8. 答疑：烧录后还能在运行时修改配置吗？

很多初学者在使用 Buildroot 烧录系统后，会尝试像在 Ubuntu 上一样，使用 vi 直接修改板子上的 /etc/network/interfaces（网络接口）或者 /etc/resolv.conf（DNS），然后发现重启后修改全都丢失了，甚至有时连修改都提示 Read-only file system（只读文件系统）。

能不能在运行时修改配置，完全取决于你在 Buildroot 中是如何配置根文件系统（RootFS）属性的：

模式一：只读根文件系统 (Read-only RootFS) - 商业产品的默认选择

在工业或物联网设备中，为了防止突然掉电导致文件系统损坏，通常会将整个 / 挂载为只读。此时，/etc 目录下需要动态修改的文件（如 DNS 配置 resolv.conf），通常会被 Buildroot 自动软链接（symlink）到 /tmp 或 /run 目录下。

现象：这些目录是存在于内存中的（tmpfs），你可以修改它们，但断电重启后修改就会丢失。

如何开启/关闭：在 make menuconfig 中：

System configuration  --->
    [*] remount root filesystem read-only during boot  # 默认通常开启

模式二：可写根文件系统 (Read-Write) - 开发调试阶段的首选

如果在开发阶段，你需要频繁地在板子上动态修改配置（比如调整 systemd 服务、修改 IP 地址），你需要关闭只读模式，并且确保你选择的根文件系统格式是支持写入的（比如 ext4，而不是只读的压缩格式 squashfs）。

现象：关闭只读模式后，只要文件系统是 ext4，你在板子上通过 vi /etc/network/interfaces 所做的任何修改，都会直接写入 Flash/SD 卡，断电重启后依然生效。

⚠️ 补充：关于 Direct I/O (O_DIRECT) 的特别说明

如果你在编写高性能存储应用，或者使用之前我们添加的 fio 进行严苛的磁盘压力测试（使用了 direct=1 或代码中使用了 open(..., O_DIRECT) 标志），你必须特别注意文件系统格式：

不能在只读模式的动态目录（如 /tmp 或 /run）下测试：因为这些目录通常挂载为内存盘 tmpfs，tmpfs 不支持 O_DIRECT，调用会直接报错 EINVAL。
不能在只读压缩格式（如 squashfs）下测试：这类格式专为只读设计，不仅无法写入，也无法绕过 Page Cache 进行块级直写。
正确做法：如果要使用 O_DIRECT，你需要一个基于真实块设备的常规文件系统（如 ext4 或 xfs），并且需要满足严格的内存和磁盘扇区对齐要求。

⚠️ 最佳实践建议

尽管你可以在可写模式（模式二）下直接修改板子上的配置并运行 O_DIRECT 测试，但这强烈不推荐作为最终的商业量产方案。因为一旦你重新执行 make 并烧录新镜像，你之前在板子上辛苦修改的所有配置就又被覆盖了。

工业级商业产品的真正标准流程应该是：

根文件系统（RootFS）保持模式一（只读的 squashfs），确保系统本身抗掉电、防篡改。
在板子的 Flash 或 eMMC 上单独划分一个数据分区（Data Partition），格式化为 ext4 并挂载到 /data 或 /mnt/data 目录。
你的应用程序日志、动态配置文件以及所有需要使用 O_DIRECT 的高性能数据库/存储业务，全部运行在 /data 分区上。
系统的初始静态配置，则拉回 PC，放入上一节提到的 RootFS Overlay 目录中，重新 make 打包。

9. 进阶：如何添加自己的程序？

Buildroot 的一大魅力就是可以轻松添加自己的应用。你只需要在 package/ 目录下创建一个新目录（例如 package/my_app/），并在其中添加两个文件：

Config.in：用于在 make menuconfig 中显示选项。
my_app.mk：编写基于 Make 语法的下载和编译规则。

然后在 package/Config.in 中引用你的 my_app/Config.in 即可。

总结

Buildroot 是一个非常优雅的嵌入式构建系统，它用最传统的 Makefile 语法，解决了最复杂的系统定制问题。如果你的项目不需要像 Yocto 那样极致的包管理（Package Management，比如在板子上使用 apt-get），而仅仅需要一个高度定制、体积小巧、可复现的固件，那么 Buildroot 绝对是你的首选。