📚 课程目录第3章获取Yocto源码

3. 获取Yocto源码：下载Poky主线版本、理解源码目录结构、切换稳定分支、使用repo管理多仓库、验证下载完整性

好，咱们正式开始动手。这一章的核心任务就一个——把Yocto的源码拿到手，并且确保它是干净的、可用的。

很多新手上来就git clone，然后就开始bitbake，结果编译到一半报错，查了半天发现是分支不对，或者源码不完整。我刚开始搞Yocto的时候也吃过这个亏，浪费了整整两天去排查一个根本不存在的问题。所以，这一章咱们把基础打牢。

3.1 下载Poky主线版本

Poky是Yocto项目的参考发行版，也是我们最常用的起点。说白了，它就是Yocto的“官方样板间”。

我个人习惯把Yocto相关的源码统一放在/opt/yocto目录下，这样方便管理。当然，你也可以放在用户目录下，看个人喜好。

# 创建源码目录
mkdir -p /opt/yocto
cd /opt/yocto

# 克隆Poky主线仓库
git clone git://git.yoctoproject.org/poky

这里要注意，git://协议在某些公司网络环境下可能被屏蔽。如果遇到这种情况，可以换成https://协议：

git clone https://git.yoctoproject.org/git/poky

下载完成后，你会得到一个poky目录。别急着进去，我们先看看它长什么样。

3.2 理解源码目录结构

Poky的目录结构其实很有规律。你想想看，一个能构建完整Linux系统的工具，它的源码组织一定是有逻辑的。我把它拆成几个核心部分：

目录/文件	作用	我的理解
`bitbake/`	构建引擎核心	Yocto的“发动机”，负责解析配方、调度任务
`meta/`	核心元数据层	包含OpenEmbedded核心配方，是所有构建的基础
`meta-poky/`	Poky发行版配置	定义了Poky这个发行版的默认策略和版本
`meta-yocto-bsp/`	参考板级支持包	官方提供的几个参考硬件平台的BSP
`scripts/`	辅助工具脚本	一些好用的工具，比如`oe-pkgdata-util`
`oe-init-build-env`	环境初始化脚本	每次开始工作前，都要source这个脚本

一个小技巧： 我个人习惯用tree -L 2命令来快速查看目录结构。如果你没有安装tree，可以用sudo apt install tree装上。

这里我要特别强调一下meta/目录。它里面包含了成千上万个.bb文件（配方文件），这些文件定义了如何下载、配置、编译和打包每一个软件包。你想想看，一个完整的Linux系统有成百上千个软件包，每个包都需要这样一套描述，工作量是巨大的。但Yocto通过层（Layer）的机制，把这些配方组织得井井有条。

3.3 切换稳定分支

主线版本是开发中的版本，可能不稳定。我们做产品开发，一定要用稳定分支。我记得有一次，我图新鲜用了主线，结果编译出来的内核死活起不来，查了三天才发现是主线的一个提交引入了bug。

从那以后，我再也不敢在生产环境中用主线了。

Yocto的稳定分支命名规则是<代号>，比如kirkstone、langdale、mickledore。每个代号对应一个长期支持版本（LTS）。

# 查看所有可用分支
cd poky
git branch -a

# 切换到kirkstone分支（当前最新的LTS版本）
git checkout kirkstone

注意： 切换分支后，一定要确认当前分支是否正确。可以用git branch命令查看，当前分支前面会有一个星号。

为什么我推荐kirkstone？因为它是Yocto Project 4.0版本，是2022年发布的LTS版本，支持到2024年。对于大多数嵌入式项目来说，这个版本足够稳定，而且社区支持也最活跃。

3.4 使用repo管理多仓库

在实际项目中，你不可能只用一个Poky仓库。你还需要自己的应用层、BSP层、第三方库层等等。如果每个仓库都手动git clone，管理起来会非常痛苦。

这时候，repo工具就派上用场了。它是Google为Android开发的一个多仓库管理工具，但同样适用于Yocto项目。

安装repo很简单：

# 下载repo工具
mkdir -p ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

# 将~/bin加入PATH
export PATH=~/bin:$PATH

然后，创建一个manifest文件来描述你的项目结构。这个文件是一个XML文件，定义了每个仓库的路径、分支和远程地址。

举个例子，一个典型的Yocto项目manifest可能长这样：

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
    <remote name="yocto" fetch="git://git.yoctoproject.org" />
    <remote name="github" fetch="https://github.com" />

    <project name="poky" path="poky" remote="yocto" revision="kirkstone" />
    <project name="meta-openembedded" path="meta-openembedded" remote="yocto" revision="kirkstone" />
    <project name="meta-raspberrypi" path="meta-raspberrypi" remote="github" revision="kirkstone" />
    <project name="my-meta-layer" path="sources/my-meta-layer" remote="github" revision="main" />
</manifest>

有了这个manifest文件，你就可以用一条命令同步所有仓库：

repo init -u <manifest仓库地址> -b <分支>
repo sync

repo sync会自动克隆所有定义的仓库，并切换到指定的分支。你想想看，如果项目有十几个甚至几十个仓库，这个工具能帮你省多少时间。

    我的经验： 我建议把manifest文件也放在一个Git仓库里管理。这样，整个项目的源码结构就有了版本控制，团队成员可以轻松复现相同的开发环境。

3.5 验证下载完整性

源码下载完了，怎么确保它没有被篡改或者下载过程中没有损坏？Yocto官方提供了SHA256校验和。

每个Poky发布版本都会附带一个SHA256SUMS文件，里面列出了所有文件的哈希值。我们可以用这个文件来验证。

# 下载SHA256SUMS文件
wget https://git.yoctoproject.org/poky/snapshot/poky-kirkstone-4.0.12.tar.bz2.SHA256SUMS

# 计算本地文件的SHA256值
sha256sum poky-kirkstone-4.0.12.tar.bz2

# 对比两个值是否一致
cat poky-kirkstone-4.0.12.tar.bz2.SHA256SUMS

如果你是用git clone的方式，验证方式就更简单了——Git本身就有完整性校验机制。每次git checkout或者git pull时，Git都会自动检查对象的完整性。

不过，我还是要多一句嘴：如果你是从非官方镜像或者第三方网站下载的源码包，一定要做校验。我曾经在一个第三方镜像站下载过被植入后门的源码包，还好我习惯性地做了校验，发现哈希值对不上，才避免了灾难。

验证小贴士： 对于git clone的仓库，可以用git fsck命令来检查仓库的完整性。这个命令会检查所有Git对象是否损坏。

3.6 本章知识结构图

为了让你更直观地理解本章的知识脉络，我画了一张流程图：

这张图清晰地展示了从下载到验证的完整链路。每一步都有它的意义，跳过了哪一步，后面都可能踩坑。