把厂商 BSP 整理进 Buildroot LTS：BR2_EXTERNAL、板级补丁与构建基线

作者LIU, ZHUOHUI

厂商 BSP 中经常混着板级支持、版本专用改动、开发机工具以及直接复制到 output 的文件。整理到 Buildroot LTS 时，需要把这些隐含输入还原为能追踪的工程内容。本文以 Buildroot 2025.02.18 为固定参考，说明如何建立外部树与迁移基线。目录和构建入口是结构示意，没有提供可直接烧录的板级配置，也没有宣称已经完成目标板构建。

先恢复输入，再迁移构建
原创工程流程示意，不代表实测结果。点击图片可查看原尺寸图解。

冻结可工作的旧构建和输入

整理前先归档可工作的厂商树，保存真实发布命令、Buildroot 有效配置、内核与 bootloader 配置、补丁、下载输入及镜像校验值，构建主机环境另行登记。原 output 留作调查副本，避免一开始就删除唯一保存了手工修改的线索。

逐项比较生成目录和受控输入：staging 下改过的头文件、target 中手工复制的应用、个人脚本生成的二进制，在新工程中都需要明确生产者。来源无法恢复的项目先记为阻塞项。把未知文件直接放进 overlay 只能移动问题，不能补齐来源。旧镜像还应保留用于后续行为对照和恢复设计。

定义外部树中的板与产品边界

使用有明确名称的外部树存放产品自有内容。固定版本的外部树说明规定了入口文件；board、package 和 configs 则分别表达板级文件、包配方和产品配置。是否为不同板修订拆分 defconfig，要由真实差异决定。

product-bsp/
  external.desc        # name: PRODUCT
  Config.in
  external.mk
  configs/product_a_defconfig
  board/product/a/
    linux.config
    rootfs-overlay/
    patches/
    post-image.sh
  package/telemetry/

树名为 PRODUCT 时，可通过 BR2_EXTERNAL_PRODUCT_PATH 引用路径。external.mk 可使用排序后的 package/*/*.mk 通配包含。目录隔离便于审查，但不会形成权限隔离，也不会自动禁止脚本访问开发者的其他目录。

迁移配置而不照搬旧 config

先从出货需求恢复架构、工具链能力、init 系统、包集合、内核来源、启动程序和镜像格式，再阅读目标版本迁移说明及 Legacy 选项。通过新版本配置系统处理改名或删除的符号，比较实际配置是否仍覆盖原需求，不能以“保存成功”作为迁移完成标志。

Buildroot、Linux、U-Boot 配置分别保存，并同时保留精简 defconfig 与本轮构建的有效配置。这样才能区分主动选择和默认值变化。对每个消失的选项，说明替代项或删除原因；认证、文件系统和网络功能尤其容易在串口首次启动时没有被发现缺失。配置审查还应覆盖不同产品变体。

旧工程发现 迁移位置或处理 必须复核
板级配置和 DTS 修改 board/产品/修订及配置文件 基线、变体范围、硬件假设
自有应用配方 package/包名 来源、许可证、依赖、安装
output/target 中手改文件 overlay 或包安装规则 来源、权限、被覆盖默认值
私有镜像生成命令 受控 post-image 脚本 输入、工具版本、分区影响
来源不明二进制或主机工具 阻塞清单 责任人、来源、分发及替代方案

给补丁建立来源和应用顺序

内核、bootloader 和用户态补丁分层保存，各自关联确切基线。文件名使用稳定排序，并建立包含用途、来源、上游状态和影响板型的索引。按该版本支持的机制配置项目补丁，避免配置结束后又由隐藏脚本追加修改。

从全新解压的源码重放补丁，检查警告和上下文，再复核修改的语义。无法应用的补丁可能已有上游实现，仍能应用的补丁也可能重复甚至抵触新实现。保留、改写或移除都应记录依据。官方补丁策略说明应用行为，产品补丁索引则要回答每项私有修改为什么仍然必要。

迁移 overlay 和镜像生成步骤

配置文件放入受控 overlay，生成结果不要混进去。每个覆盖文件都应与新包默认文件对照：旧服务脚本可能漏掉安全修复，也可能依赖新镜像不再创建的目录。用户、组、权限及可写目录要显式表达，从旧 target 复制文件并不能还原全部文件系统策略。

检查 post-build、post-image 的硬编码路径、环境变量、工作目录及旧 SDK 工具依赖。镜像生成需记录分区和启动参数基线。通用源码与示例 overlay 不应携带设备身份或凭据，相关内容走产品授权的烧录流程。涉及持久分区或启动顺序的改动，应直接生成系统验收任务。

在独立输出目录完成迁移构建

选取固定源码、已登记主机环境和全新且唯一的输出目录。下面仅示意真实外部树和板配置准备完成后的构建入口，不能当作完整构建或 CI 通过记录。

BR=/work/buildroot-2025.02.18
EXT=/work/product-bsp
OUT=/work/out/product-a-trial-001
make -C "$BR" O="$OUT" BR2_EXTERNAL="$EXT" product_a_defconfig
make -C "$BR" O="$OUT" BR2_EXTERNAL="$EXT" V=1

不要复制旧 host、staging 或 target 来消除失败。日志需关联下载源、补丁和工具链。独立目录构建成功只能支持输入完整性的判断，字节级可复现仍需另行对照验证。若是单包失败，按干净构建依赖排查缩小问题。

提交可接手的迁移差异包

移交包应包含外部树、源码标识、构建入口、补丁索引、配置差异和未解决项，并说明旧文件哪些迁移、替换或删除。实际执行后再收录日志及镜像校验值；另一名工程师应无需访问原开发者主目录，就能识别全部必要输入。

构建完成和首次启动是阶段门槛，发布判断还要经过外设、升级与恢复验收，并保持迁移规划批准的边界。涉及设备树时，可参考设备树审查文章（英文）连接源码变化与真实外设。交接最后一页应明确哪些测试尚未完成，避免接手者误把待验证项当作通过项。

资料与版本边界

示例用于说明固定版本下的工程方法；本文未执行实板验收、完整交叉构建、性能基准或现场部署，不将示意内容作为通过证据。

需要明确 BSP 维护或构建审查范围时，可向Obeita 提供基础材料：旧工程结构和构建说明, 目标板变体, 私有补丁规模, 当前无法复建的日志。先脱敏，并写明希望确认的结果。

类似文章