3. Yocto中的Bootloader集成：meta层结构、U-Boot源码获取、U-Boot配置与编译流程

好，我们进入第三章。这一章是实操前的关键一环——你得搞清楚Yocto到底怎么把U-Boot“请”进你的系统里。说白了，就是理解meta层的结构、知道源码从哪来、以及编译流程怎么跑通。

很多初学者一上来就急着改配置，结果连u-boot.bb文件在哪都没找到。我刚开始接触Yocto时也犯过这个错，折腾了两天才发现是layer优先级没搞对。嗯，咱们一步步来。

3.1 meta层结构：谁在管U-Boot？

Yocto里所有东西都是通过meta层（layer）组织的。U-Boot也不例外。你想想看，一个嵌入式系统可能有几十个组件，如果没有清晰的层次划分，那不乱套了？

通常，与Bootloader相关的meta层分为三类：

层类型 典型名称 作用
基础层 meta 提供OE-core核心配方，包含U-Boot的通用bbclass
BSP层 meta- 板级支持包，包含特定硬件平台的U-Boot源码和配置
用户层 meta- 你的项目层，用于覆盖默认配置、添加分区方案

我个人习惯把用户层放在最上层，这样优先级最高。Yocto的层优先级是通过BBFILE_COLLECTIONS和BBFILE_PRIORITY控制的，数值越大优先级越高。

关键点：U-Boot的最终配置是“基础层 + BSP层 + 用户层”叠加的结果。如果你在用户层定义了UBOOT_CONFIG，它会覆盖BSP层的默认值。

3.2 U-Boot源码获取：从哪里来？

U-Boot的源码获取方式，在Yocto里是通过SRC_URI变量指定的。最常见的做法是从Git仓库拉取。

我们来看一个典型的u-boot_2024.01.bb配方片段：

# 从上游Git仓库获取
SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master"

# 指定具体的提交哈希
SRCREV = "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0"

# 补丁文件（如果有）
SRC_URI += "file://0001-add-my-board-support.patch"

这里有几个坑，我跟你分享一下：

  • 分支选择：不要直接用master分支做产品。我建议用稳定标签，比如v2024.01。我在一个项目中就吃过亏，master分支某次提交引入了regression，导致NAND驱动挂了。
  • SRCREV锁定：一定要锁定具体的commit hash。否则每次构建都可能拿到不同版本的代码，那你的分区方案可能就白调了。
  • 补丁管理：补丁文件放在files/目录下，命名要有规律。我曾经见过一个项目，补丁文件叫fix.patch、fix2.patch……三个月后谁都不知道这些补丁是干嘛的。

我的建议：如果你用的是自己的U-Boot分支，可以在SRC_URI里直接指向你的私有Git仓库。Yocto支持SSH和HTTPS协议，但CI环境下建议用HTTPS + token的方式，避免SSH密钥管理问题。

3.3 U-Boot配置与编译流程：到底怎么跑的？

这一节是核心。U-Boot在Yocto中的编译流程，其实可以拆成四个阶段。我画了一张图，帮你理清整体逻辑：

U-Boot在Yocto中的编译流程 阶段1：源码获取 do_fetch 阶段2：配置 do_configure 阶段3：编译 do_compile 阶段4：部署 do_deploy 配置阶段的关键变量 UBOOT_CONFIG = "myboard" UBOOT_MACHINE = "myboard_config" UBOOT_BINARY = "u-boot.bin" 编译阶段的关键变量 UBOOT_MAKE_TARGET = "all" EXTRA_OEMAKE = "CROSS_COMPILE=..." PACKAGE_ARCH = "${MACHINE_ARCH}"

这张图展示了四个阶段的串联关系。下面我详细拆解每个阶段。

3.3.1 配置阶段（do_configure）

配置阶段的核心是生成.config文件。Yocto通过UBOOT_CONFIG和UBOOT_MACHINE变量来控制。

举个例子，假设你有一个板子叫myboard：

# 在机器配置文件中（如 meta-myproject/conf/machine/myboard.conf）
UBOOT_CONFIG ??= "myboard"
UBOOT_CONFIG[myboard] = "myboard_config,sdcard"
UBOOT_CONFIG[myboard_nand] = "myboard_nand_config,nand"

这里myboard_config就是U-Boot的defconfig名称。Yocto会执行make myboard_config来生成.config。

注意：如果你在UBOOT_CONFIG里指定了多个配置（比如同时支持SD卡和NAND启动），Yocto会为每个配置分别编译一次。这会显著增加构建时间。我建议在开发阶段只保留一个配置，等稳定了再添加其他启动方式。

3.3.2 编译阶段（do_compile）

编译阶段就是执行make。但这里有个细节：Yocto会设置交叉编译工具链的环境变量。

我记得有一次，同事直接在U-Boot源码目录里执行make，结果编译出来的东西在目标板上跑不起来。原因就是他没有用Yocto提供的交叉编译器。正确的做法是让BitBake帮你管理这一切。

编译阶段的关键变量：

  • UBOOT_MAKE_TARGET：默认是all，但如果你只需要u-boot.bin，可以改成u-boot.bin来节省时间。
  • EXTRA_OEMAKE：用于传递额外的make参数。比如EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX}"。
  • PARALLEL_MAKE：控制并行编译的线程数。我一般设成-j 4或-j $(nproc)。

3.3.3 部署阶段（do_deploy）

编译完成后，U-Boot镜像会被复制到部署目录。这个目录通常位于tmp/deploy/images/${MACHINE}/。

部署阶段做的事情很简单：

  1. 把u-boot.bin复制到部署目录
  2. 如果配置了UBOOT_SUFFIX，会生成对应的文件（如u-boot.imx、u-boot.sb）
  3. 生成符号链接（如u-boot-${MACHINE}.bin -> u-boot.bin）

避坑指南：我曾经遇到过一个问题——部署目录里的U-Boot镜像总是旧的。后来发现是do_deploy的sstate缓存没清理。如果你改了配置但镜像没更新，试试bitbake -c cleansstate u-boot，然后再重新编译。

3.4 实战：从零配置一个U-Boot

说了这么多理论，咱们来点实际的。假设你要为一块新板子配置U-Boot，步骤是这样的：

步骤 操作 说明
1 创建机器配置文件 meta-myproject/conf/machine/myboard.conf
2 设置UBOOT_CONFIG UBOOT_CONFIG ??= "myboard"
3 创建U-Boot配方追加文件 meta-myproject/recipes-bsp/u-boot/u-boot_%.bbappend
4 添加板级defconfig 放在files/目录下，通过SRC_URI引用
5 执行构建 bitbake u-boot

这里我特别想强调一下.bbappend文件的用法。它不会覆盖原始配方，而是在原始配方的基础上追加内容。比如：

# u-boot_%.bbappend
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "file://myboard_defconfig"

do_configure:prepend() {
    # 在配置前做一些自定义操作
    sed -i 's/CONFIG_BOOTDELAY=2/CONFIG_BOOTDELAY=0/' ${S}/configs/myboard_defconfig
}

这种做法的好处是，你不需要fork整个U-Boot配方，只需要维护自己的增量修改。升级U-Boot版本时，只要.bbappend文件里的补丁还能用，就能无缝升级。

3.5 常见问题与排查思路

最后，我总结几个我在项目中遇到过的典型问题：

  • 编译报错“No rule to make target”：通常是UBOOT_MACHINE指定的defconfig不存在。检查一下configs/目录下有没有对应的文件。
  • 镜像生成了但板子不启动：可能是U-Boot的链接地址不对。检查CONFIG_SYS_TEXT_BASE是否匹配你的硬件设计。
  • 部署目录里没有u-boot.bin：检查UBOOT_BINARY变量是否设置正确。有些平台生成的是u-boot.imx或u-boot.spl。

嗯，这一章的内容就到这里。记住，U-Boot的集成不是一蹴而就的，多试几次，把每个阶段的输出都检查一遍，你很快就能摸清门道。

← 上一章 📖 返回目录 下一章 →