从单片机到u-boot：嵌入式Linux分水岭与QEMU ARM64实战

1. 从单片机到u-boot：为什么我劝你尽早跨过这道分水岭

如果你现在还在用51单片机点灯、调数码管、写1602液晶的驱动，或者刚用STM32跑通了一个TFT触摸屏程序，觉得自己已经“入门嵌入式”了，那我接下来要说的话可能会让你不太舒服：你离真正的嵌入式开发还有相当长的一段路。单片机那套东西——裸机跑while(1)大循环、手动管理每一个寄存器、中断里塞满业务逻辑——放在今天的嵌入式Linux和ARM64平台上，连“前菜”都算不上。真正让嵌入式工程师拉开差距的，是u-boot这个看似枯燥、实则决定整个系统能不能跑起来的关键组件。

我见过太多人卡在“单片机玩得很溜，但一碰嵌入式Linux就懵”的状态。他们能背出C51的每一个SFR地址，能手动配置STM32的时钟树，但面对u-boot的启动流程、设备树传递、DDR初始化、重定位这些概念时，完全不知道从哪下手。问题出在哪？出在思维模型没有切换。单片机是“你直接控制硬件”，而u-boot是“你为操作系统搭建一个能运行的环境”。前者是手工作坊，后者是城市规划。你不需要知道每一块砖怎么烧，但你必须清楚水电管网怎么铺、交通怎么组织、应急通道在哪。

这篇文章就是写给那些已经厌倦了在单片机圈子里打转、想真正踏入嵌入式Linux和ARM64世界的朋友。我会用QEMU模拟ARM64环境，带你从零把u-boot跑起来，拆解它的启动流程，解释每一个关键步骤背后的“为什么”，并分享我在实际移植和调试中踩过的坑。你不需要有一块真实的ARM64开发板，一台能跑Linux的电脑就够了。学完这一套，你再回头看单片机的那些东西，会有一种“降维打击”的清晰感。

注意：本文所有操作均在QEMU模拟环境中进行，不涉及任何真实硬件烧录，也不需要任何特殊网络配置。你只需要一个标准的Linux开发环境（Ubuntu 22.04或类似发行版即可）。

2. 核心思路拆解：为什么u-boot是嵌入式的分水岭

2.1 单片机思维与嵌入式Linux思维的本质差异

先把这个事情说透。单片机开发的核心逻辑是：上电→初始化时钟→配置外设→进入主循环。你写的每一行代码都直接对应硬件的一个动作。C51单片机里，你写P1 = 0xFE，P1口的8个引脚立刻输出对应的电平。STM32里，你配置GPIO的MODER寄存器，引脚方向就变了。这种“所见即所得”的控制感很爽，但它有一个致命局限：你写的所有代码都是为这一个特定芯片服务的。换一颗芯片，哪怕只是同系列不同型号，你的代码可能就要大改。

嵌入式Linux的思路完全不同。它把系统分成三层：引导加载程序（bootloader）→ 操作系统内核（kernel）→ 用户空间应用（rootfs）。u-boot就是最下面那一层。它的任务不是“控制硬件”，而是“把硬件准备好，然后把控制权交给内核”。这个“准备好”包括：初始化DDR内存控制器、配置时钟树、加载内核镜像到内存、准备设备树、设置内核启动参数。做完这些，u-boot就功成身退，把CPU控制权交给Linux内核。

为什么说这是分水岭？因为从这一刻起，你的代码不再直接控制硬件了。你写的是一个“环境搭建者”，而不是“硬件操作者”。你需要理解内存映射、地址空间、启动介质、镜像格式这些抽象概念。这些东西在单片机世界里几乎不存在——51单片机哪有DDR控制器？哪有设备树？哪有内核镜像加载？

2.2 为什么选择u-boot而不是其他bootloader

市面上bootloader不止u-boot一家。RedBoot、Barebox、Little Kernel（LK）都有人用。但u-boot是事实上的行业标准，原因有几个：

• 支持架构最全：ARM、ARM64、MIPS、PowerPC、RISC-V、x86，几乎你能想到的架构它都支持。这意味着你学一套东西，换平台时迁移成本极低。
• 驱动模型成熟：u-boot有自己的驱动模型（DM），支持设备树，和Linux内核的设计理念一脉相承。你学u-boot的过程，也是在为理解Linux内核打基础。
• 社区活跃：几乎每一款主流芯片原厂都会第一时间往u-boot主线提交支持代码。你遇到问题，搜到的答案大概率是有效的。
• 工具链完善：mkimage、dumpimage、fw_printenv这些工具让你可以方便地制作镜像、查看镜像信息、管理环境变量。

相比之下，LK更轻量，适合快速启动场景（比如Android设备），但生态和文档远不如u-boot。Barebox设计更现代，但用户基数小。对于想系统学习嵌入式Linux的人来说，u-boot是性价比最高的选择。

2.3 QEMU模拟ARM64：没有开发板也能学

很多人卡在“我没有ARM64开发板”这一步。树莓派算ARM64，但它是博通定制的SoC，u-boot支持并不主线化。NXP、瑞芯微、全志的开发板动辄几百上千块，对初学者不友好。QEMU解决了这个问题。

QEMU可以模拟一台完整的ARM64虚拟机，包括CPU、内存、串口、存储控制器。你可以在里面跑u-boot、加载内核、挂载rootfs，整个流程和真实硬件几乎一致。唯一的区别是：真实硬件上你需要用烧录器把u-boot写到SPI Flash或SD卡，QEMU里你只需要用-bios参数指定u-boot二进制文件。

提示：QEMU模拟的ARM64机器类型推荐用virt，这是QEMU专门为虚拟化设计的通用平台，设备树由QEMU动态生成，不需要你手动写DTS。对于学习u-boot启动流程来说，这是最省事的方案。

3. 环境搭建与工具链准备：从零把架子搭起来

3.1 安装交叉编译工具链

ARM64的u-boot需要在x86主机上编译，所以你需要一套AArch64的交叉编译工具链。Ubuntu下最方便的是直接装包：

sudo apt update sudo apt install gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu

装完之后验证一下：

aarch64-linux-gnu-gcc --version

你应该能看到类似gcc version 11.4.0的输出。这个工具链既能编译u-boot，也能编译Linux内核，一举两得。

如果你想要更新的版本，可以去ARM官方下载GNU Toolchain，但说实话，Ubuntu自带的版本对于学习u-boot来说完全够用。我试过用ARM官方12.x版本编译，和用Ubuntu自带的11.x版本编译，生成的u-boot二进制在QEMU里跑起来没有任何区别。

3.2 获取u-boot源码

u-boot的官方仓库在GitHub上，但国内直接clone可能比较慢。我一般用以下方式：

git clone https://source.denx.de/u-boot/u-boot.git cd u-boot git checkout v2024.01

这里我特意checkout到一个稳定tag，而不是用master分支。原因很简单：master分支每天都在变，可能今天能编译通过，明天就因为某个驱动改动而挂掉。对于学习来说，稳定性比新特性重要得多。v2024.01是我实测下来比较稳的一个版本，对QEMU ARM64 virt平台的支持很完善。

如果你clone速度慢，也可以直接下载tarball：

wget https://ftp.denx.de/pub/u-boot/u-boot-2024.01.tar.bz2 tar xf u-boot-2024.01.tar.bz2 cd u-boot-2024.01

3.3 安装QEMU

QEMU的安装更简单：

sudo apt install qemu-system-arm

注意包名是qemu-system-arm，它同时包含ARM32和ARM64的模拟支持。装完之后验证：

qemu-system-aarch64 --version

你应该能看到QEMU的版本信息。我推荐用6.0以上的版本，对ARM64 virt平台的支持更完善。

3.4 配置和编译u-boot

进入u-boot源码目录，执行：

make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- qemu_arm64_defconfig make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

第一行是加载QEMU ARM64的默认配置。这个defconfig已经帮你选好了所有必要的选项：串口用PL011、存储用virtio、内存布局适配QEMU virt平台。第二行是编译，-j$(nproc)表示用你CPU的所有核心并行编译，能快不少。

编译完成后，你会在根目录下看到u-boot.bin文件。这就是我们要的u-boot二进制。另外还有一个u-boot文件（ELF格式），包含符号信息，调试时用得上。

注意：如果你编译时报错说找不到dtc（设备树编译器），需要额外安装：sudo apt install device-tree-compiler。这个坑我踩过，因为u-boot编译过程中需要把DTS编译成DTB。

4. 启动流程深度解析：u-boot到底在干什么

4.1 从上电到串口输出：第一阶段发生了什么

当你用QEMU启动u-boot时，CPU从固定的复位向量地址开始执行。对于ARM64来说，这个地址是0x00000000或者由硬件配置决定的高地址。QEMU virt平台把u-boot加载到0x40000000（1GB地址处），然后跳转过去执行。

u-boot的第一阶段代码（SPL或TPL，如果启用的话）做的是最底层的事情：设置栈指针、初始化CPU关键寄存器、配置串口（如果启用了early debug）。在QEMU环境下，DDR已经由QEMU模拟好了，不需要我们初始化内存控制器，这省掉了最麻烦的一步。

但真实硬件上，DDR初始化是u-boot第一阶段最核心的任务。你需要根据DDR芯片的型号、频率、时序参数，配置内存控制器的几十个寄存器。这一步如果错了，整个系统连串口都出不来。我当年第一次移植u-boot到一块全志H3的板子上，就是因为DDR时序参数差了一个周期，导致系统随机死机，查了整整一周才找到问题。

4.2 重定位：u-boot为什么要“自己搬自己”

u-boot编译出来的链接地址通常是0x40000000（对于QEMU ARM64），但实际运行时，它可能被加载到其他地址。为了让代码能正确运行，u-boot会把自己重定位到内存的高端地址（通常是RAM的顶部附近）。这个过程叫relocation。

为什么要多此一举？因为u-boot需要为内核和rootfs留出连续的低端内存空间。如果u-boot一直占着0x40000000不放，内核就没法加载到预期地址。重定位之后，u-boot把自己搬到高端地址，低端内存就空出来了。

重定位的实现涉及位置无关代码（PIC）的概念。u-boot通过gd->relocaddr记录重定位后的地址，所有绝对地址引用都需要加上偏移。这个过程在board_init_r函数中完成，你可以通过串口输出看到类似这样的信息：

Relocating to 0x7ff00000, new gd at 0x7feff000

4.3 设备树传递：内核怎么知道硬件长什么样

设备树（Device Tree）是嵌入式Linux最核心的抽象之一。它用文本格式（DTS）描述硬件信息：CPU有几个核、内存多大、串口在哪个地址、中断怎么连。u-boot的任务之一就是把设备树二进制（DTB）加载到内存，并把地址告诉内核。

在QEMU virt平台上，设备树是由QEMU动态生成的，u-boot通过-dtb参数或者内置的DTB来获取。启动内核时，u-boot会把DTB的地址写入x0寄存器（ARM64的约定），内核启动后从x0读取设备树。

提示：你可以用dtc -I dtb -O dts -o output.dts input.dtb命令把DTB反编译成DTS，看看QEMU到底生成了什么样的设备树。这对于理解设备树的结构非常有帮助。

4.4 内核启动参数：bootargs怎么传

u-boot通过bootargs环境变量把启动参数传给内核。这些参数包括：控制台设备（console=ttyAMA0）、根文件系统位置（root=/dev/vda）、内存大小（mem=1G）等。内核启动时会解析这些参数，决定从哪里挂载rootfs、用哪个串口输出日志。

在QEMU环境下，一个典型的bootargs是这样的：

console=ttyAMA0 root=/dev/vda rw

ttyAMA0是PL011串口的设备名，/dev/vda是virtio块设备的第一个分区。这些名字不是随便起的，它们对应设备树里的节点名称。如果你改了设备树，这些名字也要跟着改。

5. 实操全流程：在QEMU里把u-boot跑起来

5.1 启动u-boot并进入命令行

编译完成后，用以下命令启动QEMU：

qemu-system-aarch64 \ -M virt \ -cpu cortex-a57 \ -nographic \ -bios u-boot.bin \ -m 1G

参数解释：

• -M virt：使用QEMU的通用虚拟平台
• -cpu cortex-a57：模拟Cortex-A57 CPU，这是ARM64的经典核心
• -nographic：不使用图形界面，串口输出直接打到终端
• -bios u-boot.bin：把u-boot二进制作为BIOS加载
• -m 1G：给虚拟机分配1GB内存

执行后，你应该能看到u-boot的启动日志，最后停在=>提示符。这就是u-boot的命令行界面。

5.2 常用命令实操

在u-boot命令行里，你可以执行很多有用的命令：

=> bdinfo

这个命令打印板级信息：内存起始地址、内存大小、环境变量保存位置、波特率等。我一般用这个命令确认u-boot是否正确识别了内存布局。

=> printenv

打印所有环境变量。你会看到bootargs、bootcmd、baudrate等。bootcmd是u-boot启动后自动执行的命令序列，默认可能是空的或者指向网络启动。

=> mmc list

列出所有MMC设备。在QEMU virt平台上，如果你没有挂载虚拟SD卡，这个命令会返回空。但你可以用virtio list查看virtio设备。

=> virtio list

列出virtio设备。如果你启动QEMU时加了-drive file=rootfs.img,if=virtio,format=raw，这里就能看到virtio块设备。

5.3 手动加载内核并启动

假设你已经编译好了一个ARM64 Linux内核（Image文件）和一个设备树（virt.dtb），你可以用以下命令手动启动：

=> load virtio 0:0 0x41000000 Image => load virtio 0:0 0x42000000 virt.dtb => setenv bootargs "console=ttyAMA0 root=/dev/vda rw" => booti 0x41000000 - 0x42000000

load命令从virtio设备的第一个分区加载文件到指定内存地址。booti是ARM64专用的启动命令，参数依次是：内核镜像地址、initrd地址（-表示没有）、设备树地址。

执行booti后，CPU控制权交给内核，你会看到Linux内核的启动日志。如果一切正常，最后会进入登录提示或者shell。

5.4 制作可启动的SD卡镜像

在真实硬件上，你需要把u-boot写到SD卡的特定偏移处。QEMU里也可以模拟这个过程：

dd if=/dev/zero of=sdcard.img bs=1M count=64 dd if=u-boot.bin of=sdcard.img conv=notrunc bs=512 seek=1

第一行创建一个64MB的空镜像，第二行把u-boot写到偏移512字节处（跳过MBR分区表）。然后启动QEMU时用-drive file=sdcard.img,if=sd,format=raw挂载这个镜像。

注意：真实硬件上u-boot的写入偏移取决于SoC的启动ROM要求。比如全志的芯片通常要求写在8KB偏移处，瑞芯微的芯片要求写在32KB偏移处。这个偏移量在芯片手册的“Boot ROM”章节里有详细说明，写错了系统根本起不来。

6. 常见问题与排查技巧实录

6.1 u-boot启动后没有任何输出

这是最常见的问题。排查思路如下：

我遇到过一次，编译出来的u-boot在QEMU里完全没输出。后来发现是CONFIG_DEBUG_UART没有使能，early debug串口没初始化。在defconfig里加上CONFIG_DEBUG_UART=y和CONFIG_DEBUG_UART_BASE=0x9000000（QEMU virt平台的PL011串口地址）就好了。

6.2 内核启动后卡在“Starting kernel...”

这个问题的原因通常是设备树地址传错了，或者内核镜像格式不对。ARM64内核必须是Image格式（未压缩的原始二进制），不能是zImage或bzImage。你可以用file命令检查：

file arch/arm64/boot/Image

输出应该是Linux kernel ARM64 boot executable Image。如果是gzip compressed data，说明你拿的是压缩过的内核，需要用booti而不是bootz。

另一个常见原因是bootargs里的console参数写错了。QEMU virt平台的串口是ttyAMA0，不是ttyS0。写错了内核日志就出不来了。

6.3 环境变量保存失败

u-boot默认把环境变量保存在CONFIG_ENV_OFFSET指定的存储偏移处。在QEMU里如果没有配置可写的存储设备，saveenv命令会失败。解决方法是在QEMU启动参数里加一个可写的virtio块设备：

-drive file=env.img,if=virtio,format=raw

然后在u-boot里配置CONFIG_ENV_IS_IN_VIRTIO=y和CONFIG_ENV_VIRTIO_DEV=0。这样saveenv就能把环境变量写到virtio设备里了。

6.4 QEMU退出后重新启动，环境变量丢失

这是因为QEMU默认不保存virtio设备的状态。你需要确保env.img文件在QEMU退出后没有被删除，并且下次启动时用同样的-drive参数挂载。我一般会创建一个固定大小的文件：

dd if=/dev/zero of=env.img bs=1M count=1

然后每次启动QEMU都挂载这个文件。这样环境变量就能持久化了。

7. 从u-boot延伸出去：下一步该学什么

7.1 深入设备树：从消费者变成生产者

u-boot帮你把设备树加载到内存，但设备树本身是怎么来的？QEMU virt平台的设备树是QEMU动态生成的，但真实硬件上，设备树是芯片原厂或板级厂商写的。你需要学会阅读DTS文件，理解compatible属性、reg属性、interrupts属性的含义。

我建议你从QEMU生成的设备树开始，用dtc反编译成DTS，然后对照Linux内核源码里的Documentation/devicetree/bindings/目录，逐个理解每个节点的含义。等你能够自己写一个简单的DTS，描述一个虚拟的I2C设备，你就真正掌握了设备树。

7.2 移植u-boot到真实硬件

QEMU是学习工具，但最终你还是要面对真实硬件。移植u-boot到一块新板子的流程大致是：

1. 找到芯片原厂的u-boot源码（通常叫BSP）
2. 在board/目录下创建板级目录
3. 在configs/目录下创建defconfig
4. 在arch/arm/dts/目录下添加设备树
5. 配置DDR初始化参数（这是最难的一步）
6. 配置串口、存储、网络等外设
7. 编译、烧录、调试

每一步都有坑，但有了QEMU里的经验，你至少知道u-boot的启动流程是什么样的，调试时能快速定位问题出在哪个阶段。

7.3 理解SPL和TPL：u-boot的自我进化

现代SoC的启动流程通常是：Boot ROM → SPL → u-boot proper → Linux内核。SPL（Secondary Program Loader）是一个精简版的u-boot，只做最核心的DDR初始化和加载u-boot proper。TPL（Tertiary Program Loader）更精简，用于DDR还没初始化时的SRAM运行。

理解SPL和TPL的分工，对于调试启动问题至关重要。如果你的板子上电后串口没有任何输出，问题可能出在SPL阶段，而不是u-boot proper阶段。你需要用示波器或者JTAG来确认SPL是否执行了。

7.4 从u-boot看Linux内核的启动

u-boot的最后一个动作是跳转到内核入口。ARM64内核的入口地址在arch/arm64/kernel/head.S。内核启动后会重新初始化MMU、设置页表、解析设备树、初始化各个子系统。如果你理解了u-boot怎么把参数传给内核，再看内核的启动代码就会顺畅很多。

我个人的经验是：把u-boot的booti命令和内核的head.S对照着看，你会对“引导加载程序”和“操作系统”之间的边界有非常清晰的认识。这个边界就是嵌入式Linux开发的核心分界线。

最后分享一个小技巧：在u-boot里用md命令查看内存内容，用mw命令修改内存，用cmp命令比较内存。这些命令在调试内核加载问题时非常有用。比如你可以用md 0x41000000 0x10查看内核镜像的前16个字，确认它是否被正确加载到了内存中。