嵌入式 Linux 交付的不只是一个可执行文件，还包括交叉工具链、Bootloader、内核、设备树、根文件系统、库、服务和烧录布局。Buildroot 用一份配置和依赖关系把它们放到同一次构建里：选好目标架构和软件包后，它会下载源码、交叉编译、安装到 rootfs，并生成镜像。这样换一台机器也能按同样的输入重建系统。

选择 defconfig→锁定工具链与软件版本→构建 U-Boot/Kernel/Packages→生成 rootfs 与镜像→烧录并进行启动测试

Buildroot 负责哪些层

它可以构建内部/外部工具链、U-Boot、Linux 内核、BusyBox、图形栈、应用包和各种 rootfs 格式。配置最终收敛到 .config，但不应直接手工维护一份巨大的 .config；通常从板级 defconfig 开始，使用 savedefconfig 保存最小差异，借助版本控制记录变更。

镜像图Buildroot 把工具链、启动链、根文件系统和业务包放进一份可复现的构建图。
defconfig最小可复现配置入口，描述目标板/产品的构建选择toolchain编译器、C 库、sysroot 与 ABI，决定所有用户态二进制兼容性kernel/U-Boot各自独立配置和源码版本，但由同一构建图协调rootfs overlay放目标文件、配置与脚本，不直接污染 Buildroot 源树package将自定义应用描述为可依赖、可安装、可重建的包images最终输出 dtb、kernel、rootfs、boot 镜像及清单/哈希

自定义内容要放在外部树

将产品专属内容放进 br2-external：板级 defconfig、overlay、post-build 脚本、补丁和自定义 package 都可独立于 Buildroot 主源码管理。这样升级 Buildroot 时，能清楚区分上游变化与自己的产品变化，也避免直接修改 output 或下载目录导致“这台机器能编、另一台不能编”。

1
2
3
4
make menuconfig
make savedefconfig
make BR2_EXTERNAL=/path/to/br2-external <board>_defconfig
make

命令只是典型工作流。生产项目还应固定 Buildroot commit、外部源码 revision、下载镜像哈希和构建容器/宿主机版本，避免上游 URL、编译器或 locale 变化悄悄改变产物。

rootfs overlay、post-build 与 package 如何分工

静态配置文件、systemd/SysV 启动脚本和少量目标文件适合 overlay；需要按构建结果修改 rootfs 的操作适合 post-build/post-image 脚本；需要交叉编译、有依赖、有 license 信息的应用应做成 package。把一个复杂应用塞进 post-build 脚本，看似省事，后续会失去依赖、重建和缓存管理。

1
2
3
配置文件/启动脚本 -> overlay
镜像签名/分区组装   -> post-image
可编译的业务软件     -> Buildroot package

镜像成功不等于产品成功

构建完成后要验证至少四类事情：启动链能否加载正确 kernel/DTB/rootfs；用户态 ABI 是否与目标匹配；关键服务是否在预期时间启动；镜像、配置和开源许可证清单是否可以追溯。对 OTA 或量产，还要验证分区布局、回滚、掉电恢复和版本兼容。

Buildroot 能把手工凑出来的板端系统变成可重复构建的镜像。产品差异越早放进外部树和 package，后面升级内核、工具链和业务软件时越好维护。

参考：Buildroot Manual · br2-external