Yocto内核配方中SRCREV_machine与SRCREV_meta是什么？BitBake如何处理？

1. 两个SRCREV变量的核心作用 #

很多硬件厂商的内核会拆分成两个独立Git仓库维护：一个存储硬件专属的驱动、设备树补丁；另一个存储Yocto层适配用的通用配置、脚本。这两个变量就是分别锁定这两个仓库的具体提交版本：

• SRCREV_machine：对应树莓派这类硬件专属的内核代码提交ID，管控和硬件强绑定的驱动、板级支持内容。
• SRCREV_meta：对应Yocto维护的通用内核适配代码提交ID，管控通用补丁、构建模板这类不绑定特定硬件的内容。

2. 为何不直接用SRCREV="${AUTOREV}"或单一Git哈希？ #

• 避开AUTOREV：AUTOREV会自动拉取仓库最新提交，导致每次构建的内核版本可能不一致，完全丧失构建可重复性，生产环境或稳定版本构建绝对不能用。
• 单一哈希无法满足多仓库场景：内核代码来自多个独立仓库时，一个哈希只能锁定一个仓库的版本，拆分的SRCREV才能精准控制每个仓库的提交，避免不同仓库版本不兼容的问题。

3. 树莓派内核配方代码解读与BitBake处理逻辑 #

树莓派配方里的两行代码，就是给对应的两个内核仓库指定了固定的提交哈希：

SRCREV_machine = "31dbf25138831241f31f7eee835b83a607eaa179"
SRCREV_meta = "2eaed50911009f9ddbc74460093e17b22ef7daa0"

BitBake的处理流程：

• 先读取配方中的SRC_URI配置，找到这两个变量对应的Git仓库地址。
• 分别拉取两个仓库中对应哈希的代码，合并到构建目录中。
• 按照Yocto内核构建流程，完成补丁应用、配置生成、编译等步骤，最终产出适配树莓派的内核镜像。

内容的提问来源于stack exchange，提问作者preetam