软件工作流
微控制器开发极为简便：安装厂商集成开发环境（IDE）、创建新项目，即可开始编程与调试。可能需要从库中引用部分.c/.h 文件，极少数情况下需链接预编译库。
而构建嵌入式 Linux 系统时，首先需编译所有计划运行的现成软件 —— 引导加载程序、内核、用户态库及应用程序。还需编写和定制 shell 脚本与配置文件，且通常需要从零开发部分应用程序。这是一套完全不同的开发流程，以下将介绍相关前提条件。
若要构建 Linux 系统镜像，需借助 Linux 操作系统。若你同时负责硬件设计，这会陷入两难境地 —— 多数 PCB 设计工作需在 Windows 环境下完成。尽管 Windows 子系统 Linux（WSL）可运行构建镜像所需的所有软件，但目前 WSL 无法实现 USB 设备直通，因此无法在 Linux 环境中使用硬件调试器（甚至 USB MicroSD 读卡器）。此外，由于 WSL2 基于 Hyper-V 架构，启用后将无法运行采用自有虚拟机监控程序的 VMware（不过 VMware 测试版本已解决此问题）。
因此，建议用户暂时避开这类新型技术，转而使用传统的 VMware 虚拟机安装 Linux 系统。在 VMware 中，可实现 MicroSD 读卡器、调试探针甚至设备本身（通常具备 USB 引导加载程序）的直通。
构建镜像是计算密集型且高度并行的任务，因此计算机需配备高性能、高功耗的高端桌面级（HEDT）/ 服务器级多核 CPU—— 应尽可能为虚拟机分配更多核心。编译目标系统的所有软件也会快速占用存储空间：若计划同时处理多个大型嵌入式 Linux 项目，建议至少分配 200GB 存储空间。
尽管具体项目可能需要更多软件，但现代嵌入式 Linux 系统均包含以下五大核心组件（注：这些组件存在替代方案，但偏离嵌入式 Linux 标准越远，后续问题排查难度越大）：
- 1. 交叉工具链：通常基于 GCC + glibc，包含编译器、二进制工具（binutils）和 C 库。它并不直接部署到嵌入式 Linux 系统，而是用于编译其他组件。
- 2. U-Boot：引导加载程序，负责初始化 DRAM、控制台和启动介质，将 Linux 内核加载到内存并执行。
- 3. Linux 内核：管理内存、调度进程，实现与硬件和网络的交互。
- 4. Busybox：单一可执行文件，集成核心用户态组件（如 init、sh 等）。
- 5. 根文件系统（rootfs）：包含上述用户态组件、所有已编译的可加载内核模块、共享库及配置文件。
阅读至此无需感到压力：若你的硬件与现有参考设计或评估套件较为接近，他人很可能已为所有这些组件创建了默认配置，你只需找到并修改它们即可。作为从事板级支持包（BSP）工作的嵌入式 Linux 开发者，你将更多时间用于阅读和修改他人代码，而非从零编写新软件。
交叉工具链
与微控制器开发类似，嵌入式 Linux 项目需在计算机上编写和编译软件，再在目标设备上远程测试。微控制器编程时，通常直接使用厂商 IDE（内置交叉工具链）—— 交叉工具链是指在一种 CPU 架构上运行，却能为另一种架构生成代码的工具链。例如，为 ATTiny1616 编程时，使用的 GCC 版本运行在 x64 计算机上，但可生成 AVR 架构代码。嵌入式 Linux 开发同样需要交叉工具链（除非你使用 ARM 架构笔记本电脑，或构建 x64 架构嵌入式系统）。
配置工具链时，可考虑两款轻量级 C 库 ——musl libc 和 uClibc-ng，它们实现了完整 glibc 的子集功能，但体积仅为 glibc 的 1/5。大多数软件可正常编译，因此无需完整 libc 功能时是极佳选择。两者相比，uClibc 是较老的项目，尽量兼容 glibc；musl 则是全新重写，性能出色，但兼容性稍差。
U-Boot
遗憾的是，CPU 的引导 ROM 无法直接加载内核。Linux 需要通过特定方式启动，以获取引导参数、设备树指针和初始内存磁盘（initrd），且要求主内存已完成初始化。而引导 ROM 不具备主内存初始化能力，导致 Linux 无存储空间可用。此外，引导 ROM 最多只能从闪存加载数 KB 数据，远不足以容纳完整内核。因此，需要一个小型程序（由引导 ROM 加载）来初始化主内存，再加载完整的（通常为数 MB 的）Linux 内核并执行。
嵌入式系统中最流行的引导加载程序是 Das U-Boot（通常简称 U-Boot），它不仅能完成上述所有工作，还提供了大量额外功能：全交互式 shell、脚本支持、USB / 网络启动等。
若使用小型 SPI 闪存启动，通常将内核、设备树和初始内存磁盘（initrd）/ 根文件系统存储在闪存的不同偏移地址 ——U-Boot 可将其加载到内存并执行。此外，由于 U-Boot 完全支持文件系统，也可将内核和设备树作为普通文件存储在 SD 卡、eMMC 设备或 USB 闪存的分区中。
U-Boot 需要了解系统的大量技术细节：每个支持的平台都有专门的 board.c 文件，负责初始化时钟、DRAM、相关内存外设，以及 UART 控制台或电源管理集成电路（PMIC）等关键外设（可能需要在 CPU 全速运行前正确配置）。较新的板级移植通常将部分配置信息存储在设备树（后文将详细介绍）中。部分 DRAM 配置数据可自动检测，因此无需修改 U-Boot 的处理器移植代码即可更改 DRAM 容量和布局（注：若 DRAM 布局处于临界状态，或使用的内存芯片时序与移植代码预设差异较大，则可能需要调整这些参数）。
通过编写脚本可配置 U-Boot 的行为：指定初始化的设备、加载文件 / 地址到内存地址、向 Linux 传递引导参数。这些配置可硬编码，也可存储为环境变量（启动脚本本身可存储为 bootcmd 环境变量）。因此，让 U-Boot 在新板卡上工作的核心任务之一是配置环境变量。
Linux 内核
这是整个系统的核心。U-Boot 将程序计数器交给 Linux 后，内核会初始化自身、加载设备驱动（注：Linux 不会像 DOS 等老式 PC 操作系统调用 BIOS 功能那样调用 U-Boot 驱动）和其他内核模块，然后调用 init 程序。
要让板卡正常工作，内核相关的修改通常仅限于启用文件系统、网络功能和设备驱动 —— 但也有更高级的选项可控制和优化内核的底层功能。
启用或禁用驱动并不复杂，但新开发者往往在驱动配置环节受阻。嵌入式 Linux 与桌面 Linux 的一个重要区别是：嵌入式 Linux 系统需通过设备树文件或平台数据（platform data）C 代码手动向 Linux 传递硬件配置信息，因为嵌入式系统没有 EFI 或 ACPI 等桌面级自动硬件检测机制。
需要告知 Linux CPU 内置外设的地址和配置，以及对应内核模块。你可能认为这是 CPU 的 Linux 移植的一部分，但在 Linux 看来，即便是 CPU 内置的外设（如 LCD 控制器、SPI 接口、ADC）也与 CPU 本身无关，而是作为独立的设备驱动存储在单独的内核模块中。
此外，PCB 上的所有外部外设（传感器、显示器等非 USB 设备）也需手动实例化和配置。例如，告知 Linux I2C0 总线上连接了地址为 0x68 的 MPU6050 惯性测量单元（IMU），或 MIPI D-PHY 接口上连接了 OV5640 图像传感器。许多设备驱动需要额外配置信息，如预分频系数、更新速率或中断引脚使用方式。
传统做法是在板卡的 platform_data C 文件中手动添加 C 结构体，而现代做法是使用设备树（Device Tree）—— 一种以类 C/JSON 语法描述板卡所有硬件的配置文件。每个逻辑硬件都表示为一个节点，嵌套在其父总线 / 设备下，节点包含驱动所需的所有配置参数。
设备树源文件（DTS）不会编译到内核中，而是编译为独立的.dtb 二进制文件（需单独处理：保存到闪存、配置 U-Boot 加载等）（注：实际上可将 DTB 附加到内核中，使 U-Boot 无需单独处理 —— 许多从原始闪存启动的简单系统采用这种方式）。我认为初学者对这一机制感到沮丧是合理的，因为设备驱动需要在两个地方配置：Kconfig 和 DTS 文件。若两者不一致，诊断难度极大 —— 例如 DTS 包含无对应驱动的节点、内核编译了 DTS 未引用的驱动，或属性拼写错误（所有绑定均在运行时解析），都不会产生编译错误。
Busybox
Linux 初始化完成后，会运行 init 程序 —— 这是启动后第一个执行的用户态程序。init 程序通常需要运行 shell 脚本，因此需要 sh 命令；脚本可能需要使用 touch、echo、cat 等命令。仅启动系统就需要在根文件系统中包含大量用户态软件，更不用说登录（getty）、列出目录（ls）、配置网络（ifconfig）或编辑文本文件（vi、emacs、nano、vim 等）等功能了。
Busybox 的巧妙之处在于：将这些程序（及数百个其他常用工具）的轻量级版本整合到单一源码树中，编译链接为单一可执行文件。然后创建指向 Busybox 的符号链接（命名为各个工具的名称），执行这些工具时，Busybox 会根据调用名称执行相应命令 —— 非常巧妙！
Busybox 的配置方式直观，采用与 Linux 和 U-Boot 相同的 Kconfig 系统。只需指定要构建的软件包（及选项）即可。唯一需要注意的 “陷阱” 是：这些轻量级工具的功能通常较少，语法 / 参数未必与标准版本完全兼容。
根文件系统
Linux 需要根文件系统，启动参数需指定根文件系统的位置和格式。
许多简单设备无需在重启后保留数据，因此可在启动前将整个根文件系统复制到 RAM 中（称为 initrd）。但如果需要向根文件系统写入数据，则需考虑存储介质特性：除 MMC 外，所有嵌入式闪存均为未管理闪存 —— 主机需自行处理反复擦写导致的坏块问题。大多数普通文件系统未针对这种场景优化，因此出现了专为闪存设计的专用文件系统，最常用的三款是 JFFS2、YAFFS2 和 UBIFS。它们的性能特点差异较大，但通常高端设备更多使用 UBIFS，小型系统则使用 YAFFS2 和 JFFS2。
MMC 设备内置闪存控制器，可抽象底层闪存细节并自动处理坏块。这种管理型闪存设备在设计中使用更简便，因为它们支持传统分区表和文件系统 —— 用法与 PC 中的硬盘和 SSD 完全一致。
YOCTO 与 BUILDROOT
若前一节内容让你感到困惑，无需担心：完全无需手动配置和编译所有组件。实际上，所有人都使用构建系统 —— 两大主流选择是 Yocto 和 Buildroot—— 它们能自动获取并编译完整的工具链、U-Boot、Linux 内核、Busybox，以及数千个可选软件包，并将所有组件安装到目标文件系统中，可直接部署到硬件。
更重要的是，这些构建系统包含厂商和社区开发的开发板默认配置 —— 我们正是基于这些开发板测试 CPU 并进行硬件设计，这些默认配置能极大节省时间。
诚然，U-Boot 和 Linux 本身都有 defconfig 配置文件来完成主要工作：例如，通过 U-Boot 的 defconfig，已有人为你完成了配置工作，包括初始化特定启动介质、设置 SPL 代码、激活相应外设、编写合理的 U-Boot 环境和启动脚本等。
但构建系统的默认配置更进一步，将所有组件整合在一起。例如，若希望系统从 MicroSD 卡启动，U-Boot 直接写入卡的起始位置，后续是包含内核和设备树的 FAT32 分区，以及 ext4 格式的根文件系统分区。U-Boot 的 defconfig 会生成可写入 SD 卡的二进制文件，Linux 的 defconfig 会生成对应的 vmlinuz 文件，而构建系统会创建 MicroSD 镜像、写入 U-Boot、创建分区表、格式化文件系统，并将相关文件复制到对应位置，最终生成可写入 MicroSD 卡的 “image.sdcard” 文件。
几乎所有市售开发板都至少在 Buildroot 或 Yocto 中拥有非官方支持，因此通常只需一两个命令即可构建可运行的镜像。
这两个构建环境在设计理念、实现方式、功能、起源和行业支持方面完全对立 —— 我从未见过两个功能相同但实现方式差异如此之大的软件项目。以下是详细分析：
Buildroot
Buildroot 最初是一组 Makefile 脚本，用于在大量常用应用中测试 uClibc，以修复库中的漏洞。如今，其架构保持不变，但已发展为构建嵌入式 Linux 镜像最简便的工具。
Buildroot 采用与 Linux、U-Boot 和 Busybox 相同的 Kconfig 系统，通过运行 make menuconfig 即可配置所有参数 —— 目标架构、工具链、Linux、U-Boot、目标软件包和整体系统配置。它提供了大量现成的 defconfig 配置文件，加载对应配置后运行 make 即可生成开发板的可运行镜像。例如，make raspberrypi3_defconfig && make 会生成可用于树莓派 3 的 SD 卡镜像。
Buildroot 还支持直接调用 Linux、U-Boot 或 Busybox 的 Kconfig 配置界面 —— 例如，运行 make linux-menuconfig 可在 Buildroot 目录中启动 Linux 的 menuconfig 编辑器。我认为初学者可能难以区分 Buildroot 选项与 Linux 内核或 U-Boot 选项，因此需要在不同位置仔细查找。
Buildroot 以单一源码树形式分发，基于 GPL v2 许可证。为支持自定义硬件，需添加 defconfig 文件和包含相关文件的 board 文件夹（内容差异较大，可能包含 U-Boot 脚本、补丁，或为空）。尽管 Buildroot 文档指出 “发布包含 GPL 许可软件的产品时，应将 Buildroot 源码与其他软件包源码一同发布”，但这并非强制要求。我发现许多产品（3D 打印机、智能恒温器、测试设备）使用 Buildroot，却未出现在官方支持的配置中，因此推测大多数人并未严格遵循这一要求 —— 官方 defconfig 仅包含开发板配置。
坦白说，对于快速原型项目，你甚至无需创建正式的 board 或 defconfig—— 直接修改现有配置即可。Buildroot 的设计非常灵活，便于快速实现功能：大多数相关设置存储在 defconfig 文件中，可轻松修改和保存；对于极简单项目，无需进一步修改。例如，启用设备驱动时，可在 Buildroot 中调用 Linux 的 menuconfig，修改后保存配置，更新 Buildroot 配置文件以使用本地 Linux 配置（而非源码树中的默认配置）。Buildroot 支持将树外 DTS 文件传递给编译器，因此无需将新板卡的 DTS 文件放入内核源码树或创建机器配置即可编译。若需修改内核源码，还可强制构建过程使用本地内核（非常适合活跃开发阶段）。
Buildroot 的致命缺陷是增量构建支持极差。例如，加载 defconfig 后运行 make，添加软件包后再次运行 make 可能正常工作，但修改软件包选项后，make 不会自动检测变更，也不会重建受依赖影响的其他软件包。虽然可使用 make [package]-rebuild 目标，但需了解软件包之间的依赖关系。大多数情况下，你可能会直接放弃，执行 make clean && make（注意：需先保存 Linux、U-Boot 和 Busybox 的配置修改，否则会被清除），从头重新构建 —— 即便启用编译器缓存，这一过程也耗时极长。坦白说，Buildroot 是我在这个项目中升级到 Threadripper 3970X 处理器的主要原因。
Yocto
Yocto 则完全相反。Buildroot 是 Busybox/uClibc 团队发起的小型项目，而 Yocto 是由行业巨头赞助的大型项目，包含众多组件。你可能会看到该构建系统被称为 Yocto、OpenEmbedded 和 Poky—— 发表本文前我做了一些调研，但仍未完全理解它们的关系。我认为第一个是总项目名称，第二个是基础软件包集合，第三个是…… 好吧，我还是不清楚。欢迎在评论区留言澄清。
我所知道的是：Yocto 使用基于 Python 的构建系统（BitBake），通过解析 “配方”（recipe）文件执行任务。配方可继承自其他配方，覆盖或追加任务、变量等。还有一个密切相关的独立 “机器”（Machine）配置系统，配方按类别分组为不同 “层”（layer）。
官方 Yocto 仓库包含多个层，层可单独授权和分发，因此许多公司维护自己的 “Yocto 层”（例如 meta-atmel），大型厂商甚至基于 Yocto 构建自己的发行版。TI 的 ProcessorSDK 基于其 Arago 项目架构（构建于 Yocto 之上），ST 的 OpenSTLinux 发行版也是如此。尽管 Yocto 发行商广泛使用 Google 的 repo 工具，但获取构建镜像所需的所有层仍十分繁琐，且不同厂商的层冲突时常导致奇怪的漏洞。
Buildroot 使用 Kconfig（支持 menuconfig），而 Yocto 的配置文件分散在各处：你肯定需要带文件浏览器的文本编辑器，且所有配置均基于文件，无 menuconfig 等图形界面，因此需随时查阅文档以理解参数名称和取值。其学习曲线极为陡峭。
不过，若仅需为现有板卡构建镜像，操作则极为简便：只需设置一个环境变量 MACHINE，指定目标板卡型号，然后运行 BitBake 命令构建所需镜像（例如 bitbake core-image-minimal）即可。
但作为硬件开发者，Yocto 让我失望的地方在于：它完全无意帮助你为新设计的定制板卡构建镜像。它并非原型开发初期（例如整个博客项目期间）快速整合内核 / U-Boot / 根文件系统的工具 —— 其设计理念决定了它永远不会成为这样的工具。它采用典型的软件工程设计思路，将封装、抽象和通用性置于首位。它不预设任何硬件相关信息，因此即便执行最简单的操作，也需修改大量配方并创建繁琐的文件覆盖。它不识别 DTS 文件，因此没有 “快速技巧” 来编译带有自定义 DTS 的 Linux 内核。甚至看似简单的操作 —— 如使用 menuconfig 修改内核配置并保存（避免被覆盖）—— 也会变得异常复杂。只需阅读 Yocto 指南的第 1 节，就能了解完成 Buildroot 中 “make linux-savedefconfig” 等效操作所需的步骤（注：公平地说，许多内核配方会在自身文件夹中内置硬编码的 defconfig 文件，因此通常可直接将内核构建目录中生成的 defconfig 文件复制到该位置 —— 但这依赖于内核配方的配置方式）。因此，若计划修改内核配置或 DTS 文件，我通常会采用极端方案：将整个内核复制到其他位置，然后将内核配方的 SRC_URI 指向该位置。
一旦内核和 U-Boot 可正常工作，且专注于优化根文件系统，Yocto 会是极佳选择。Yocto 的增量构建支持远优于 Buildroot—— 若修改某个软件包配置并重建，Yocto 会智能重建所有依赖该软件包的其他组件。Yocto 还支持轻松切换目标机器，并将软件包构建分类为机器专用（如内核）、架构专用（如 Qt5）和通用型（如 PNG 图标包）。由于无需不必要的重建，切换指令集相同的机器（如 ARMv7 架构）时，无需重新编译大量软件包，效率更高。
入门阶段可能难以察觉，但两者的核心区别在于：Yocto 构建的是 Linux 发行版，而 Buildroot 构建的是系统镜像。Yocto 了解每个软件组件及其依赖关系，因此可为平台构建软件包源，允许像桌面或服务器 Linux 一样，在嵌入式产品上远程安装和更新软件。这也是 Yocto 不将自己视为 Linux 发行版，而是 “构建 Linux 发行版的工具” 的原因。是否使用该功能需综合考量 —— 多数嵌入式 Linux 工程师更倾向于整体镜像更新，以避免异常情况。但如果项目的根文件系统达 500MB，通过网络推送此类镜像会消耗大量带宽（且 “下载中……” 进度条会让用户不满）。
项目初期，我本计划在 Buildroot 和 Yocto 之间切换使用，但最终全程使用 Buildroot（尽管我对 Yocto 的经验更丰富），这无疑是正确选择。诚然，这种方式看似繁琐：我需要为 10 款处理器构建镜像，因此保留了 10 个不同的 Buildroot 副本，每个对应一款板卡。这些文件夹中 90% 的二进制文件可能完全相同，而 Yocto 本可支持快速切换机器。但归根结底，Yocto 的设计初衷并非帮助开发者调试新硬件。尽管可行，但过程会异常痛苦。
