1. 课程导入

大家好，欢迎来到这门实战课。我是你们的老朋友，一个在嵌入式底层摸爬滚打了十几年的工程师。

咱们第一讲，先聊聊 U-Boot 到底是什么。说白了，它就是嵌入式 Linux 系统上电后运行的第一个用户程序。你想想看，一块开发板或者一个产品，CPU 一上电，内部固化的 ROM 代码会先跑一小段，然后就把控制权交给了 U-Boot。所以，它是硬件和操作系统之间的桥梁。

1.1 U-Boot 的历史：从 8 位机到多核 ARM

U-Boot 的历史挺有意思的。它最早可以追溯到 1999 年的 PPCBoot，当时主要是给 PowerPC 架构用的。后来，随着 ARM 架构的崛起，社区把 PPCBoot 和 ARMBoot 合并，在 2002 年正式改名为 U-Boot。

我记得刚入行那会儿，还在用 U-Boot 1.1.x 版本，那时候代码结构还比较“朴素”。现在呢？已经发展到 2024.x 版本了，支持几十种 CPU 架构，从 ARM、RISC-V 到 x86、MIPS，几乎全覆盖。

为什么它能活这么久？我觉得有两点：

• 开源社区的持续维护：Denx 公司主导，全球开发者贡献补丁。
• 极强的硬件适应性：从 8 位微控制器到 64 位多核处理器，它都能跑。

1.2 U-Boot 的核心功能

U-Boot 到底能干什么？我把它拆成几个关键点，你一看就明白。

功能模块	具体作用	我遇到的坑
硬件初始化	设置时钟、DDR 内存、串口、存储控制器等	DDR 时序配错，板子直接“变砖”
引导加载	从 Flash、SD 卡、网络等介质读取内核和设备树	网络启动时 TFTP 超时，原来是网口 PHY 没配好
命令行交互	提供 Shell 环境，用于调试、烧写、配置	printenv 和 setenv 是我最常用的两个命令
环境变量管理	存储启动参数、IP 地址、启动命令等	环境变量损坏，导致启动失败，后来我学会了备份
设备树支持	传递硬件描述信息给内核（FDT）	设备树里 GPIO 编号写错，外设死活不工作

嗯，这里要注意一点：U-Boot 的硬件初始化是“轻量级”的。它不会像 Linux 内核那样把所有驱动都加载一遍，而是只初始化启动内核所必需的最小硬件集合。比如 DDR、串口、存储控制器。其他的，比如 GPU、声卡，它根本不管。

1.3 在嵌入式系统中的地位

U-Boot 在嵌入式系统里到底有多重要？我打个比方：它就像大楼的“地基”和“电梯”。没有它，内核这个“住户”根本进不了门，更别提运行了。

具体来说，它的地位体现在这几个方面：

• 启动链的第一环：上电 -> ROM 代码 -> SPL（Secondary Program Loader）-> U-Boot -> 内核。U-Boot 是用户可控的第一个环节。
• 硬件抽象层：它把不同板子的硬件差异“消化”掉，让同一个内核镜像可以在不同硬件上启动。这就是设备树（Device Tree）的功劳。
• 调试利器：在产品开发阶段，U-Boot 的命令行是排查硬件问题的第一道防线。比如，用 md 命令读内存，用 mm 命令写寄存器，比用示波器还快。
• 量产烧写的核心：在工厂里，U-Boot 通常被用来烧写内核、文件系统到 Flash 中。它支持网络、USB、SD 卡等多种烧写方式。

1.4 U-Boot 的启动流程概览

为了让你对 U-Boot 有个整体印象，我画了一张流程图。这张图会贯穿我们整个课程，现在先混个脸熟。

这张图展示了从芯片上电到内核启动的完整链路。你会发现，U-Boot 并不是一步到位的，它分成了 SPL 和主程序两个阶段。为什么要这么设计？因为早期的嵌入式芯片内部 SRAM 很小，装不下完整的 U-Boot，所以先跑一个“迷你版”的 SPL，把 DDR 初始化好，再把完整的 U-Boot 从 Flash 搬到内存里运行。

我个人觉得，理解这个流程是移植 U-Boot 的第一步。你只有知道它在哪个阶段干了什么事，出了问题才能快速定位。比如，串口没打印，那大概率是 SPL 阶段就挂了；如果打印到一半卡住，那可能是 DDR 配置有问题。

1.5 为什么选择 U-Boot？

市面上也有其他 Bootloader，比如 RedBoot、GRUB、Coreboot。为什么 U-Boot 成了嵌入式 Linux 的事实标准？

• 硬件支持最广：几乎你能想到的嵌入式 SoC，都有现成的 U-Boot 移植。
• 社区活跃：邮件列表、补丁提交、问题修复，响应速度很快。
• 功能丰富：网络启动、USB 烧写、文件系统支持、加密验证，一应俱全。
• 可定制性强：通过 Kconfig 和设备树，你可以只编译自己需要的功能，减小体积。