4、U-Boot编译流程：从源码到u-boot.bin的完整编译过程

说实话，很多初学者拿到U-Boot源码后，第一反应就是直接敲个make，然后等着出镜像。但这样做往往会在各种莫名其妙的报错中浪费大量时间。我刚开始接触U-Boot移植时也踩过这个坑——编译出来的bin文件死活跑不起来，后来才发现是编译流程中某个中间步骤出了问题。

这一章，我就带你完整走一遍U-Boot的编译流程。从源码到最终的u-boot.bin，每一步发生了什么，生成了什么文件，我都会讲清楚。你想想看，搞懂了这些，以后遇到编译问题就能快速定位，不用再瞎猜了。

4.1 配置阶段：告诉U-Boot你要做什么

编译的第一步不是编译，而是配置。说白了，就是告诉U-Boot：「我要给哪块板子编译？要支持哪些功能？」。这个阶段的核心产物是.config文件。

我个人习惯在移植新板子时，先找一个相近的参考板配置，然后在此基础上修改。比如你要移植一块基于i.MX6ULL的板子，可以先执行：

make mx6ull_14x14_evk_defconfig

这条命令会做三件事：

1. 读取默认配置：从configs/目录下找到对应的mx6ull_14x14_evk_defconfig文件
2. 生成.config：将默认配置写入顶层目录的.config文件
3. 生成auto.conf：将.config转换为C语言可用的宏定义，存放在include/config/auto.conf

这里有个容易忽略的点：include/config/auto.conf是在配置阶段自动生成的，它会被Makefile包含。如果你手动修改了.config，记得重新执行make，否则auto.conf不会更新。

4.2 预处理阶段：宏展开与条件编译

配置完成后，进入预处理阶段。这个阶段由C预处理器（CPP）完成。它会处理所有的#include、#define、#ifdef等预处理指令。

U-Boot源码中大量使用了条件编译。举个例子：

#ifdef CONFIG_CMD_NAND
    /* NAND相关命令的实现 */
    do_nand_cmd();
#endif

如果.config中没有定义CONFIG_CMD_NAND，这段代码在预处理阶段就会被直接删除，根本不会进入编译阶段。这就是为什么配置阶段如此重要——它决定了哪些代码最终会被编译进去。

我在项目中遇到过一个问题：明明在.config里打开了某个功能，但编译出来的镜像却没有包含它。后来发现是include/configs/目录下的板级头文件里，有一个#undef CONFIG_xxx把配置给覆盖了。嗯，这里要注意，U-Boot的配置优先级是：include/configs/下的头文件 > .config。

4.3 编译阶段：从.c到.o

预处理完成后，每个.c文件会被编译成对应的.o目标文件。这个阶段由交叉编译器完成，比如arm-linux-gnueabihf-gcc。

编译命令大致是这样的：

arm-linux-gnueabihf-gcc -c -o file.o file.c \
    -I./include \
    -I./arch/arm/include \
    -DCONFIG_SYS_TEXT_BASE=0x87800000 \
    -Os -g -fno-builtin

注意几个关键点：

• -I：指定头文件搜索路径，U-Boot的头文件分散在include/、arch/arm/include/等多个目录
• -D：通过命令行定义宏，比如CONFIG_SYS_TEXT_BASE定义了U-Boot的运行基地址
• -Os：优化尺寸，U-Boot对体积有严格要求，毕竟它要放在有限的存储空间里
• -fno-builtin：不使用GCC内置函数，避免与U-Boot自带的函数实现冲突

编译阶段会生成大量的.o文件，它们分散在源码的各个子目录中。你可以在arch/arm/cpu/、common/、drivers/等目录下找到它们。

4.4 链接阶段：拼装成完整的ELF

所有.o文件编译完成后，链接器（LD）将它们合并成一个完整的ELF文件——u-boot。这个阶段的核心是链接脚本u-boot.lds。

链接脚本定义了各个段的排列顺序和加载地址。U-Boot的链接脚本通常位于arch/arm/cpu/u-boot.lds（ARM架构为例）。它的核心内容大致如下：

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)

SECTIONS
{
    . = 0x87800000;  /* 起始地址 */

    .text : {
        *(.text._start)   /* 入口代码 */
        *(.text*)         /* 其他代码段 */
    }

    .rodata : { *(.rodata*) }  /* 只读数据 */

    .data : { *(.data*) }      /* 读写数据 */

    .bss : { *(.bss*) }        /* 未初始化数据 */
}

这里有个关键点：ENTRY(_start)指定了程序的入口点是_start符号。这个符号定义在arch/arm/lib/vectors.S中，是U-Boot的第一条指令。

链接完成后，生成的u-boot文件是ELF格式的。它包含了调试信息、符号表等元数据，不能直接烧录到Flash中。这就是为什么还需要下一步——格式转换。

4.5 格式转换：生成可烧录的镜像

格式转换阶段使用objcopy工具，从ELF文件中提取出纯二进制数据。命令大致如下：

arm-linux-gnueabihf-objcopy -O binary u-boot u-boot.bin

这条命令做了两件事：

• 去除ELF头部：ELF文件有文件头、段头表等结构，这些在裸机环境下不需要
• 提取纯数据：只保留.text、.rodata、.data、.bss段的内容，按顺序拼接成连续的二进制流

除了u-boot.bin，U-Boot还会生成其他格式的镜像：

文件	格式	用途
u-boot	ELF	调试用，包含符号表，可用GDB加载
u-boot.bin	纯二进制	直接烧录到Flash，最常用
u-boot.img	带U-Boot头部	包含校验和、加载地址等信息，用于U-Boot自身加载
u-boot.srec	SREC	文本格式的二进制，用于串口下载

4.6 编译流程中的关键文件一览

为了让你对整个编译流程有个更清晰的印象，我把每个阶段的关键输入输出文件整理成了表格：

阶段	输入	输出	关键工具
配置	configs/xxx_defconfig	.config, auto.conf	make
预处理	.c文件	.i文件（预处理后的源码）	cpp
编译	.c / .S文件	.o目标文件	gcc
链接	所有.o文件 + u-boot.lds	u-boot（ELF）	ld
格式转换	u-boot（ELF）	u-boot.bin等	objcopy

4.7 一个完整的编译命令示例

最后，我给你一个完整的编译命令序列。假设你正在移植一块基于ARM Cortex-A7的板子：

# 1. 配置
make myboard_defconfig

# 2. 编译（包含预处理、编译、链接、格式转换）
make -j4

# 3. 查看生成的镜像
ls -lh u-boot*
# 输出示例：
# -rwxrwxr-x 1 user user 1.2M u-boot          # ELF文件
# -rw-rw-r-- 1 user user 512K u-boot.bin      # 纯二进制
# -rw-rw-r-- 1 user user 516K u-boot.img      # 带头部

你可能会问：为什么u-boot有1.2MB，而u-boot.bin只有512KB？因为ELF文件包含了大量的调试信息和符号表，这些在运行时是不需要的。所以实际烧录到板子上的，永远是u-boot.bin。