1. 课程导入与工程环境总览

NXP i.MX 系列处理器（如 i.MX 6/7/8/9 系列）在工业控制、车载娱乐、边缘计算与智能终端领域应用广泛。围绕这些 SoC，NXP 官方维护了一套基于 Yocto Project 的构建系统，通常称为 i.MX Yocto BSP 或 i.MX Linux Release。本课程的目标，是让读者能够独立完成从主机环境准备、源码获取、镜像构建，到镜像烧写与板级验证的完整工程闭环，而不是停留在"能跑通一条命令"的层面。

1.1 构建工程的目标与交付物

i.MX Yocto 构建工程的核心目标，是把"上游开源组件 + NXP 私有补丁 + 板级配置"三者组合，编译出可直接部署到目标板的可启动镜像。它要解决三个问题：一是保证内核、U-Boot、根文件系统与 SoC 版本严格匹配；二是把 NXP 的图形、VPU、ISP、DSP 等专有组件正确集成；三是让同一套配方（recipe）能覆盖多个 i.MX 板卡，实现可复现构建。

一次完整构建的典型交付物包括：

• 引导镜像：imx-boot（含 U-Boot SPL、DDR 固件、U-Boot proper 打包后的 imx-boot-*.bin），用于从 SD/eMMC 启动。
• 内核镜像：Image（ARM64）或 zImage（ARM32），以及对应的设备树 .dtb 文件。
• 根文件系统：core-image-base、core-image-minimal 或带图形栈的 imx-image-full，输出为 .tar.bz2、.ext4、.wic 等格式。
• SDK 与工具链：meta-toolchain 生成的交叉编译 SDK 安装脚本，供应用开发者使用。
• 许可证与清单：license.manifest、image_manifest，用于合规审计与版本追溯。

这些交付物最终都落在 tmp/deploy/images/<machine>/ 目录下，是判断构建是否成功的直接依据。

1.2 典型开发流程

从工程视角看，i.MX Yocto 的开发流程可以概括为"环境准备 → 源码同步 → 配置选择 → 构建 → 部署 → 验证"六个阶段。其中最容易出问题的不是构建本身，而是环境准备与配置选择。下图给出了这一流程中各阶段的关键输入、输出与依赖关系，帮助读者在动手前建立整体认知。

1.3 主机环境准备要点

NXP 官方推荐使用 Ubuntu 20.04 LTS 或 22.04 LTS 作为构建主机。虽然理论上其他发行版也能工作，但依赖包名称、Python 版本、locale 设置的差异会显著增加排障成本。以下是一份经过验证的环境准备清单，可直接作为工程初始化脚本使用：

# 1. 安装基础依赖（Ubuntu 22.04）
sudo apt-get update
sudo apt-get install -y gawk wget git diffstat unzip texinfo gcc \
  build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
  xz-utils debianutils iputils-ping python3-git python3-jinja2 \
  libegl1-mesa libsdl1.2-dev pylint xterm zstd liblz4-tool file \
  locales apt-utils sudo

# 2. 设置 locale（避免 bitbake 报 locale 错误）
sudo locale-gen en_US.UTF-8
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

# 3. 配置 git 用户信息
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# 4. 安装 repo 工具
mkdir -p ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
export PATH=~/bin:$PATH

磁盘空间是最容易被低估的一项。一个完整的 i.MX8 构建，sources/ 目录约 30～40GB，build/ 目录（含 tmp/、sstate-cache/、downloads/）在首次全量构建后通常达到 80～120GB。因此建议为构建目录单独挂载一块 ≥250GB 的 SSD，并确保文件系统为 ext4，避免在 NTFS 或网络文件系统上构建，否则会出现权限、符号链接与大小写敏感性问题。

网络方面，Yocto 构建需要从多个上游站点下载源码包（tarball、git 仓库）。国内环境建议配置代理或使用镜像源，并在 build/conf/local.conf 中设置 BB_NO_NETWORK 之前先完成一次完整下载。若企业内网有防火墙，需要放行 git、https 与 ftp 协议，或提前把 downloads/ 目录做成共享缓存。

1.4 工具链与版本匹配

i.MX Yocto 使用 Yocto 自带的交叉工具链，由 meta-toolchain 或 bitbake meta-toolchain 生成，不需要手动安装 arm-linux-gnueabihf-gcc。工具链的版本与 Yocto 版本绑定：例如 i.MX Linux 5.15.71_2.2.0 对应 Yocto Kirkstone，使用 GCC 11；i.MX Linux 6.1.22_2.0.0 对应 Yocto Mickledore，使用 GCC 12。混用不同版本的 BSP 与工具链，会导致内核模块 vermagic 不匹配、glibc 符号缺失等难以定位的问题。

1.5 工程目录结构速览

执行 repo sync 后，工作区通常呈现如下结构，理解它有助于快速定位问题：

建议在首次构建前，先执行 bitbake -e core-image-minimal | grep ^MACHINE= 确认 MACHINE 变量生效，再用 bitbake -s | grep imx 查看可用的 i.MX 相关配方。这两步能在几分钟内暴露大部分配置错误，避免浪费数小时的构建时间。