一、概述
Buildroot 为每个包支持自定义 patch：把 NNNN-描述.patch 文件放进包的目录（package/<包名>/），Buildroot 会在解压源码之后、配置之前自动按文件名序号依次应用。
以 bluez5_utils 为例，它的 patch 在：
buildroot/package/bluez5_utils/├── 0001-gdbus-define-MAX_INPUT-for-musl.patch├── 0002-Leave-config-files-writable-for-owner.patch├── 0003-input-fix-HID-compilation-w-o-HoG.patch├── 0004-input-fix-HoG-compilation-w-o-HID.patch├── 0005-bluez-modified-only-for-rockchip.patch├── Config.in├── S40bluetoothd├── bluez5_utils.hash└── bluez5_utils.mk
二、核心机制
2.1 patch 从哪些目录找
package/pkg-utils.mk 里的 pkg-patch-hash-dirs：
pkg-patch-hash-dirs = \ $($(1)_PKGDIR) $(addsuffix /$($(1)_RAWNAME),$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)))
两个来源：
- 包目录本身
package/<包名>/（最常用，我们看到的 5 个 patch 就在这） BR2_GLOBAL_PATCH_DIR 指定的全局 patch 目录（板级/产品级共享补丁，通常可选）
收集所有 patch 文件（pkg-patches-list）：
pkg-patches-list = $(foreach patchdir,$(call pkg-patches-dirs,$(1)),\ $(wildcard $(addsuffix /*.patch,$(patchdir))))
即：把所有 patch 目录下的 *.patch 通配收集。
2.2 什么时候应用（构建流程分阶段）
package/pkg-generic.mk 的.stamp_patched阶段：
$(BUILD_DIR)/%/.stamp_patched: $(Q)$(APPLY_PATCHES) $(@D)# 初始化 git 仓库 $(foreach p,$($(PKG)_PATCH),$(APPLY_PATCHES) $(@D) $($(PKG)_DL_DIR) $(notdir $(p))$(sep)) $(foreach dir,$(call pkg-patches-dirs,$(PKG)),\ $(Q)$(APPLY_PATCHES) $(@D) $(dir) \*.patch$(sep)\# 核心：应用所有 patch ) $(Q)touch $@
Buildroot 用stamp 文件管理每个包的生命周期，顺序是：
解压(.stamp_extracted) → 打补丁(.stamp_patched) ← patch 在这里应用 → 配置(.stamp_configured) → 编译(.stamp_built) → 安装到 staging(.stamp_staging_installed) → 安装到 target(.stamp_target_installed) ← 进固件的是 target 里装的 → 打包固件(images/)
关键点：patch 只在 .stamp_patched 阶段跑一次，之后不再重复。
2.3 具体怎么打（apply-patches.sh）
用 support/scripts/apply-patches.sh，核心逻辑：
# 对每个 *.patch：patch -p1 --batch -s -d ”$builddir” -i ”$patch”
- 按文件名排序顺序应用：
0001 → 0002 → ... → 0005（序号决定顺序） - 目标目录是解压后的源码树
build/<包名>-<版本>/
三、构建产物各位置（为什么烧了固件还是旧的）
要理解"改了代码固件却没生效"，必须分清三个目录：
| | |
|---|
package/bluez5_utils/0005-*.patch | | |
output/.../build/bluez5_utils-5.79/ | | |
output/.../target/usr/libexec/bluetooth/bluetoothd | | |
典型坑：只改 build/.../src/device.c 并 make，只会更新 build 目录的二进制，.stamp_patched/.stamp_built 都没失效，buildroot 认为包"没变"，重新打包时不会重新打补丁/编译，target 里还是旧文件 →固件就是旧的。
实际案例：RK3572 蓝牙 Connect 签名修复中，build 目录 bluetoothd 已是新版（2101024B，无 ADDR_TYPE），
但 target 里仍是旧版（1643808B，含 ADDR_TYPE），烧进固件后板子报错依旧。
详见 rk3572-bluetooth-connect-unknownmethod-fix.md。
四、修改 patch 后的正确操作
4.1 强制重新走全流程
cd /home/user/rk3572_0728/sdk/buildroot# 删掉 build 目录（连同所有 stamp），强制重新解压→打补丁→配置→编译→安装make bluez5_utils-dircleanmake bluez5_utils
dirclean 会删掉 build/bluez5_utils-5.79/ 整个目录，
下次 make bluez5_utils 重新解压并用新 patch 打补丁、重新编译、重新安装到 target。
4.2 验证 target 是否已更新
OUT=output/rockchip_rk3572_customer_v10_spi_nand_ab/rockchip_rk3572_customer_spi_nand_ab# 确认 build 与 target 都是新版（以蓝牙为例：新版无 ADDR_TYPE 字符串）grep -ac ADDR_TYPE $OUT/build/bluez5_utils-5.79/src/bluetoothd# 应为 0grep -ac ADDR_TYPE $OUT/target/usr/libexec/bluetooth/bluetoothd# 应为 0
两个都为 0，才说明固件会带上新代码。
4.3 各 make 目标的区别
| | |
|---|
make bluez5_utils-dirclean | | |
make bluez5_utils | | |
make bluez5_utils-rebuild | | |
make bluez5_utils-reinstall | | |
五、改 patch 文件的注意事项
5.1 推荐：用 git 重建 patch
手动编辑 patch 的 hunk 行号（@@ -x,y +x2,y2 @@）极易出错——后面几十个 hunk 都要重算。推荐用 git 重建法：
# 1. 准备上游源码并初始化 gittar -xf dl/<包>-<版本>.tar.xz -C /tmp/workcd /tmp/work/<包>-<版本> && git init && git add -A && git commit -qm base# 2. 先按顺序应用前面的 patch（0001~0004），commit 一次# 这样新 patch 的旧文件基准 = 前面 patch 应用后的状态for f in 0001-*.patch 0002-*.patch 0003-*.patch 0004-*.patch; do git apply ”$BR/package/<包>/$f”donegit add -A && git commit -qm ”patches 1-4”# 3. 修改源码（如 src/device.c），用 git format-patch 生成新 patchgit format-patch -1 HEAD --stdout > /tmp/<包>-0005-new.patch# 4. 保留原作者 header（From/Date/Subject），写回包目录
好处：hunk 行号由 git 自动计算，patch 干净可应用。
5.2 验证 patch 能干净应用
# 在干净上游上：按顺序应用 0001~0004 + 新0005，确认成功cd /tmp/verifytar -xf dl/<包>-<版本>.tar.xzfor f in 0001 0002 0003 0004; do patch -p1 --dry-run < ”$BR/package/<包>/$f-*.patch” && patch -p1 < ...donepatch -p1 --dry-run < /tmp/<包>-0005-new.patch && echo ”OK”
5.3 改 patch 源 vs 改 build 目录
| | |
|---|
package/<包>/NNNN-*.patch | | |
build/<包>-<版本>/src/xxx.c | 临时验证，make <pkg>-dirclean 会被冲掉 | |
六、FAQ
Q1: 改了 patch 文件，为什么重新 make 还是旧的？
因为 .stamp_patched 没失效，buildroot 不会重打补丁。需要 make -dirclean 清掉 build 目录。
Q2: 多个 patch 按什么顺序应用？
按文件名排序：0001 < 0002 < ... < 0005。序号前缀就是顺序控制。
Q3: 想在板级再叠加 patch 怎么办？
用 BR2_GLOBAL_PATCH_DIR 指向全局 patch 目录，放同名包的 patch 即可（优先级：包目录先，全局目录后）。
Q4: 如何确认某个包打了哪些 patch？
看构建日志或：
grep -E 'Applying|Patching|\.patch' output/.../build/<包>-<版本>/.git 2>/dev/null# 或直接看 build 目录源码是否包含 patch 的改动
附：常用路径速查（bluez5_utils 示例）
| |
|---|
| buildroot/package/bluez5_utils/*.patch |
| buildroot/output/<板级>/build/bluez5_utils-5.79/ |
| buildroot/output/<板级>/build/bluez5_utils-5.79/src/bluetoothd |
| buildroot/output/<板级>/target/usr/libexec/bluetooth/bluetoothd |
| buildroot/output/<板级>/images/rootfs.* |
| buildroot/support/scripts/apply-patches.sh |
10个月宝宝每天需要喝多少奶粉？