从零构建 Linux|07 使用 Yocto

系列第 7 篇｜通用工作流 + BitBake 流程 + 常见菜谱路径 + QEMU 说明 + 玄铁对照 + 双 MACHINE编译宿主：Windows 上的 WSL2 Ubuntu｜动手目标：qemux86-64 与 genericx86-64

上一篇建立了「Yocto 是什么」的概念。本篇做五件事：

1. 把通用使用流程用文字和命令串起来；
2. 说明 BitBake 构建流程，弄清为何要改 layer / recipe / conf；
3. 标出内核、sh / bash、BusyBox 等常见模块在 poky 里的菜谱路径；
4. 简介 xuantie-yocto-project（只作对照，不作为烧写目标）；
5. 说清 QEMU 是什么、为何先用它，并锁定第 8～12 篇动手 demo（WSL2 虚机/真机对比 + Git 托管配置）。

编译宿主：就用你 Windows 里的 WSL2 Ubuntu

BitBake 需要在 Linux 环境中运行。本系列统一约定：

读者在自己的 Windows 电脑上启用 WSL2，安装 Ubuntu，之后所有依赖安装、配置、bitbake 都在这个 Ubuntu 里完成。

这样做的好处很直接：不另买 Linux 机器，也能用日常 PC 走完构建；真机验证时，往往还是同一台 Windows 电脑。

几条入门提醒：

1. 在微软文档里启用 WSL2，并安装 Ubuntu（版本以 Yocto 官方 Quick Start 支持列表为准）。
2. 工程目录放在 WSL2 自己的文件系统里，例如 ~/yocto/poky，尽量不要放在 /mnt/c/... 下长编译（跨文件系统会明显变慢）。
3. 本系列不走「纯 Windows 原生直接跑 Yocto」的路线。

备注：官方 Quick Start（文档现称 Quick Build）见https://docs.yoctoproject.org/5.0/brief-yoctoprojectqs/（与本系列示例分支 scarthgap / YP 5.0 对应；若换版本请到 https://docs.yoctoproject.org 选对应发行版文档。）

通用流程：从零到镜像

第一次接触 Yocto 时，最容易迷失在目录和名词里。先把流程当成一条公交线路：

1. 获取 poky 以及你需要的 layer2. 在 WSL2 Ubuntu 上安装构建依赖3. source oe-init-build-env4. 编辑 local.conf、bblayers.conf5. bitbake <镜像名>6. 到 deploy 目录拿走镜像文件

对应的命令骨架如下（版本分支请以 Yocto 官方文档当前推荐为准；这里以 scarthgap 为例）：

# 以下命令均在 WSL2 的 Ubuntu 终端中执行git clone https://git.yoctoproject.org/poky.git -b scarthgap --depth=1cd poky# 第 8 篇会用 TEMPLATECONF 分别创建：#   build-qemux86-64 / build-genericx86-64# 入门示意（单目录）也可：source oe-init-build-env build-bootstrap# 先改配置（第 8 篇详述），再构建：bitbake core-image-base

core-image-base 是什么？为何选它？

bitbake 后面跟的不是「随便起的名字」，而是一个 image 配方（镜像目标）：它规定「这盒系统默认装哪些包、最终打成什么镜像」。Poky 自带若干参考镜像，常见对比如下：

本系列统一选 core-image-base，原因很具体：

1. 比 minimal 好用：虚机 / 真机上更容易具备中等硬件与网络相关能力，少踩「能开机但缺驱动组」的坑；
2. 比图形镜像轻：不引入桌面栈，构建时间和镜像体积都更可控，也更贴近嵌入式 / 产品裁剪的思路；
3. 足够完成 demo：能登录、能跑 hello、能走完 QEMU 与 U 盘验证即可；更细的「默认装了啥、怎么裁」见第 9 篇。

记一句即可：core-image-base = 「能登录的控制台系统」+「一组可裁的中等硬件支持」；本系列用它当默认套餐，再往里加自己的包。

官方文档入口：

https://docs.yoctoproject.org

备注：宿主依赖、兼容发行版等以官方 Quick Start 为准：https://docs.yoctoproject.org/5.0/brief-yoctoprojectqs/

几个词再解释一遍

BitBake 构建流程：你改的东西各自进哪一步

上一节只列出「改 conf → bitbake」。要真正理解为什么要动 layer / recipe / bblayers.conf / local.conf，需要先看 BitBake 接到一条命令后大致怎么干活。

你执行：

bitbake core-image-base

BitBake 并不是「找到一个叫 core-image-base 的脚本就直接编译」，而是按下面这条链路推进（简化版）：

读配置  → 扫描已启用 layer 里的 recipe  → 解析目标（image / 软件包）与依赖图  → 按任务依次：下载 → 解压 → 打补丁 → 配置 → 编译 → 安装 → 打包  → 把选中的包装进 rootfs  → 按 MACHINE 生成可启动镜像 → 放到 deploy

对应到你手里会改的对象：

用「做盒饭」再串一遍：

bblayers.conf  → 厨房里打开哪几抽屉（layer）local.conf     → 今天这锅为谁做、份量、加什么菜、装什么盒子recipe (.bb)   → 某一道菜的做法（源码从哪来、怎么炒）image 目标     → 这盒套餐叫什么、默认摆哪些菜bitbake        → 厨师按依赖顺序把菜做完、装箱、放到出餐口（deploy）

任务链再拆一层（够入门即可）

对每一个软件包（recipe），BitBake 通常会跑类似这样的任务序列（名字里常见 do_ 前缀）：

do_fetch → do_unpack → do_patch → do_configure → do_compile → do_install → do_package → …

镜像目标（如 core-image-base）则额外负责：收集包 → 组装 rootfs → 生成 wic / tar 等格式。你改 recipe，改的是「某一道菜」的任务怎么跑；你改 local.conf / image，改的是「整盒套餐」怎么选菜、怎么装箱。

和下一节的关系

所以后面强调改两个 conf、再建 meta-demo 写 .bb，不是习惯问题，而是对上了 BitBake 的输入口：

1. 层列表（bblayers.conf）→ BitBake 才看得见你的 meta；
2. 本机策略（local.conf）→ 决定 MACHINE 与镜像侧偏好；
3. 菜谱（recipe）→ 决定自定义软件如何被构建进包。

第 8 篇起动手改这些文件时，可以随时回看本节这张「改什么 ↔ 进哪一步」对照表。

两个最关键的配置文件

初始化后，在对应 build-*/conf/ 下你会看到很多文件。结合上一节：它们是 BitBake 读配置阶段的入口。初学先抓住两个：

local.conf 里常见会改：

1. MACHINE：为哪种机器构建；
2. 下载目录、并行编译数量；
3. 额外安装哪些包；
4. 生成哪些镜像格式等。

本系列为两个 MACHINE 各建一个 build 目录，各自 local.conf 里写死对应值，而不是在同一文件里来回改：

# build-qemux86-64/conf/local.confMACHINE ??= "qemux86-64"# build-genericx86-64/conf/local.confMACHINE ??= "genericx86-64"

??= 的含义粗浅理解为：若前面没人指定过 MACHINE，就用这个默认值。初学阶段把它看成「给 MACHINE 赋值」即可。

镜像里最终有哪些软件，还取决于 image 配方里的 IMAGE_INSTALL 等变量——那是「组 rootfs」那一步。第 8 篇会用 TEMPLATECONF 模板实际改一版；第 12 篇说明如何用 Git 托管这些模板。

常见模块的菜谱路径（内核 / sh / bash / BusyBox）

知道「要改 recipe」还不够：读者常会问「内核在哪改？/bin/sh 又是谁提供的？」下面按 poky 源码树（~/yocto/poky/）给出本系列最常碰到的几处路径。版本号随 scarthgap 等分支变化，以你克隆下来的实际文件名为准。

关系可以记成：

virtual/kernel  →  具体菜谱（本系列 x86 多为 linux-yocto）busybox         →  小工具 + 常见默认 /bin/sh（ash）bash            →  完整 shell；要进镜像需显式安装/bin/sh         →  符号链接，指向当前优先级最高的 shell 提供者

在已 source oe-init-build-env build 的终端里，可用下面命令「找路」（find 请在 poky 根目录执行）：

# 某个包由哪份 .bb 提供（示例；需在 build 环境中）bitbake -e busybox | grep '^FILE='bitbake -e bash | grep '^FILE='bitbake -e virtual/kernel | grep -E '^(PREFERRED_PROVIDER_virtual/kernel|FILE|PN|PV)='# 源码树里快速定位菜谱文件名cd ~/yocto/poky   # 按你的实际克隆路径调整find . \( -name 'busybox_*.bb' -o -name 'bash_*.bb' -o -name 'linux-yocto_*.bb' \)

定制原则（后面第 8～9 篇会反复用到）：

1. 上游 meta/ 里的 .bb 只读、不手改——升级 poky 时会被覆盖。
2. 改行为：在自己的 meta-demo 里写同名 **.bbappend**，或改 local.conf / image 的 IMAGE_INSTALL。
3. 内核版本与补丁的具体写法见第 9 篇；本节约路径地图，方便你对照源码树。

xuantie-yocto-project：看懂即可

平头哥玄铁的 Yocto 工程，典型形态是：

1. 在上游 Yocto / OpenEmbedded 之上，叠加厂商 BSP layer；
2. 提供玄铁相关 machine、内核 / 引导适配、参考 image；
3. 用官方 README 说明如何获取、如何构建。

你去阅读它的价值在于：看清「真实芯片厂商如何组织 Yocto 工程」。但请反复记住本系列边界：

我们不在玄铁板卡上烧写，也不把玄铁 machine 当作第 8～12 篇的构建目标。动手目标是 x86_64：先 QEMU，再真机 PC。

检索关键词：

xuantie-yocto-project

QEMU 是什么？为什么先用它跑

动手 demo 会反复出现两个名字：qemux86-64 与 runqemu。先把 QEMU 说清楚，再进后面的约定表。

QEMU（Quick Emulator）是一套开源机器模拟器 / 虚拟化器：在你的 WSL2 Ubuntu 里，用软件「假装」出一块带 CPU、内存、磁盘、网卡的 x86_64 电脑，然后把你刚编好的内核和 rootfs 镜像交给这块「假电脑」去启动。

和真机的对应关系：

真机 PC：UEFI / 固件 → 引导器 → Linux 内核 → rootfs → init → …QEMU 里：runqemu 拉起 QEMU → 模拟硬件 → 同一套内核 / rootfs → init → …

qemux86-64 是 Yocto 里为「在 QEMU 上跑」准备的 MACHINE；runqemu 是 poky 自带的包装脚本，帮你选镜像、拼好 QEMU 命令（第 11 篇细讲）。

为什么本系列先编、先跑 QEMU（qemux86-64），再去做真机（genericx86-64）？

1. 闭环快：不写 U 盘、不动分区，改完配置 → bitbake → runqemu，在同一台 Windows / WSL2 上就能看到登录提示和 hello。
2. 风险低：失败最多是虚机起不来，不会误擦硬盘或搞坏 Windows 启动项。
3. 问题更好定位：若 QEMU 里已经正常，再上真机出问题，多半是固件 / 引导 / 磁盘镜像格式，而不是「hello 配方写错了」。
4. 和前面启动篇对得上：启动链（bootloader → kernel → rootfs → init）在虚机里同样完整可观察，只是硬件被模拟掉了。

一句话：QEMU 是廉价、可重复的「第一块板子」；真机 U 盘双系统是第二步，用来确认「通用 PC」路径也能走通。

Demo 约定（第 8～12 篇全部按此执行）

从现在起，动手部分统一使用下表，避免「文档里一会儿板子一会儿 PC」。

两机型怎么对比（先记住这张表）

实话实说：genericx86-64 是「通用」机型，不能保证你笔记本上每块声卡、独显、特殊触控板都完美。本 demo 的成功标准是：虚机与真机都能进系统并运行 hello，而不是替代你的日常桌面发行版。

宿主依赖与磁盘：开始前的心理准备

Yocto 会下载大量源码、进行大量编译。请提前准备：

1. 按官方 Quick Start 在 WSL2 Ubuntu 上安装宿主软件包（git、gcc、python3、chrpath、diffstat 等，具体列表随发行版变化）；
2. 预留 50GB 以上空闲磁盘，两机型都编时更多更稳妥；
3. 保持网络畅通（公司代理环境需额外配置）。

备注：官方 Quick Start（宿主软件包安装命令）见https://docs.yoctoproject.org/5.0/brief-yoctoprojectqs/

第一次完整构建可能要数小时，这是正常现象，不是你操作错了。

本篇小结

1. 编译宿主锁定为 Windows 上的 WSL2 Ubuntu。
2. 通用路径：拿 poky → 按 MACHINE 初始化 build 目录 → 改 conf → bitbake → 取 deploy 产物。
3. BitBake 流程：读配置 → 扫 layer/recipe → 跑任务链 → 组 rootfs → 出镜像；因此才需要改 bblayers.conf / local.conf / meta / recipe。
4. bblayers.conf 管「用哪些层」，local.conf 管「这次怎么构建」；两机型建议两套 build。
5. 常见菜谱：linux-yocto 在 meta/recipes-kernel/linux/，BusyBox 在 meta/recipes-core/busybox/，bash 在 meta/recipes-extended/bash/；/bin/sh 多半由 BusyBox 等通过 alternatives 提供，定制用 bbappend / IMAGE_INSTALL，勿直接改上游。
6. QEMU 用软件模拟一台电脑；先 qemux86-64 + runqemu 闭环，再 genericx86-64 真机验证。玄铁工程只作对照。

下一篇开始真正改配置：用 bitbake-layers create-layer 建 meta-demo、导出 TEMPLATECONF，并把 hello 加进镜像。

系列文章列表：