自己在一线做嵌入式开发这些年打交道最多的就是uboot。手上有块imx6ull开发板刚开始移植uboot时照着教程敲了一行make mx6ull_14x14_evk_defconfig然后又敲了一行make -j4屏幕刷刷刷跑了一堆编译信息最后生成了u-boot.imx。文件是出来了但你要问我这中间到底经历了什么当时是真答不上来。后来做4412移植、imx6ull适配把编译流程完整啃了一遍才算是真正搞明白uboot这套编译体系。这篇就把uboot编译流程拆开讲透从交叉编译工具链到make xxx_defconfig的配置原理从顶层Makefile的依赖关系说到u-boot.imx是怎么拼出来的再结合imx6ull和4412这两个平台的实操对照把我踩过的坑和排查思路一并写清楚。适合正在学uboot、准备做板级移植、或者想搞懂“uboot编译到底在干什么”的嵌入式开发者。1. uboot编译流程全景先搞清楚你在编译什么uboot的编译和普通Linux应用程序编译完全是两回事。应用软件拿gcc一编出来一个可执行文件就完事了uboot不一样它是个bootloader最终要跑在特定的CPU架构、特定内存布局、特定启动介质上。所以uboot的编译体系天生就是配置编译两层结构并且针对不同厂商的芯片还会在编译后做额外的镜像封装。1.1 为什么uboot编译不是简单一个make就能搞定这里要先理解一个基本逻辑uboot源码是通用的可以支持几十个架构、几百块开发板。但每一块板子的CPU型号、DDR初始化参数、启动方式、外设配置都不一样。如果编译时不做区分出来的镜像没有任何一片板子能跑。所以uboot把“通用源码”和“板级配置”彻底分开。make xxx_defconfig这一步就是选定板级配置生成.config文件make这一步才是根据.config去编译源码、链接镜像。这个思路和Linux内核编译完全一样因为uboot的构建体系本身就是从Linux内核的Kbuild系统继承而来的。实际操作中我经常看到新手跳过make xxx_defconfig直接make结果报一堆 undefined reference 或者找不到头文件的错误。原因就是没有配置阶段很多自动生成的头文件根本不存在。1.2 编译产物全家福u-boot、u-boot.bin、u-boot.imx、SPL/MLO分别是什么编译完成后源码根目录下会生成一大堆名字以u-boot开头的文件很多人会懵到底哪个才是要烧进板子的我通常这么给团队新人解释这些文件其实是一条生产链上的不同形态产物格式作用u-bootELF带调试信息、带符号表的原始链接产物主要用于gdb调试和查看内存布局u-boot.bin纯二进制去掉了ELF头部的裸机指令流是uboot本体很多平台直接烧这个u-boot.imx带头部/IVT/DCD的二进制NXP i.MX系列专用镜像在u-boot.bin前面加了一段BootROM要求的数据结构u-boot.srec / u-boot.hex文本化二进制用于串口、仿真器下载调试SPL/MLO精简版uboot片内SRAM太小装不下完整uboot时先跑一个小的SPL初始化DDR再加载完整uboot如果你用的是三星4412经典做法是生成u-boot.bin配合芯片的BL1和tzsw一起烧写如果你用的是NXP imx6ull烧的是u-boot.imx。这就是为什么不同板子的编译教程里最终烧写的文件不太一样。2. 编译前的准备工作工具链、环境变量和底层配置逻辑在敲任何make命令之前先把工具链和编译环境理顺。这块卡住的时间往往比真正编译多得多。2.1 交叉编译工具链的选择与验证uboot是跑在ARM核上的但编译是在PC上做的这就必须有交叉编译工具链。选择工具链的原则很简单优先使用芯片厂商SDK里自带的其次用对应架构官方维护的版本。imx6ull平台我常用的是arm-linux-gnueabihf-系列工具链4412平台早期常用arm-none-eabi-或者CodeSourcery的工具链。核心要求是两点第一工具链必须支持目标CPU的浮点架构。imx6ull的Cortex-A7默认是硬浮点如果你的工具链是软浮点的编译出来的uboot在启动时很容易跑飞。第二编译器版本不能太老也不能太新。太老的gcc比如4.4以下对uboot源码里一些新的语法支持不好太新的gcc比如10以上开了高优化等级后可能触发uboot老代码里的一些未定义行为。我实测gcc 7.5和gcc 9.x编imx6ull的uboot都没问题。装完工具链第一件事不是急着编译而是确认它能跑arm-linux-gnueabihf-gcc -v如果输出一串版本信息说明工具链可执行文件在PATH里。如果提示command not found那就是没有把工具链的bin目录加进环境变量或者工具链本身还需要更高版本的glibc支持。2.2 make xxx_defconfig 背后到底做了什么所有xxx_defconfig文件都放在源码根目录的configs/目录下。imx6ull常见的几个ls configs/ | grep mx6ull会看到mx6ull_14x14_evk_defconfig这类文件。执行make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- mx6ull_14x14_evk_defconfig这行命令做什么它调用的是顶层Makefile里的%config规则最终执行scripts/kconfig/conf工具读取configs/mx6ull_14x14_evk_defconfig的内容经过Kconfig的依赖解析后生成根目录下的.config文件同时生成include/config.h、include/config/auto.conf和include/generated/autoconf.h。这里要特别提醒一个经验不要手动去改动.config之后直接编译。.config是配置过程的产物改它不如改defconfig。因为.config每次make distclean之后就会消失而真正入库管理、用于重新生成配置的是configs/目录下的defconfig文件。这在多人协作和版本维护时尤其重要。3. 核心编译阶段make命令背后的完整链路拆解配置完成之后就进入真正耗时耗力的编译阶段。整个过程看起来就是屏幕上滚动日志背后其实分了好几个层次逐步生成依赖、编译子目录、生成链接脚本、链接ELF、转二进制、封装镜像。3.1 顶层Makefile与子目录的联动关系uboot的构建系统本质上是一个递归式Makefile集合。顶层Makefile负责全局规则每个子目录比如drivers/net/、drivers/mmc/、arch/arm/cpu/armv7/都有自己的Makefile负责把当前目录下的源码编译成built-in.o。编译时顶层Makefile按.config中的配置项决定哪些目录参与编译。比如配置了CONFIG_MMC就会进入drivers/mmc/目录把它下面的built-in.o编出来如果没有配置整个MMC驱动目录动都不会动。结构上非常像Linux内核这也是uboot和Linux内核能共用一套Kbuild机制的原因。你在编译日志里看到的LD drivers/mmc/built-in.o就是这个阶段的工作。它先把目录内所有的.o文件用ld -r合并成一个局部的built-in.o最后在顶层统一链接。很多新手在加驱动时直接把.c文件扔进目录发现编译根本没反应就是因为没有修改对应目录的Makefile没有把新文件挂到obj-y或obj-$(CONFIG_XXX)上。3.2 链接脚本u-boot.lds的生成过程与内存布局约束uboot最终能启动最关键的是链接地址是否正确。这个地址由链接脚本和一个关键配置项决定。imx6ull的uboot链接脚本源头在arch/arm/cpu/armv7/u-boot.lds但实际编译用的u-boot.lds是由这个源文件经过C预处理器展开后生成的。为什么要经过预处理因为链接脚本里有些地址宏来自配置头文件比如#ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0x87800000 #endifCONFIG_SYS_TEXT_BASE就是uboot的链接起始地址。imx6ull的DDR地址范围是0x80000000开始uboot一般链接在0x87800000即DDR偏移128MB处这样前面留出一段空间给其他镜像或者传递参数用。编译日志里会看到CPP u-boot.lds这行命令做的就是把源代码里的宏展开生成带具体地址的链接脚本。你可以用以下命令查看最终脚本内容head -50 u-boot.lds会看到类似. 0x87800000; .text : { *(.__image_copy_start) *(.vectors) *(.text*) }这个. 0x87800000就是整个uboot镜像的基地址。如果你在移植过程中发现uboot能在内存里启动但没法从DDR直接运行第一个检查点就是这个基地址是否和板子DDR实际地址匹配。3.3 从ELF到u-boot.binobjcopy与relocate机制的配合链接生成的u-boot是ELF格式。ELF有文件头、有段表、有调试信息CPU不关心这些它只关心跳转进去之后第一条指令是什么。所以必须用objcopy去掉所有冗余信息提取出纯二进制指令流arm-linux-gnueabihf-objcopy -O binary u-boot u-boot.bin这里补充一个关键点uboot运行早期会把自己从Flash或SD卡里重定位到DDR的高地址处执行。这个重定位机制靠的是二进制镜像里的符号表和__image_copy_start、__image_copy_end这两个链接脚本标记。所以u-boot.bin不是简单把ELF转成bin就完了它的代码段里已经准备好了重定位所需的地址表。如果你用arm-linux-gnueabihf-nm u-boot | grep __rel_dyn_start能看到重定位表相关的符号这些符号正是uboot自己把自己搬到正确位置时使用的。3.4 从u-boot.bin到u-boot.imxmkimage添加IVT与DCD数据这是NXP i.MX平台的特色环节。i.MX6ULL芯片内部的BootROM在上电后会尝试从启动介质读取镜像。但BootROM不知道DDR怎么初始化如果直接加载uboot到DDR里DDR根本没工作所以BootROM要求镜像前面带一个头。这个头叫IVTImage Vector Table里面包含程序入口地址、DCDDevice Configuration Data指针等信息。DCD数据就是一串初始化寄存器表BootROM解析它先把DDR初始化好再加载主体uboot代码。编译日志里类似MKIMAGE u-boot.imx的实现其实是调用了tools/mkimage工具./tools/mkimage -n board/freescale/mx6ullevk/imximage.cfg -T imximage -e 0x87800000 -d u-boot.bin u-boot.imx其中imximage.cfg里就是DCD寄存器初始化表由板级目录下的.cfg文件预处理后生成。这也是为什么imx6ull移植时SDK里常说“DDR初始化在cfg文件里改”——改的是这里。如果你做4412移植流程会有些区别4412没有用这一套它的BL1和uboot是分开的。但理解mkimage这一层的意义在于不同厂商的封装格式恰恰是移植适配的差异化点。3.5 从源码到SPL/MLO的独立编译链部分平台因为没有足够的SRAM加载完整uboot于是需要SPL。SPL是uboot的一个子项目代码在spl/目录编译时由顶层Makefile根据配置决定是否生成。日志里你会看到LD spl/u-boot-spl OBJCOPY spl/u-boot-spl.binSPL的代码很小只做最基本的初始化初始化时钟、初始化DDR、从启动介质读取完整uboot到DDR、然后跳转执行。TI平台习惯叫MLO三星平台也有类似的概念。它的编译流程和主uboot差不多但是使用独立的链接脚本spl/u-boot-spl.lds并且CONFIG_SPL_BUILD这个宏会在编译SPL时自动定义源码里大量#ifdef CONFIG_SPL_BUILD就是干这个用的。4. 平台实操对照imx6ull与4412的uboot编译移植实录说了这么多理论落地到两个经典平台上跑一遍编译流程的共性和差异就一目了然。4.1 imx6ull完整编译步骤与常见烧写姿势我以正点原子imx6ull开发板的uboot编译为例完整步骤是make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- distclean make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- mx6ull_14x14_evk_defconfig make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- -j4等待编译结束后重点看这几个文件ls -l u-boot.imx u-boot.bin u-boot其中u-boot.imx就是最终要烧写到SD卡或EMMC的镜像。注意生成u-boot.imx这个步骤需要mkimage工具很多老版本的源码里mkimage生成的阶段会报错mkimage: command not found解决办法是在PC上安装对应工具或者确保编译环境里有u-boot-tools。烧写方式可以用ddsudo dd ifu-boot.imx of/dev/sdb bs512 seek2 convfsync这里的seek2意味着镜像写入SD卡的第2个扇区因为i.MX6ULL的BootROM要求IVT位于SD卡的1KB偏移处正好是第2个扇区的起始位置。这些细节虽然不属于编译本身但移植调试时烧错位置镜像编得再对也起不来。4.2 4412平台uboot编译流程的差异点分析4412平台的uboot编译以老版本的uboot为例make ARCHarm CROSS_COMPILEarm-none-eabi- smdk4412_config make ARCHarm CROSS_COMPILEarm-none-eabi- -j4有些用tiny4412_defconfig的仓库则用make ARCHarm CROSS_COMPILEarm-none-eabi- tiny4412_defconfig make ARCHarm CROSS_COMPILEarm-none-eabi- -j44412和imx6ull最大的差异是4412没有DCD那套东西它的镜像通常是u-boot.bin要和三星的BL1如 E4412_N.bl1以及tzsw按固定布局组合烧写。三星的BL1负责最基础的时钟和DDR初始化u-boot.bin则是二级引导程序。编译后常出现的错误之一是老版本uboot在较新gcc下编译不过报multiple definition of ...或者string.h相关错误很多情况是因为工具链版本差异导致的隐式函数声明规则不同。这种情况我处理过多次最有效的办法是换回平台验证过的老工具链而不是去改uboot源码。4.3 如何快速验证编译产物是否正常编译完之后不要急着烧板子先做三件事验证产物。第一看文件大小。u-boot.imx一般一两百KB如果编译出来只有几十字节不用想链接阶段出问题了。第二看文件头。用hexdump查看u-boot.imx的开头字节hexdump -C u-boot.imx | head -20正常能看到DCD数据、地址信息等有规律的结构。如果全是FF或者全是00说明mkimage步骤没正确执行。第三最直接的验证是烧到板子看串口输出。烧写后如果串口能打出U-Boot SPL ...或者uboot的版本信息、编译时间说明整个编译链路和镜像封装都正常。这一步才是终极验证。5. 常见编译错误与排查经验实录最后把这几年编译uboot时踩过的坑集中整理一下每一类问题都给出排查路径。5.1 高频错误类型与速查表错误现象根本原因解决方法arm-linux-gnueabihf-gcc: Command not found工具链bin目录没加进PATHexport PATH$PATH:/opt/toolchain/bin*** No rule to make target xxx_defconfigconfigs目录下没有这个名字的defconfigls configs/ | grep xxx确认准确名称bison: command not found缺少Kconfig依赖工具安装bison flex及相关包mkimage: command not foundmkimage在PATH中找不到安装u-boot-tools或确认tools/mkimage已生成undefined reference to main链接脚本或入口函数异常检查u-boot.lds的ENTRY和C代码入口multiple definition of xxx多个源文件定义了同名全局符号检查是否有重复文件加入编译配合make V1定位编译时头文件报错typedef redefinition配置头文件被重复包含或include顺序异常make distclean后重新配置编译镜像烧进去启动无反应镜像格式、链接地址、烧写偏移任一不对依次检查u-boot.imx头、CONFIG_SYS_TEXT_BASE、烧写扇区5.2 排查思路make V1是第一利器遇到编译错误第一件事是重新编译并输出完整命令make ARCHarm CROSS_COMPILEarm-linux-gnueabihf- V1V1会把每条实际的gcc命令都打印出来。通过看具体命令能立刻判断出是不是头文件搜索路径少了、是不是优化选项不对、是不是链接时少了某个库。我曾经遇到一个诡异问题uboot编译完成之后u-boot.bin能启动但u-boot.imx无法启动。最终用V1定位发现执行mkimage时的输入文件路径不对读到了一个旧的u-boot.bin而旧文件是之前一次脏编译留下的。清掉重编后问题消失。这就是典型的“产物过时”陷阱屡见不鲜。5.3 编译缓存的坑distclean不是可选项uboot编译系统会生成大量中间文件和自动生成的配置头。切换defconfig时如果不执行make distclean直接重新配置编译经常会遇到编译产物残留导致的问题。具体表现为“改了源码却不生效”“各种奇怪的宏冲突”“链接出来镜像大小和之前一样”。这就是老旧的自动生成文件没有清理干净。我个人的习惯是每次切换板型或切换分支必先make distclean然后再配置编译。虽然多花几秒钟但能省掉后面几小时的排查时间。结个尾吧结合我自己的经验编uboot这么多年最大的体会是编译流程看似枯燥但它是连接源代码和实际硬件的第一道桥梁。搞懂defconfig、顶层Makefile、链接脚本、mkimage这几个关键环节再做任何平台的uboot移植心里都会有底——至少出了问题能快速判断是配置问题、代码问题、工具链问题还是镜像封装问题。最后分享一个小习惯我会在自己的工作目录里建一个build-uboot.sh脚本把distclean、defconfig、make V1 -j4串起来同时在脚本末尾自动打印生成镜像的大小和时间。这样每次编译可复现、可追溯也方便在团队里共享统一的编译基线。编译这事看似机械但做规范了能帮自己省掉很多不必要的折腾。