【正点原子Linux连载】第三十一章U-Boot顶层Makefile详解--摘自【正点原子】I.MX6U嵌入式Linux驱动开发指南
本帖最后由 正点原子 于 2020-10-24 16:10 编辑1）实验平台：正点原子阿尔法Linux开发板
2）平台购买地址：https://item.taobao.com/item.htm?id=603672744434
3）全套实验源码+手册+视频下载地址：http://www.openedv.com/thread-300792-1-1.html
4）对正点原子Linux感兴趣的同学可以加群讨论：876919289
5）关注正点原子公众号，获取最新资料
第三十一章U-Boot顶层Makefile详解
上一章我们详细的讲解了uboot的使用方法，其实就是各种命令的使用，学会uboot使用以后就可以尝试移植uboot到自己的开发板上了，但是在移植之前需要我们得先分析一遍uboot的启动流程源码，得捋一下uboot的启动流程，否则移植的时候都不知道该修改那些文件。本章我们就来分析一下正点原子提供的uboot源码，重点是分析uboot启动流程，而不是整个uboot源码，uboot整个源码非常大，我们只看跟我们关心的部分即可。
31.1 U-Boot工程目录分析
本书我们以EMMC版本的核心板为例讲解，为了方便，uboot启动源码分析就在Windows下进行，将正点原子提供的uboot源码进行解压，解压完成以后的目录如图31.1.1所示：
图31.1.1未编译的uboot
图31.1.1是正点原子提供的未编译的uboot源码目录，我们在分析uboot源码之前一定要先在Ubuntu中编译一下uboot源码，因为编译过程会生成一些文件，而生成的这些恰恰是分析uboot源码不可或缺的文件。使用上一章创建的shell脚本来完成编译工作，命令如下：
cd alientek_uboot //进入正点原子uboot源码目录
./mx6ull_alientek_emmc.sh //编译uboot
cd../ //返回上一级目录
tar -vcjf alientek_uboot.tar.bz2 alientek_uboot //压缩
最终会生成一个名为alientek_uboot.tar.bz2的压缩包，将alientek_uboot.tar.bz2拷贝到windows系统中并解压，解压后的目录如图31.1.2所示：
图31.1.2编译后的uboot源码文件
对比图31.1.2和图31.1.1，可以看出编译后的uboot要比没编译之前多了好多文件，这些文件夹或文件的含义见表31.1.1所示：
表31.1.1uboot目录列表
表31.1.1中的很多文件夹和文件我们都不需要去关心，我们要关注的文件夹或文件如下：
1、arch文件夹
这个文件夹里面存放着和架构有关的文件，如图31.1.3所示：
图31.1.3arch文件夹
从图31.1.3可以看出有很多架构，比如arm、avr32、m68k等，我们现在用的是ARM芯片，所以只需要关心arm文件夹即可，打开arm文件夹里面内容如图31.1.4所示：
图31.1.4arm文件夹
图31.1.4只截取了一部分，还有一部分mach-xxx的文件夹。mach开头的文件夹是跟具体的设备有关的，比如“mach-exynos”就是跟三星的exyons系列CPU有关的文件。我们使用的是I.MX6ULL，所以要关注“imx-common”这个文件夹。另外“cpu”这个文件夹也是和cpu架构有关的，打开以后如图31.1.5所示：
图31.1.5 cpu文件夹
从图31.1.5可以看出有多种ARM架构相关的文件夹，I.MX6ULL使用的Cortex-A7内核，Cortex-A7属于armv7，所以我们要关心“armv7”这个文件夹。cpu文件夹里面有个名为就“u-boot.lds”的链接脚本文件，这个就是ARM芯片所使用的u-boot链接脚本文件！armv7这个文件夹里面的文件都是跟ARMV7架构有关的，是我们分析uboot启动源码的时候需要重点关注的。
2、board文件夹
board文件夹就是和具体的板子有关的，打开此文件夹，里面全是不同的板子，毫无疑问！正点原子的开发板肯定也在里面(正点原子添加的)，borad文件夹里面有个名为“freescale”的文件夹，如图31.1.6所示：
图31.1.6freescale文件夹
所有使用freescale芯片的板子都放到此文件夹中，I.MX系列以前属于freescale，只是freescale后来被NXP收购了。打开此freescale文件夹，在里面找到和mx6u(I.MX6UL/ULL)有关的文件夹，如图31.1.7所示：
图31.1.7mx6u相关板子
图31.1.7中有5个文件夹，这5个文件夹对应5种板子，以“mx6ul”开头的表示使用I.MX6UL芯片的板子，以mx6ull开头的表示使用I.MX6ULL芯片的板子。mx6ullevk是NXP官方的I.MX6ULL开发板，正点原子的ALPHA开发板就是在这个基础上开发的，因此mx6ullevk也是正点原子的开发板。我们后面移植uboot到时候就是参考的NXP官方的开发板，也就是要参考mx6ullevk这个文件夹来定义我们的板子。
3、configs文件夹
此文件夹为uboot配置文件，uboot是可配置的，但是你要是自己从头开始一个一个项目的配置，那就太麻烦了，因此一般半导体或者开发板厂商都会制作好一个配置文件。我们可以在这个做好的配置文件基础上来添加自己想要的功能，这些半导体厂商或者开发板厂商制作好的配置文件统一命名为“xxx_defconfig”，xxx表示开发板名字，这些defconfig文件都存放在configs文件夹，因此，NXP官方开发板和正点原子的开发板配置文件肯定也在这个文件夹中，如图31.1.8所示：
图31.1.8正点原子开发板配置文件
图31.1.8中这6个文件就是正点原子I.MX6U-ALPHA开发板所对应的uboot默认配置文件。我们只关心mx6ull_14x14_ddr512_emmc_defconfig和mx6ull_14x14_ddr256_nand_defconfig这两根文件，分别是正点原子I.MX6ULL EMMC核心板和NAND核心板的配置文件。使用“makexxx_defconfig”命令即可配置uboot，比如：
makemx6ull_14x14_ddr512_emmc_defconfig
上述命令就是配置正点原子的I.MX6ULL EMMC核心板所使用的uboot。
在编译uboot之前一定要使用defconfig来配置uboot！
在mx6ull_alientek_emmc.sh中就有下面这一句：
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mx6ull_14x14_ddr512_emmc_
defconfig
这个就是调用mx6ull_14x14_ddr512_emmc_defconfig来配置uboot，只是这个命令还带了一些其它参数而已。
4、.u-boot.xxx_cmd文件
.u-boot.xxx_cmd是一系列的文件，这些文件都是编译生成的，都是一些命令文件，比如文件.u-boot.bin.cmd，看名字应该是和u-boot.bin有关的，此文件的内容如下：
示例代码31.1.1 .u-boot.bin.cmd代码
1cmd_u-boot.bin:= cp u-boot-nodtb.bin u-boot.bin
.u-boot.bin.cmd里面定义了一个变量：cmd_u-boot.bin，此变量的值为“cp u-boot-nodtb.bin u-boot.bin”，也就是拷贝一份u-boot-nodtb.bin文件，并且重命名为u-boot.bin，这个就是u-boot.bin的来源，来自于文件u-boot-nodtb.bin。
那么u-boot-nodtb.bin是怎么来的呢？文件.u-boot-nodtb.bin.cmd就是用于生成u-boot.nodtb.bin的，此文件内容如下：
示例代码31.1.2 .u-boot-nodtb.bin.cmd代码
1 cmd_u-boot-nodtb.bin:= arm-linux-gnueabihf-objcopy --gap-fill=0xff-j .text -j .secure_text -j .rodata -j .hash -j .data -j .got -j .got.plt -j .u_boot_list -j .rel.dyn -O binaryu-boot u-boot-nodtb.bin
这里用到了arm-linux-gnueabihf-objcopy，使用objcopy将ELF格式的u-boot文件转换为二进制的u-boot-nodtb.bin文件。
文件u-boot是ELF格式的文件，文件.u-boot.cmd用于生成u-boot，文件内容如下：
示例代码31.1.3 .u-boot.cmd代码
1 cmd_u-boot:= arm-linux-gnueabihf-ld.bfd -pie--gc-sections -Bstatic -Ttext 0x87800000 -o u-boot -T u-boot.lds arch/arm/cpu/armv7/start.o --start-grouparch/arm/cpu/built-in.oarch/arm/cpu/armv7/built-in.oarch/arm/imx-common/built-in.oarch/arm/lib/built-in.oboard/freescale/common/built-in.oboard/freescale/mx6ull_alientek_emmc/built-in.ocmd/built-in.ocommon/built-in.odisk/built-in.odrivers/built-in.odrivers/dma/built-in.odrivers/gpio/built-in.odrivers/i2c/built-in.odrivers/mmc/built-in.odrivers/mtd/built-in.odrivers/mtd/onenand/built-in.odrivers/mtd/spi/built-in.odrivers/net/built-in.odrivers/net/phy/built-in.odrivers/pci/built-in.odrivers/power/built-in.odrivers/power/battery/built-in.odrivers/power/fuel_gauge/built-in.odrivers/power/mfd/built-in.odrivers/power/pmic/built-in.odrivers/power/regulator/built-in.odrivers/serial/built-in.odrivers/spi/built-in.odrivers/usb/dwc3/built-in.odrivers/usb/emul/built-in.odrivers/usb/eth/built-in.odrivers/usb/gadget/built-in.odrivers/usb/gadget/udc/built-in.odrivers/usb/host/built-in.odrivers/usb/musb-new/built-in.odrivers/usb/musb/built-in.odrivers/usb/phy/built-in.odrivers/usb/ulpi/built-in.ofs/built-in.olib/built-in.onet/built-in.otest/built-in.otest/dm/built-in.o --end-group arch/arm/lib/eabi_compat.o-L /usr/local/arm/gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.4 -lgcc -Map u-boot.map
.u-boot.cmd使用到了arm-linux-gnueabihf-ld.bfd，也就是链接工具，使用ld.bfd将各个built-in.o文件链接在以前就形成了u-boot文件。uboot在编译的时候会将同一个目录中的所有.c文件都编译在一起，并命名为built-in.o，相当于将众多的.c文件对应的.o文件集合在一起，这个就是u-boot文件的来源。
如果我们要用NXP提供的MFGTools工具向开发板烧写uboot，此时烧写的是u-boot.imx文件，而不是u-boot.bin文件。u-boot.imx是在u-boot.bin文件的头部添加了IVT、DCD等信息。这个工作是由文件.u-boot.imx.cmd来完成的，此文件内容如下：
示例代码31.1.4 .u-boot.imx.cmd代码
1 cmd_u-boot.imx:= ./tools/mkimage -n board/freescale/mx6ull_alientek_emmc/imximage.cfg.cfgtmp -T imximage -e 0x87800000 -d u-boot.bin u-boot.imx
可以看出，这里用到了工具tools/mkimage，而IVT、DCD等数据保存在了文件board/freescale/mx6ullevk/imximage-ddr512.cfg.cfgtmp中(如果是NAND核心板的话就是imximage-ddr256.cfg.cfgtmp)，工具mkimage就是读取文件imximage-ddr512.cfg.cfgtmp里面的信息，然后将其添加到文件u-boot.bin的头部，最终生成u-boot.imx。
文件.u-boot.lds.cmd就是用于生成u-boot.lds链接脚本的，由于.u-boot.lds.cmd文件内容太多，这里就不列出来了。uboot根目录下的u-boot.lds链接脚本就是来源于arch/arm/cpu/u-boot.lds文件。
还有一些其它的.u-boot.lds.xxx.cmd文件，大家自行分析一下，关于.u-boot.lds.xxx.cmd文件就讲解到这里。
5、Makefile文件
这个是顶层Makefile文件，Makefile是支持嵌套的，也就是顶层Makefile可以调用子目录中的Makefile文件。Makefile嵌套在大项目中很常见，一般大项目里面所有的源代码都不会放到同一个目录中，各个功能模块的源代码都是分开的，各自存放在各自的目录中。每个功能模块目录下都有一个Makefile，这个Makefile只处理本模块的编译链接工作，这样所有的编译链接工作就不用全部放到一个Makefile中，可以使得Makefile变得简洁明了。
uboot源码根目录下的Makefile是顶层Makefile，他会调用其它的模块的Makefile文件，比如drivers/adc/Makefile。当然了，顶层Makefile要做的工作可远不止调用子目录Makefile这么简单，关于顶层Makefile的内容我们稍后会有详细的讲解。
6、u-boot.xxx文件
u-boot.xxx同样也是一系列文件，包括u-boot、u-boot.bin、u-boot.cfg、u-boot.imx、u-boot.lds、u-boot.map、u-boot.srec、u-boot.sym和u-boot-nodtb.bin，这些文件的含义如下：
u-boot：编译出来的ELF格式的uboot镜像文件。
u-boot.bin：编译出来的二进制格式的uboot可执行镜像文件。
u-boot.cfg：uboot的另外一种配置文件。
u-boot.imx：u-boot.bin添加头部信息以后的文件，NXP的CPU专用文件。
u-boot.lds：链接脚本。
u-boot.map：uboot映射文件，通过查看此文件可以知道某个函数被链接到了哪个地址上。
u-boot.srec：S-Record格式的镜像文件。
u-boot.sym：uboot符号文件。
u-boot-nodtb.bin：和u-boot.bin一样，u-boot.bin就是u-boot-nodtb.bin的复制文件。
7、.config文件
uboot配置文件，使用命令“make xxx_defconfig”配置uboot以后就会自动生成，.config内容如下：
示例代码31.1.5 .config代码
1#
2# Automatically generated file; DO NOT EDIT.
3# U-Boot 2016.03 Configuration
4#
5CONFIG_CREATE_ARCH_SYMLINK=y
6CONFIG_HAVE_GENERIC_BOARD=y
7CONFIG_SYS_GENERIC_BOARD=y
8# CONFIG_ARC is not set
9CONFIG_ARM=y
10 # CONFIG_AVR32 is not set
11 # CONFIG_BLACKFIN is not set
12 # CONFIG_M68K is not set
13 # CONFIG_MICROBLAZE is not set
14 # CONFIG_MIPS is not set
15 # CONFIG_NDS32 is not set
16 # CONFIG_NIOS2 is not set
17 # CONFIG_OPENRISC is not set
18 # CONFIG_PPC is not set
19 # CONFIG_SANDBOX is not set
20 # CONFIG_SH is not set
21 # CONFIG_SPARC is not set
22 # CONFIG_X86 is not set
23 CONFIG_SYS_ARCH="arm"
24 CONFIG_SYS_CPU="armv7"
25 CONFIG_SYS_SOC="mx6"
26 CONFIG_SYS_VENDOR="freescale"
27 CONFIG_SYS_BOARD="mx6ull_alientek_emmc"
28 CONFIG_SYS_CONFIG_NAME="mx6ull_alientek_emmc"
29
30......
31
32 #
33 # Boot commands
34 #
35 CONFIG_CMD_BOOTD=y
36 CONFIG_CMD_BOOTM=y
37 CONFIG_CMD_ELF=y
38 CONFIG_CMD_GO=y
39 CONFIG_CMD_RUN=y
40 CONFIG_CMD_IMI=y
41 CONFIG_CMD_IMLS=y
42 CONFIG_CMD_XIMG=y
43
44 #
45 # Environment commands
46 #
47 CONFIG_CMD_EXPORTENV=y
48 CONFIG_CMD_IMPORTENV=y
49 CONFIG_CMD_EDITENV=y
50 CONFIG_CMD_SAVEENV=y
51 CONFIG_CMD_ENV_EXISTS=y
52
53......
54
55 #
56 # Library routines
57 #
58 # CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED is not set
59 CONFIG_HAVE_PRIVATE_LIBGCC=y
60 # CONFIG_USE_PRIVATE_LIBGCC is not set
61 CONFIG_SYS_HZ=1000
62 # CONFIG_USE_TINY_PRINTF is not set
63 CONFIG_REGEX=y
可以看出.config文件中都是以“CONFIG_”开始的配置项，这些配置项就是Makefile中的变量，因此后面都跟有相应的值，uboot的顶层Makefile或子Makefile会调用这些变量值。在.config中会有大量的变量值为‘y’，这些为‘y’的变量一般用于控制某项功能是否使能，为‘y’的话就表示功能使能，比如：
CONFIG_CMD_BOOTD=y
如果使能了bootd这个命令的话，CONFIG_CMD_BOOTM就为‘y’。在cmd/Makefile中有如下代码：
示例代码31.1.6 cmd/Makefile代码
1 ifndef CONFIG_SPL_BUILD
2 # core command
3 obj-y += boot.o
4 obj-$(CONFIG_CMD_BOOTM)+= bootm.o
5 obj-y += help.o
6 obj-y += version.o
在示例代码31.1.6中，有如下所示一行代码：
obj-$(CONFIG_CMD_BOOTM) += bootm.o
CONFIG_CMD_BOOTM=y，将其展开就是：
obj-y += bootm.o
也就是给obj-y追加了一个“bootm.o”，obj-y包含着所有要编译的文件对应的.o文件，这里表示需要编译文件cmd/bootm.c。相当于通过“CONFIG_CMD_BOOTD=y”来使能bootm这个命令，进而编译cmd/bootm.c这个文件，这个文件实现了命令bootm。在uboot和Linux内核中都是采用这种方法来选择使能某个功能，编译对应的源码文件。
8、README
README文件描述了uboot的详细信息，包括uboot该如何编译、uboot中各文件夹的含义、相应的命令等等。建议大家详细的阅读此文件，可以进一步增加对uboot的认识。
关于uboot根目录中的文件和文件夹的含义就讲解到这里，接下来就要开始分析uboot的启动流程了。
31.2 VScode工程创建
先在Ubuntu下编译一下uboot，然后将编译后的uboot文件夹复制到windows下，并创建VScode工程。打开VScode，选择：文件->打开文件夹…，选中uboot文件夹，如图31.2.1所示：
图31.2.1选择uboot源码文件夹
打开uboot目录以后，VSCode界面如图31.2.2所示：
图31.2.2 VScode界面
点击“文件->将工作区另存为…”，打开保存工作区对话框，将工作区保存到uboot源码根目录下，设置文件名为“uboot”，如图31.2.3所示：
图31.2.3保存工作区
保存成功以后就会在uboot源码根目录下存在一个名为uboot.code-workspace的文件。这样一个完整的VSCode工程就建立起来了。但是这个VSCode工程包含了uboot的所有文件， uboot中有些文件是不需要的，比如arch目录下是各种架构的文件夹，如图31.2.4所示：
图31.2.4arch目录
在arch目录下，我们只需要arm文件夹，所以需要将其它的目录从VSCode中给屏蔽掉，比如将arch/avr32这个目录给屏蔽掉。
在VSCode上建名为“.vscode”的文件夹，如图31.2.5所示：
图31.2.5新建.vscode文件夹
输入新建文件夹的名字，完成以后如图31.2.6所示。
图31.2.6新建的.vscode文件夹
在.vscode文件夹中新建一个名为“settings.json”的文件，然后在settings.json中输入如下内容：
示例代码31.2.1settings.json文件代码
1{
2"search.exclude":{
3"**/node_modules": true,
4"**/bower_components": true,
5},
6"files.exclude":{
7"**/.git": true,
8"**/.svn": true,
9"**/.hg": true,
10"**/CVS": true,
11"**/.DS_Store": true,
12}
13}
结果如图31.2.7所示：
图31.2.7 settings.json文件默认内容
其中"search.exclude"里面是需要在搜索结果中排除的文件或者文件夹，"files.exclude"是左侧工程目录中需要排除的文件或者文件夹。我们需要将arch/avr32文件夹下的所有文件从搜索结果和左侧的工程目录中都排除掉，因此在"search.exclude"和"files.exclude"中输入如图31.2.8所示内容：
图31.2.8 排除arch/avr32目录
此时再看一下左侧的工程目录，发现arch目录下没有avr32这个文件夹了，说明avr32这个文件夹被排除掉了，如图31.2.9所示：
图31.2.9 arch/avr32目录排除
我们只是在"search.exclude"和"files.exclude"中加入了：arch/avr32": true，冒号前面的是要排除的文件或者文件夹，冒号后面为是否将文件排除，true表示排除，false表示不排除。用这种方法即可将不需要的文件，或者文件夹排除掉，对于本章我们分析uboot而言，在"search.exclude"和"files.exclude"中需要输入的完成的内容如下：
示例代码31.2.2 settings.json文件代码
1"**/*.o":true,
2"**/*.su":true,
3"**/*.cmd":true,
4"arch/arc":true,
5"arch/avr32":true,
6"arch/blackfin":true,
7"arch/m68k":true,
8"arch/microblaze":true,
9"arch/mips":true,
10"arch/nds32":true,
11"arch/nios2":true,
12"arch/openrisc":true,
13"arch/powerpc":true,
14"arch/sandbox":true,
15"arch/sh":true,
16"arch/sparc":true,
17"arch/x86":true,
18"arch/arm/mach*":true,
19"arch/arm/cpu/arm11*":true,
20"arch/arm/cpu/arm720t":true,
21"arch/arm/cpu/arm9*":true,
22"arch/arm/cpu/armv7m":true,
23"arch/arm/cpu/armv8":true,
24"arch/arm/cpu/pxa":true,
25"arch/arm/cpu/sa1100":true,
26"board/*":true,
27"board/*":true,
28"board/*":true,
29"board/*":true,
30"board/fir*":true,
31"board/freescale/b*":true,
32"board/freescale/l*":true,
33"board/freescale/m5*":true,
34"board/freescale/mp*":true,
35"board/freescale/c29*":true,
36"board/freescale/cor*":true,
37"board/freescale/mx7*":true,
38"board/freescale/mx2*":true,
39"board/freescale/mx3*":true,
40"board/freescale/mx5*":true,
41"board/freescale/p*":true,
42"board/freescale/q*":true,
43"board/freescale/t*":true,
44"board/freescale/v*":true,
45"configs/*":true,
46"configs/*":true,
47"configs/*":true,
48"configs/M*":true,
49"configs/M*":true,
50"configs/M*":true,
51"configs/m*":true,
52"configs/m*":true,
53"configs/*":true,
54"include/configs/*":true,
55"include/configs/*":true,
56 "include/configs/*":true,
57"include/configs/m*":true,
上述代码用到了通配符“*”，比如“**/*.o”表示所有.o结尾的文件。“configs/*”表示configs目录下所有以‘a’~‘l’开头的文件或者文件夹。上述配置只是排除了一部分文件夹，大家在实际的使用中可以根据自己的实际需求来选择将哪些文件或者文件夹排除掉。排除以后我们的工程就会清爽很多，搜索的时候也不会跳出很多文件了。
31.3 U-Boot顶层Makefile分析
在阅读uboot源码之前，肯定是要先看一下顶层Makefile，分析gcc版本代码的时候一定是先从顶层Makefile开始的，然后再是子Makefile，这样通过层层分析Makefile即可了解整个工程的组织结构。顶层Makefile也就是uboot根目录下的Makefile文件，由于顶层Makefile文件内容比较多，所以我们将其分开来看。
31.3.1 版本号
顶层Makefile一开始是版本号，内容如下(为了方便分析，顶层Makefile代码段前段行号采用Makefile中的行号，因为uboot会更新，因此行号可能会与你所看的顶层Makefile有所不同)：
示例代码31.3.1.1 顶层Makefile代码
5 VERSION =2016
6 PATCHLEVEL =03
7 SUBLEVEL =
8 EXTRAVERSION =
9 NAME =
VERSION是主版本号，PATCHLEVEL是补丁版本号，SUBLEVEL是次版本号，这三个一起构成了uboot的版本号，比如当前的uboot版本号就是“2016.03”。EXTRAVERSION是附加版本信息，NAME是和名字有关的，一般不使用这两个。
31.3.2 MAKEFLAGS变量
make是支持递归调用的，也就是在Makefile中使用“make”命令来执行其他的Makefile文件，一般都是子目录中的Makefile文件。假如在当前目录下存在一个“subdir”子目录，这个子目录中又有其对应的Makefile文件，那么这个工程在编译的时候其主目录中的Makefile就可以调用子目录中的Makefile，以此来完成所有子目录的编译。主目录的Makefile可以使用如下代码来编译这个子目录：
$(MAKE) -C subdir
$(MAKE)就是调用“make”命令，-C指定子目录。有时候我们需要向子make传递变量，这个时候使用“export”来导出要传递给子make的变量即可，如果不希望哪个变量传递给子make的话就使用“unexport”来声明不导出:
export VARIABLE …… //导出变量给子make 。
unexport VARIABLE…… //不导出变量给子make。
有两个特殊的变量：“SHELL”和“MAKEFLAGS”，这两个变量除非使用“unexport”声明，否则的话在整个make的执行过程中，它们的值始终自动的传递给子make。在uboot的主Makefile中有如下代码：
示例代码31.3.2.1 顶层Makefile代码
20 MAKEFLAGS +=-rR --include-dir=$(CURDIR)
上述代码使用“+=”来给变量MAKEFLAGS追加了一些值，“-rR”表示禁止使用内置的隐含规则和变量定义，“--include-dir”指明搜索路径，”$(CURDIR)”表示当前目录。
31.3.3 命令输出
uboot默认编译是不会在终端中显示完整的命令，都是短命令，如图31.3.3所示：
图31.3.3.1 终端短命令输出
在终端中输出短命令虽然看起来很清爽，但是不利于分析uboot的编译过程。可以通过设置变量“V=1“来实现完整的命令输出，这个在调试uboot的时候很有用，结果如图31.3.3.2所示：
图31.3.3.2 终端完整命令输出
顶层Makefile中控制命令输出的代码如下：
示例代码31.3.3.1 顶层Makefile代码
73 ifeq ("$(origin V)","command line")
74 KBUILD_VERBOSE = $(V)
75 endif
76 ifndef KBUILD_VERBOSE
77 KBUILD_VERBOSE =0
78 endif
79
80 ifeq ($(KBUILD_VERBOSE),1)
81 quiet =
82 Q =
83else
84 quiet=quiet_
85 Q = @
86 endif
上述代码中先使用ifeq来判断"$(origin V)"和"command line"是否相等。这里用到了Makefile中的函数origin，origin和其他的函数不一样，它不操作变量的值，origin用于告诉你变量是哪来的，语法为：
$(origin <variable>)
variable是变量名，o函数的返回值就是变量来源，因此$(origin V)就是变量V的来源。如果变量V是在命令行定义的那么它的来源就是"command line"，这样"$(origin V)"和"command line"就相等了。当这两个相等的时候变量KBUILD_VERBOSE就等于V的值，比如在命令行中输入“V=1“的话那么KBUILD_VERBOSE=1。如果没有在命令行输入V的话KBUILD_VERBOSE=0。
第80行判断KBUILD_VERBOSE是否为1，如果KBUILD_VERBOSE为1的话变量quiet和Q都为空，如果KBUILD_VERBOSE=0的话变量quiet为“quiet_“，变量Q为“@”,综上所述：
V=1的话:
Makefile中会用到变量quiet和Q来控制编译的时候是否在终端输出完整的命令，在顶层Makefile中有很多如下所示的命令：
$(Q)$(MAKE) $(build)=tools
如果V=0的话上述命令展开就是“@make$(build)=tools”，make在执行的时候默认会在终端输出命令，但是在命令前面加上“@”就不会在终端输出命令了。当V=1的时候Q就为空，上述命令就是“make$(build)=tools”，因此在make执行的过程，命令会被完整的输出在终端上。
有些命令会有两个版本，比如：
quiet_cmd_sym ?= SYM $@
cmd_sym ?= $(OBJDUMP) -t [ DISCUZ_CODE_6462 ]lt;> $@
sym命令分为“quiet_cmd_sym”和“cmd_sym”两个版本，这两个命令的功能都是一样的，区别在于make执行的时候输出的命令不同。quiet_cmd_xxx命令输出信息少，也就是短命令，而cmd_xxx命令输出信息多，也就是完整的命令。
如果变量quiet为空的话，整个命令都会输出。
如果变量quiet为“quiet_”的话，仅输出短版本。
如果变量quiet为“silent_”的话，整个命令都不会输出。
31.3.4 静默输出
上一小节讲了，设置V=0或者在命令行中不定义V的话，编译uboot的时候终端中显示的短命令，但是还是会有命令输出，有时候我们在编译uboot的时候不需要输出命令，这个时候就可以使用uboot的静默输出功能。编译的时候使用“make-s”即可实现静默输出，顶层Makefile中相应的代码如下：
示例代码31.3.4.1 顶层Makefile代码
88# If the user is running make -s (silent mode), suppress echoing of
89# commands
90
91ifneq ($(filter 4.%,$(MAKE_VERSION)),)# make-4
92ifneq ($(filter %s ,$(firstword x$(MAKEFLAGS))),)
93 quiet=silent_
94endif
95else # make-3.8x
96ifneq ($(filter s%-s%,$(MAKEFLAGS)),)
97 quiet=silent_
98endif
99endif
100
101 export quiet Q KBUILD_VERBOSE
第91行判断当前正在使用的编译器版本号是否为4.x，判断$(filter 4.%,$(MAKE_VERSION))和“”(空)是否相等，如果不相等的话就成立，执行里面的语句。也就是说$(filter 4.%,$(MAKE_VERSION))不为空的话条件就成立，这里用到了Makefile中的filter函数，这是个过滤函数，函数格式如下：
$(filter <pattern...>,<text>)
filter函数表示以pattern模式过滤text字符串中的单词，仅保留符合模式pattern的单词，可以有多个模式。函数返回值就是符合pattern的字符串。因此$(filter 4.%,$(MAKE_VERSION))的含义就是在字符串“MAKE_VERSION”中找出符合“4.%”的字符(%为通配符)，MAKE_VERSION是编译器的版本号，我们当前使用的交叉编译器版本号为4.9.4，所以肯定可以找出“4.%”。因此$(filter 4.%,$(MAKE_VERSION))不为空，条件成立，执行92~94行的语句。
第92行也是一个判断语句，如果$(filter %s ,$(firstword x$(MAKEFLAGS)))不为空的话条件成立，变量quiet等于“silent_”。这里也用到了函数filter，在$(firstword x$(MAKEFLAGS)))中过滤出符合“%s”的单词。到了函数firstword，函数firstword是获取首单词，函数格式如下：
$(firstword <text>)
firstword函数用于取出text字符串中的第一个单词，函数的返回值就是获取到的单词。当使用“make-s”编译的时候，“-s”会作为MAKEFLAGS变量的一部分传递给Makefile。在顶层Makfile中添加如图31.3.4.1所示的代码：
图31.3.4.1 顶层Makefile添加代码
图31.3.4.1中的两行代码用于输出$(firstword x$(MAKEFLAGS))的结果，最后修改文件mx6ull_alientek_emmc.sh，在里面加入“-s”选项，结果如图31.3.4.2所示：
图31.3.4.2 加入-s选项
修改完成以后执行mx6ull_alientek_emmc.sh，结果如图31.3.4.3所示：
图31.3.4.3 修改顶层Makefile后的执行结果
从图31.3.4.3可以看出第一个单词是“xrRs”，将$(filter %s ,$(firstword x$(MAKEFLAGS)))展开就是$(filter %s, xrRs)，而$(filter %s, xrRs)的返回值肯定不为空，条件成立，quiet=silent_。
第101行 使用export导出变量quiet、Q和KBUILD_VERBOSE。
31.3.5 设置编译结果输出目录
uboot可以将编译出来的目标文件输出到单独的目录中，在make的时候使用“O”来指定输出目录，比如“make O=out”就是设置目标文件输出到out目录中。这么做是为了将源文件和编译产生的文件分开，当然也可以不指定O参数，不指定的话源文件和编译产生的文件都在同一个目录内，一般我们不指定O参数。顶层Makefile中相关的代码如下：
示例代码31.3.5.1 顶层Makefile代码
103 # kbuild supports saving output files in a separate directory.
104 # To locate output files in a separate directory two syntaxes are supported.
105 # In both cases the working directory must be the root of the kernel src.
106 # 1) O=
107 # Use "make O=dir/to/store/output/files/"
108 #
109 # 2) Set KBUILD_OUTPUT
110 # Set the environment variable KBUILD_OUTPUT to point to the directory
111 # where the output files shall be placed.
112 # export KBUILD_OUTPUT=dir/to/store/output/files/
113 # make
114 #
115 # The O= assignment takes precedence over the KBUILD_OUTPUT environment
116 # variable.
117
118 # KBUILD_SRC is set on invocation of make in OBJ directory
119 # KBUILD_SRC is not intended to be used by the regular user (for now)
120 ifeq ($(KBUILD_SRC),)
121
122 # OK, Make called in directory where kernel src resides
123 # Do we want to locate output files in a separate directory?
124 ifeq ("$(origin O)","command line")
125 KBUILD_OUTPUT := $(O)
126 endif
127
128 # That's our default target when none is given on the command line
129 PHONY := _all
130 _all:
131
132 # Cancel implicit rules on top Makefile
133 $(CURDIR)/Makefile Makefile:;
134
135 ifneq ($(KBUILD_OUTPUT),)
136 # Invoke a second make in the output directory, passing relevant variables
137 # check that the output directory actually exists
138 saved-output := $(KBUILD_OUTPUT)
139 KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT)&& cd $(KBUILD_OUTPUT) \
140&&/bin/pwd)
......
155 endif # ifneq ($(KBUILD_OUTPUT),)
156 endif # ifeq ($(KBUILD_SRC),)
第124行判断“O”是否来自于命令行，如果来自命令行的话条件成立，KBUILD_OUTPUT就为$(O)，因此变量KBUILD_OUTPUT就是输出目录。
第135行判断KBUILD_OUTPUT是否为空。
第139行调用mkdir命令，创建KBUILD_OUTPUT目录，并且将创建成功以后的绝对路径赋值给KBUILD_OUTPUT。至此，通过O指定的输出目录就存在了。
31.3.6 代码检查
uboot支持代码检查，使用命令“make C=1”使能代码检查，检查那些需要重新编译的文件。“make C=2”用于检查所有的源码文件，顶层Makefile中的代码如下：
示例代码31.3.6.1 顶层Makefile代码
166 # Call a source code checker (by default,"sparse") as part of the
167 # C compilation.
168 #
169 # Use 'make C=1' to enable checking of only re-compiled files.
170 # Use 'make C=2' to enable checking of *all* source files, regardless
171 # of whether they are re-compiled or not.
172 #
173 # See the file "Documentation/sparse.txt"for more details, including
174 # where to get the "sparse" utility.
175
176 ifeq ("$(origin C)","command line")
177 KBUILD_CHECKSRC = $(C)
178 endif
179 ifndef KBUILD_CHECKSRC
180 KBUILD_CHECKSRC =0
181 endif
第176行判断C是否来源于命令行，如果C来源于命令行，那就将C赋值给变量KBUILD_CHECKSRC，如果命令行没有C的话KBUILD_CHECKSRC就为0。
31.3.7 模块编译
在uboot中允许单独编译某个模块，使用命令“make M=dir”即可，旧语法“make SUBDIRS=dir”也是支持的。顶层Makefile中的代码如下：
示例代码31.3.7.1 顶层Makefile代码
183 # Use make M=dir to specify directory of external module to build
184 # Old syntax make ... SUBDIRS=$PWD is still supported
185 # Setting the environment variable KBUILD_EXTMOD take precedence
186 ifdef SUBDIRS
187 KBUILD_EXTMOD ?= $(SUBDIRS)
188 endif
189
190 ifeq ("$(origin M)","command line")
191 KBUILD_EXTMOD := $(M)
192 endif
193
194 # If building an external module we donot care about the all: rule
195 # but instead _all depend on modules
196 PHONY += all
197 ifeq ($(KBUILD_EXTMOD),)
198 _all: all
199else
200 _all: modules
201 endif
202
203 ifeq ($(KBUILD_SRC),)
204 # building in the source tree
205 srctree :=.
206else
207 ifeq ($(KBUILD_SRC)/,$(dir $(CURDIR)))
208 # building in a subdirectory of the source tree
209 srctree :=..
210else
211 srctree := $(KBUILD_SRC)
212 endif
213 endif
214 objtree :=.
215 src := $(srctree)
216 obj := $(objtree)
217
218 VPATH := $(srctree)$(if $(KBUILD_EXTMOD),:$(KBUILD_EXTMOD))
219
220export srctree objtree VPATH
第186行判断是否定义了SUBDIRS，如果定义了SUBDIRS，变量KBUILD_EXTMOD=SUBDIRS，这里是为了支持老语法“make SUBIDRS=dir”
第190行判断是否在命令行定义了M，如果定义了的话KBUILD_EXTMOD=$(M)。
第197行判断KBUILD_EXTMOD时为空，如果为空的话目标_all依赖all，因此要先编译出all。否则的话默认目标_all依赖modules，要先编译出modules，也就是编译模块。一般情况下我们不会在uboot中编译模块，所以此处会编译all这个目标。
第203行判断KBUILD_SRC是否为空，如果为空的话就设置变量srctree为当前目录，即srctree为“.”，一般不设置KBUILD_SRC。
第214行设置变量objtree为当前目录。
第215和216行分别设置变量src和obj，都为当前目录。
第218行设置VPATH。
第220行导出变量scrtree、objtree和VPATH。
31.3.8 获取主机架构和系统
接下来顶层Makefile会获取主机架构和系统，也就是我们电脑的架构和系统，代码如下：
示例代码31.3.8.1 顶层Makefile代码
227 HOSTARCH := $(shell uname -m | \
228 sed -e s/i.86/x86/ \
229-e s/sun4u/sparc64/ \
230 -e s/arm.*/arm/ \
231-e s/sa110/arm/ \
232-e s/ppc64/powerpc/ \
233-e s/ppc/powerpc/ \
234-e s/macppc/powerpc/\
235 -e s/sh.*/sh/)
236
237 HOSTOS := $(shell uname -s | tr '[:upper:]''[:lower:]'| \
238 sed -e 's/\(cygwin\).*/cygwin/')
239
240exportHOSTARCH HOSTOS
第227行定义了一个变量HOSTARCH，用于保存主机架构，这里调用shell命令“uname-m”获取架构名称，结果如图31.3.8.1所示：
图31.3.8.1 uname-m命令
从图31.3.8.1可以看出当前电脑主机架构为“x86_64”，shell中的“|”表示管道，意思是将左边的输出作为右边的输入，sed -e是替换命令，“sed -e s/i.86/x86/”表示将管道输入的字符串中的“i.86”替换为“x86”，其他的“sed -s”命令同理。对于我的电脑而言，HOSTARCH=x86_64。
第237行定义了变量HOSTOS，此变量用于保存主机OS的值，先使用shell命令“name-s”来获取主机OS，结果如图31.3.8.2所示：
图31.3.8.2 uname-s命令
从图31.3.8.2可以看出此时的主机OS为“Linux”，使用管道将“Linux”作为后面“tr '[:upper:]' '[:lower:]'”的输入，“tr '[:upper:]' '[:lower:]'”表示将所有的大写字母替换为小写字母，因此得到“linux”。最后同样使用管道，将“linux”作为“sed -e 's/\(cygwin\).*/cygwin/'”的输入，用于将cygwin.*替换为cygwin。因此，HOSTOS=linux。
第240行导出HOSTARCH=x86_64，HOSTOS=linux。
31.3.9 设置目标架构、交叉编译器和配置文件
编译uboot的时候需要设置目标板架构和交叉编译器，“make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-”就是用于设置ARCH和CROSS_COMPILE，在顶层Makefile中代码如下：
示例代码31.3.9.1 顶层Makefile代码
244 # set default to nothing for native builds
245 ifeq ($(HOSTARCH),$(ARCH))
246 CROSS_COMPILE ?=
247 endif
248
249 KCONFIG_CONFIG?=.config
250export KCONFIG_CONFIG
第245行判断HOSTARCH和ARCH这两个变量是否相等，主机架构(变量HOSTARCH)是x86_64，而我们编译的是ARM版本uboot，肯定不相等，所以CROS_COMPILE= arm-linux-gnueabihf-。从示例代码31.3.9.1可以看出，每次编译uboot的时候都要在make命令后面设置ARCH和CROS_COMPILE，使用起来很麻烦，可以直接修改顶层Makefile，在里面加入ARCH和CROSS_COMPILE的定义，如图31.3.9.1所示：
图31.3.9.1 定义ARCH和CROSS_COMPILE
按照图31.3.9.1所示，直接在顶层Makefile里面定义ARCH和CROSS_COMPILE，这样就不用每次编译的时候都要在make命令后面定义ARCH和CROSS_COMPILE。
第249行定义变量KCONFIG_CONFIG，uboot是可以配置的，这里设置配置文件为.config，.config默认是没有的，需要使用命令“makexxx_defconfig”对uboot进行配置，配置完成以后就会在uboot根目录下生成.config。默认情况下.config和xxx_defconfig内容是一样的，因为.config就是从xxx_defconfig复制过来的。如果后续自行调整了uboot的一些配置参数，那么这些新的配置参数就添加到了.config中，而不是xxx_defconfig。相当于xxx_defconfig只是一些初始配置，而.config里面的才是实时有效的配置。
31.3.10 调用scripts/Kbuild.include
主Makefile会调用文件scripts/Kbuild.include这个文件，顶层Makefile中代码如下：
示例代码31.3.10.1 顶层Makefile代码
327 # We need some generic definitions (donottry to remake the file).
328 scripts/Kbuild.include:;
329 include scripts/Kbuild.include
示例代码31.3.10.1中使用“include”包含了文件scripts/Kbuild.include，此文件里面定义了很多变量，如图31.3.10.1所示：
图31.3.10.1 Kbuild.include文件
在uboot的编译过程中会用到scripts/Kbuild.include中的这些变量，后面用到的时候再分析。
31.3.11 交叉编译工具变量设置
上面我们只是设置了CROSS_COMPILE的名字，但是交叉编译器其他的工具还没有设置，顶层Makefile中相关代码如下：
示例代码31.3.11.1 顶层Makefile代码
331 # Make variables (CC, etc...)
332
333 AS = $(CROSS_COMPILE)as
334 # Always use GNU ld
335 ifneq ($(shell $(CROSS_COMPILE)ld.bfd -v 2>/dev/null),)
336 LD = $(CROSS_COMPILE)ld.bfd
337else
338 LD = $(CROSS_COMPILE)ld
339 endif
340 CC = $(CROSS_COMPILE)gcc
341 CPP = $(CC)-E
342 AR = $(CROSS_COMPILE)ar
343 NM = $(CROSS_COMPILE)nm
344 LDR = $(CROSS_COMPILE)ldr
345 STRIP = $(CROSS_COMPILE)strip
346 OBJCOPY = $(CROSS_COMPILE)objcopy
347 OBJDUMP = $(CROSS_COMPILE)objdump
31.3.12 导出其他变量
接下来在顶层Makefile会导出很多变量，代码如下：
示例代码31.3.12.1 顶层Makefile代码
368export VERSION PATCHLEVEL SUBLEVEL UBOOTRELEASE UBOOTVERSION
369export ARCH CPU BOARD VENDOR SOC CPUDIR BOARDDIR
370export CONFIG_SHELL HOSTCC HOSTCFLAGS HOSTLDFLAGS CROSS_COMPILE AS LD CC
371export CPP AR NM LDR STRIP OBJCOPY OBJDUMP
372export MAKE AWK PERL PYTHON
373export HOSTCXX HOSTCXXFLAGS DTC CHECK CHECKFLAGS
374
375export KBUILD_CPPFLAGS NOSTDINC_FLAGS UBOOTINCLUDE OBJCOPYFLAGS LDFLAGS
376export KBUILD_CFLAGS KBUILD_AFLAGS
这些变量中大部分都已经在前面定义了，我们重点来看一下下面这几个变量：
ARCH CPU BOARD VENDOR SOC CPUDIR BOARDDIR
这7个变量在顶层Makefile是找不到的，说明这7个变量是在其他文件里面定义的，先来看一下这7个变量都是什么内容，在顶层Makefile中输入如图31.3.12.1所示的内容：
图31.3.12.1 输出变量值
修改好顶层Makefile以后执行如下命令：
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-mytest
结果如图31.3.12.2所示：
图31.3.12.2 变量结果
从图31.3.12.2可以看到这7个变量的值，这7个变量是从哪里来的呢？在uboot根目录下有个文件叫做config.mk，这7个变量就是在config.mk里面定义的，打开config.mk内容如下：
示例代码31.3.12.2 config.mk代码
1#
2# (C) Copyright 2000-2013
3# Wolfgang Denk, DENX Software Engineering, wd@denx.de.
4#
5# SPDX-License-Identifier: GPL-2.0+
6#
7#########################################################################
8
9# This file is included from ./Makefile and spl/Makefile.
10 # Clean the state to avoid the same flags added twice.
11 #
12 # (Tegra needs different flags for SPL.
13 #That's the reason why this file must be included from spl/Makefile too.
14 #If we did not have Tegra SoCs, build system would be much simpler...)
15 PLATFORM_RELFLAGS :=
16 PLATFORM_CPPFLAGS :=
17 PLATFORM_LDFLAGS :=
18 LDFLAGS :=
19 LDFLAGS_FINAL :=
20 OBJCOPYFLAGS :=
21 # clear VENDOR for tcsh
22 VENDOR :=
23 #########################################################################
24
25 ARCH := $(CONFIG_SYS_ARCH:"%"=%)
26 CPU := $(CONFIG_SYS_CPU:"%"=%)
27 ifdef CONFIG_SPL_BUILD
28 ifdef CONFIG_TEGRA
29 CPU := arm720t
30 endif
31 endif
32 BOARD := $(CONFIG_SYS_BOARD:"%"=%)
33 ifneq ($(CONFIG_SYS_VENDOR),)
34 VENDOR := $(CONFIG_SYS_VENDOR:"%"=%)
35 endif
36 ifneq ($(CONFIG_SYS_SOC),)
37 SOC := $(CONFIG_SYS_SOC:"%"=%)
38 endif
39
40 # Some architecture config.mk files need to know what CPUDIR is set to,
41 # so calculate CPUDIR before including ARCH/SOC/CPU config.mk files.
42 # Check if arch/$ARCH/cpu/$CPU exists, otherwise assume arch/$ARCH/cpu contains
43 # CPU-specific code.
44 CPUDIR=arch/$(ARCH)/cpu$(if $(CPU),/$(CPU),)
45
46 sinclude $(srctree)/arch/$(ARCH)/config.mk
47 sinclude $(srctree)/$(CPUDIR)/config.mk
48
49 ifdef SOC
50 sinclude $(srctree)/$(CPUDIR)/$(SOC)/config.mk
51 endif
52 ifneq ($(BOARD),)
53 ifdef VENDOR
54 BOARDDIR = $(VENDOR)/$(BOARD)
55else
56 BOARDDIR = $(BOARD)
57 endif
58 endif
59 ifdef BOARD
60 sinclude $(srctree)/board/$(BOARDDIR)/config.mk# include board specific rules
61 endif
62
63 ifdef FTRACE
64 PLATFORM_CPPFLAGS +=-finstrument-functions -DFTRACE
65 endif
66
67 # Allow use of stdint.h if available
68 ifneq ($(USE_STDINT),)
69 PLATFORM_CPPFLAGS +=-DCONFIG_USE_STDINT
70 endif
71
72 #########################################################################
73
74 RELFLAGS := $(PLATFORM_RELFLAGS)
75
76 PLATFORM_CPPFLAGS += $(RELFLAGS)
77 PLATFORM_CPPFLAGS +=-pipe
78
79 LDFLAGS += $(PLATFORM_LDFLAGS)
80 LDFLAGS_FINAL +=-Bstatic
81
82export PLATFORM_CPPFLAGS
83export RELFLAGS
84export LDFLAGS_FINAL
第25行定义变量ARCH，值为$(CONFIG_SYS_ARCH:"%"=%)，也就是提取CONFIG_SYS_ARCH里面双引号“”之间的内容。比如CONFIG_SYS_ARCH=“arm”的话，ARCH=arm。
第26行定义变量CPU，值为$(CONFIG_SYS_CPU:"%"=%)。
第32行定义变量BOARD，值为(CONFIG_SYS_BOARD:"%"=%)。
第34行定义变量VENDOR，值为$(CONFIG_SYS_VENDOR:"%"=%)。
第37行定义变量SOC，值为$(CONFIG_SYS_SOC:"%"=%)。
第44行定义变量CPUDIR，值为arch/$(ARCH)/cpu$(if $(CPU),/$(CPU),)。
第46行sinclude和include的功能类似，在Makefile中都是读取指定文件内容，这里读取文件$(srctree)/arch/$(ARCH)/config.mk的内容。sinclude读取的文件如果不存在的话不会报错。
第47行读取文件$(srctree)/$(CPUDIR)/config.mk的内容。
第50行读取文件$(srctree)/$(CPUDIR)/$(SOC)/config.mk的内容。
第54行定义变量BOARDDIR，如果定义了VENDOR那么BOARDDIR=$(VENDOR)/$(BOARD)，否则的BOARDDIR=$(BOARD)。
第60行读取文件$(srctree)/board/$(BOARDDIR)/config.mk。
接下来需要找到CONFIG_SYS_ARCH、CONFIG_SYS_CPU、CONFIG_SYS_BOARD、CONFIG_SYS_VENDOR和CONFIG_SYS_SOC这5个变量的值。这5个变量在uboot根目录下的.config文件中有定义，定义如下：
示例代码31.3.12.3 .config文件代码
23 CONFIG_SYS_ARCH="arm"
24 CONFIG_SYS_CPU="armv7"
25 CONFIG_SYS_SOC="mx6"
26 CONFIG_SYS_VENDOR="freescale"
27 CONFIG_SYS_BOARD="mx6ullevk "
28 CONFIG_SYS_CONFIG_NAME="mx6ullevk"
根据示例代码31.3.12.3可知：
ARCH = arm
CPU = armv7
BOARD = mx6ullevk
VENDOR = freescale
SOC = mx6
CPUDIR = arch/arm/cpu/armv7
BOARDDIR = freescale/mx6ullevk
在config.mk中读取的文件有：
arch/arm/config.mk
arch/arm/cpu/armv7/config.mk
arch/arm/cpu/armv7/mx6/config.mk (此文件不存在)
board/ freescale/mx6ullevk/config.mk (此文件不存在)
31.3.13 make xxx_defconfig过程
在编译uboot之前要使用“makexxx_defconfig”命令来配置uboot，那么这个配置过程是如何运行的呢？在顶层Makefile中有如下代码：
示例代码31.3.13.1 顶层Makefile代码段
414 # To make sure we donot include .config for any of the *config targets
415 # catch them early,and hand them over to scripts/kconfig/Makefile
416 # It is allowed to specify more targets when calling make, including
417 # mixing *config targets and build targets.
418 # For example 'make oldconfig all'.
419 # Detect when mixed targets is specified,and make a second invocation
420 # of make so .config is not included in thiscase either (for*config).
421
422 version_h := include/generated/version_autogenerated.h
423 timestamp_h := include/generated/timestamp_autogenerated.h
424
425 no-dot-config-targets := clean clobber mrproper distclean \
426 help %docs check% coccicheck \
427 ubootversion backup
428
429 config-targets :=0
430 mixed-targets:=0
431 dot-config :=1
432
433 ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),)
434 ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),)
435 dot-config :=0
436 endif
437 endif
438
439 ifeq ($(KBUILD_EXTMOD),)
440 ifneq ($(filter config %config,$(MAKECMDGOALS)),)
441 config-targets :=1
442 ifneq ($(words $(MAKECMDGOALS)),1)
443 mixed-targets :=1
444 endif
445 endif
446 endif
447
448 ifeq ($(mixed-targets),1)
449 # ================================================================
450 # We're called with mixed targets (*config and build targets).
451 # Handle them one by one.
452
453 PHONY += $(MAKECMDGOALS) __build_one_by_one
454
455 $(filter-out __build_one_by_one, $(MAKECMDGOALS)): __build_one_by_one
456 @:
457
458 __build_one_by_one:
459 $(Q)set -e; \
460for i in $(MAKECMDGOALS);do \
461 $(MAKE)-f $(srctree)/Makefile $i; \
462 done
463
464else
465 ifeq ($(config-targets),1)
466 # ================================================================
467 # *config targets only - make sure prerequisites are updated,and descend
468 # in scripts/kconfig to make the *config target
469
470 KBUILD_DEFCONFIG := sandbox_defconfig
471export KBUILD_DEFCONFIG KBUILD_KCONFIG
472
473 config: scripts_basic outputmakefile FORCE
474 $(Q)$(MAKE) $(build)=scripts/kconfig $@
475
476%config: scripts_basic outputmakefile FORCE
477 $(Q)$(MAKE) $(build)=scripts/kconfig $@
478
479else
480 #==================================================================
481 # Build targets only -this includes vmlinux, arch specific targets, clean
482 # targets and others. In general all targets except *config targets.
483
484 ifeq ($(dot-config),1)
485 # Read in config
486-include include/config/auto.conf
......
第422行定义了变量version_h，这变量保存版本号文件，此文件是自动生成的。文件include/generated/version_autogenerated.h内容如图31.3.13.1所示：
图31.3.13.1 版本号文件
第423行定义了变量timestamp_h，此变量保存时间戳文件，此文件也是自动生成的。文件include/generated/timestamp_autogenerated.h内容如图31.3.13.2所示：
图31.3.13.2 时间戳文件
第425行定义了变量no-dot-config-targets。
第429行定义了变量config-targets，初始值为0。
第430行定义了变量mixed-targets，初始值为0。
第431行定义了变量dot-config，初始值为1。
第433行将MAKECMDGOALS中不符合no-dot-config-targets的部分过滤掉，剩下的如果不为空的话条件就成立。MAKECMDGOALS是make的一个环境变量，这个变量会保存你所指定的终极目标列表，比如执行“make mx6ull_alientek_emmc_defconfig”，那么MAKECMDGOALS就为mx6ull_alientek_emmc_defconfig。很明显过滤后为空，所以条件不成立，变量dot-config依旧为1。
第439行判断KBUILD_EXTMOD是否为空，如果KBUILD_EXTMOD为空的话条件成立，经过前面的分析，我们知道KBUILD_EXTMOD为空，所以条件成立。
第440行将MAKECMDGOALS中不符合“config”和“%config”的部分过滤掉，如果剩下的部分不为空条件就成立，很明显此处条件成立，变量config-targets=1。
第442行统计MAKECMDGOALS中的单词个数，如果不为1的话条件成立。此处调用Makefile中的words函数来统计单词个数，words函数格式如下：
$(words <text>)
很明显，MAKECMDGOALS的单词个数是1个，所以条件不成立，mixed-targets继续为0。综上所述，这些变量值如下：
config-targets =1
mixed-targets = 0
dot-config = 1
第448行如果变量mixed-targets为1的话条件成立，很明显，条件不成立。
第465行如果变量config-targets为1的话条件成立，很明显，条件成立，执行这个分支。
第473行，没有目标与之匹配，所以不执行。
第476行，有目标与之匹配，当输入“makexxx_defconfig”的时候就会匹配到%config目标，目标“%config”依赖于scripts_basic、outputmakefile和FORCE。FORCE在顶层Makefile的1610行有如下定义：
示例代码31.3.13.2 顶层Makefile代码段
1610 PHONY += FORCE
1611 FORCE:
可以看出FORCE是没有规则和依赖的，所以每次都会重新生成FORCE。当FORCE作为其他目标的依赖时，由于FORCE总是被更新过的，因此依赖所在的规则总是会执行的。
依赖scripts_basic和outputmakefile在顶层Makefile中的内容如下：
示例代码31.3.13.3 顶层Makefile代码段
394 # Basic helpers built in scripts/
395 PHONY += scripts_basic
396 scripts_basic:
397 $(Q)$(MAKE) $(build)=scripts/basic
398 $(Q)rm -f .tmp_quiet_recordmcount
399
400 # To avoid any implicit rule to kick in, define an empty command.
401 scripts/basic/%: scripts_basic ;
402
403 PHONY += outputmakefile
404 # outputmakefile generates a Makefile in the output directory,if
405 # using a separate output directory. This allows convenient use of
406 # make in the output directory.
407 outputmakefile:
408 ifneq ($(KBUILD_SRC),)
409 $(Q)ln -fsn $(srctree) source
410 $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile \
411 $(srctree) $(objtree) $(VERSION) $(PATCHLEVEL)
412 endif
第408行，判断KBUILD_SRC是否为空，只有变量KBUILD_SRC不为空的时候outputmakefile才有意义，经过我们前面的分析KBUILD_SRC为空，所以outputmakefile无效。只有scripts_basic是有效的。
第396~398行是scripts_basic的规则，其对应的命令用到了变量Q、MAKE和build，其中：
Q=@或为空
MAKE=make
变量build是在scripts/Kbuild.include文件中有定义，定义如下：
示例代码31.3.13.3 Kbuild.include代码段
177 ###
178 # Shorthand for $(Q)$(MAKE)-f scripts/Makefile.build obj=
179 # Usage:
180 # $(Q)$(MAKE) $(build)=dir
181 build :=-f $(srctree)/scripts/Makefile.build obj
从示例代码31.3.13.3可以看出build=-f $(srctree)/scripts/Makefile.build obj，经过前面的分析可知，变量srctree为”.”，因此：
build=-f ./scripts/Makefile.build obj
scripts_basic展开以后如下：
scripts_basic:
@make -f ./scripts/Makefile.build obj=scripts/basic //也可以没有@，视配置而定
@rm -f . tmp_quiet_recordmcount //也可以没有@
scripts_basic会调用文件./scripts/Makefile.build，这个我们后面在分析。
接着回到示例代码31.3.13.1中的%config处，内容如下：
%config: scripts_basic outputmakefile FORCE
$(Q)$(MAKE) $(build)=scripts/kconfig $@
将命令展开就是：
@make -f ./scripts/Makefile.build obj=scripts/kconfig xxx_defconfig
同样也跟文件./scripts/Makefile.build有关，我们后面再分析此文件。使用如下命令配置uboot，并观察其配置过程：
make mx6ull_14x14_ddr512_emmc_defconfig V=1
配置过程如图31.3.13.1所示：
图31.3.13.1 uboot配置过程
从图31.3.13.1可以看出，我们的分析是正确的，接下来就要结合下面两行命令重点分析一下文件scripts/Makefile.build。
①、scripts_basic目标对应的命令
@make -f ./scripts/Makefile.build obj=scripts/basic
②、%config目标对应的命令
@make -f ./scripts/Makefile.build obj=scripts/kconfig xxx_defconfig
31.3.14 Makefile.build脚本分析
从上一小节可知，“makexxx_defconfig“配置uboot的时候如下两行命令会执行脚本scripts/Makefile.build：
@make -f ./scripts/Makefile.build obj=scripts/basic
@make -f ./scripts/Makefile.build obj=scripts/kconfig xxx_defconfig
依次来分析一下：
1、scripts_basic目标对应的命令
scripts_basic目标对应的命令为：@make -f ./scripts/Makefile.build obj=scripts/basic。打开文件scripts/Makefile.build，有如下代码：
示例代码31.3.14.1 Makefile.build代码段
8# Modified for U-Boot
9prefix := tpl
10 src := $(patsubst $(prefix)/%,%,$(obj))
11 ifeq ($(obj),$(src))
12 prefix := spl
13 src := $(patsubst $(prefix)/%,%,$(obj))
14 ifeq ($(obj),$(src))
15 prefix :=.
16 endif
17 endif
第9行定义了变量prefix值为tpl。
第10行定义了变量src，这里用到了函数patsubst，此行代码展开后为：
$(patsubst tpl/%,%, scripts/basic)
patsubst是替换函数，格式如下：
$(patsubst <pattern>,<replacement>,<text>)
此函数用于在text中查找符合pattern的部分，如果匹配的话就用replacement替换掉。pattenr是可以包含通配符“%”，如果replacement中也包含通配符“%”，那么replacement中的这个“%”将是pattern中的那个“%”所代表的字符串。函数的返回值为替换后的字符串。因此，第10行就是在“scripts/basic”中查找符合“tpl/%”的部分，然后将“tpl/”取消掉，但是“scripts/basic”没有“tpl/”，所以src= scripts/basic。
第11行判断变量obj和src是否相等，相等的话条件成立，很明显，此处条件成立。
第12行和第9行一样，只是这里处理的是“spl”，“scripts/basic”里面也没有“spl/”，所以src继续为scripts/basic。
第15行因为变量obj和src相等，所以prefix=.。
继续分析scripts/Makefile.build，有如下代码：
示例代码31.3.14.2 Makefile.build代码段
56 # The filename Kbuild has precedence over Makefile
57 kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src))
58 kbuild-file := $(if $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile)
59 include $(kbuild-file)
将kbuild-dir展开后为：
$(if $(filter /%, scripts/basic),scripts/basic, ./scripts/basic)，
因为没有以“/”为开头的单词，所以$(filter /%, scripts/basic)的结果为空，kbuild-dir=./scripts/basic。
将kbuild-file展开后为：
$(if $(wildcard ./scripts/basic/Kbuild), ./scripts/basic/Kbuild, ./scripts/basic/Makefile)
因为scrpts/basic目录中没有Kbuild这个文件，所以kbuild-file= ./scripts/basic/Makefile。最后将59行展开，即：
include./scripts/basic/Makefile
也就是读取scripts/basic下面的Makefile文件。
继续分析scripts/Makefile.build，如下代码：
示例代码31.3.14.3 Makefile.build代码段
116 __build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \
117 $(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \
118 $(subdir-ym) $(always)
119 @:
__build是默认目标，因为命令“@make -f ./scripts/Makefile.build obj=scripts/basic”没有指定目标，所以会使用到默认目标：__build。在顶层Makefile中，KBUILD_BUILTIN为1，KBUILD_MODULES为0，因此展开后目标__build为：
__build:$(builtin-target) $(lib-target) $(extra-y)) $(subdir-ym) $(always)
@:
可以看出目标__build有5个依赖：builtin-target、lib-target、extra-y、subdir-ym和always。这5个依赖的具体内容我们就不通过源码来分析了，直接在scripts/Makefile.build中输入图31.3.14.1所示内容，将这5个变量的值打印出来：
图31.3.14.1 输出变量
执行如下命令：
make mx6ull_14x14_ddr512_emmc_defconfig V=1
结果如图31.3.14.2所示：
图31.3.14.2 输出结果
从上图可以看出，只有always有效，因此__build最终为：
__build: scripts/basic/fixdep
@:
__build依赖于scripts/basic/fixdep，所以要先scripts/basic/fixdep.c编译，生成fixdep，前面已经读取了scripts/basic/Makefile文件。
综上所述，scripts_basic目标的作用就是编译出scripts/basic/fixdep这个软件。
2、%config目标对应的命令
%config目标对应的命令为：@make -f ./scripts/Makefile.build obj=scripts/kconfig xxx_defconfig，各个变量值如下：
src= scripts/kconfig
kbuild-dir =./scripts/kconfig
kbuild-file =./scripts/kconfig/Makefile
include ./scripts/kconfig/Makefile
可以看出，Makefilke.build会读取scripts/kconfig/Makefile中的内容，此文件有如下所示内容：
示例代码31.3.14.4 scripts/kconfig/Makefile代码段
113%_defconfig: $(obj)/conf
114 $(Q)[ DISCUZ_CODE_6494 ]lt; $(silent)--defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
115
116 # Added for U-Boot (backward compatibility)
117%_config:%_defconfig
118 @:
目标%_defconfig刚好和我们输入的xxx_defconfig匹配，所以会执行这条规则。依赖为$(obj)/conf，展开后就是scripts/kconfig/conf。接下来就是检查并生成依赖scripts/kconfig/conf。conf是主机软件，到这里我们就打住，不要纠结conf是怎么编译出来的，否则就越陷越深，太绕了，像conf这种主机所使用的工具类软件我们一般不关心它是如何编译产生的。如果一定要看是conf是怎么生成的，可以输入如下命令重新配置uboot，在重新配置uboot的过程中就会输出conf编译信息。
make distclean
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mx6ull_14x14_ddr512_emmc_
defconfigV=1
结果如图31.3.14.3所示：
图31.3.14.3 编译过程
得到scripts/kconfig/conf以后就要执行目标%_defconfig的命令：
$(Q)[ DISCUZ_CODE_6496 ]lt; $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
相关的变量值如下：
silent=-s或为空
SRCARCH=..
Kconfig=Kconfig
将其展开就是：
@ scripts/kconfig/conf --defconfig=arch/../configs/xxx_defconfig Kconfig
上述命令用到了xxx_defconfig文件，比如mx6ull_alientek_emmc_defconfig。这里会将mx6ull_alientek_emmc_defconfig中的配置输出到.config文件中，最终生成uboot根目录下的.config文件。
这个就是命令makexxx_defconfig执行流程，总结一下如图31.3.14.4所示：
图31.3.14.4 makexxx_defconfig执行流程图
至此，makexxx_defconfig就分析完了，接下来就要分析一下u-boot.bin是怎么生成的了。
31.3.15 make过程
配置好uboot以后就可以直接make编译了，因为没有指明目标，所以会使用默认目标，主Makefile中的默认目标如下：
示例代码31.3.15.1 顶层Makefile代码段
128 # That's our default target when none is given on the command line
129 PHONY := _all
130 _all:
目标_all又依赖于all，如下所示：
示例代码31.3.15.2 顶层Makefile代码段
194 # If building an external module we donot care about the all: rule
195 # but instead _all depend on modules
196 PHONY += all
197 ifeq ($(KBUILD_EXTMOD),)
198 _all: all
199else
200 _all: modules
201 endif
如果KBUILD_EXTMOD为空的话_all依赖于all。这里不编译模块，所以KBUILD_EXTMOD肯定为空，_all的依赖就是all。在主Makefile中all目标规则如下：
示例代码31.3.15.2 顶层Makefile代码段
802 all: $(ALL-y)
803 ifneq ($(CONFIG_SYS_GENERIC_BOARD),y)
804 @echo "===================== WARNING ======================"
805 @echo "Please convert this board to generic board."
806 @echo "Otherwise it will be removed by the end of 2014."
807 @echo "See doc/README.generic-board for further information"
808 @echo "===================================================="
809 endif
810 ifeq ($(CONFIG_DM_I2C_COMPAT),y)
811 @echo "===================== WARNING ======================"
812 @echo "This board uses CONFIG_DM_I2C_COMPAT. Please remove"
813 @echo "(possibly in a subsequent patch in your series)"
814 @echo "before sending patches to the mailing list."
815 @echo "===================================================="
816 endif
从802行可以看出，all目标依赖$(ALL-y)，而在顶层Makefile中，ALL-y如下：
示例代码31.3.15.3 顶层Makefile代码段
730 # Always append ALL so that arch config.mk's can add custom ones
731 ALL-y += u-boot.srec u-boot.bin u-boot.sym System.map u-boot.cfg binary_size_check
732
733 ALL-$(CONFIG_ONENAND_U_BOOT)+= u-boot-onenand.bin
734 ifeq ($(CONFIG_SPL_FSL_PBL),y)
735 ALL-$(CONFIG_RAMBOOT_PBL)+= u-boot-with-spl-pbl.bin
736else
737 ifneq ($(CONFIG_SECURE_BOOT), y)
738 # For Secure Boot The Image needs to be signedand Header must also
739 # be included. So The image has to be built explicitly
740 ALL-$(CONFIG_RAMBOOT_PBL)+= u-boot.pbl
741 endif
742 endif
743 ALL-$(CONFIG_SPL)+= spl/u-boot-spl.bin
744 ALL-$(CONFIG_SPL_FRAMEWORK)+= u-boot.img
745 ALL-$(CONFIG_TPL)+= tpl/u-boot-tpl.bin
746 ALL-$(CONFIG_OF_SEPARATE)+= u-boot.dtb
747 ifeq ($(CONFIG_SPL_FRAMEWORK),y)
748 ALL-$(CONFIG_OF_SEPARATE)+= u-boot-dtb.img
749 endif
750 ALL-$(CONFIG_OF_HOSTFILE)+= u-boot.dtb
751 ifneq ($(CONFIG_SPL_TARGET),)
752 ALL-$(CONFIG_SPL)+= $(CONFIG_SPL_TARGET:"%"=%)
753 endif
754 ALL-$(CONFIG_REMAKE_ELF)+= u-boot.elf
755 ALL-$(CONFIG_EFI_APP)+= u-boot-app.efi
756 ALL-$(CONFIG_EFI_STUB)+= u-boot-payload.efi
757
758 ifneq ($(BUILD_ROM),)
759 ALL-$(CONFIG_X86_RESET_VECTOR)+= u-boot.rom
760 endif
761
762 # enable combined SPL/u-boot/dtb rules for tegra
763 ifeq ($(CONFIG_TEGRA)$(CONFIG_SPL),yy)
764 ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
765 ALL-$(CONFIG_OF_SEPARATE)+= u-boot-dtb-tegra.bin
766 endif
767
768 # Add optional build target if defined in board/cpu/soc headers
769 ifneq ($(CONFIG_BUILD_TARGET),)
770 ALL-y += $(CONFIG_BUILD_TARGET:"%"=%)
771 endif
从示例代码代码31.3.15.3可以看出，ALL-y包含u-boot.srec、u-boot.bin、u-boot.sym、System.map、u-boot.cfg 和binary_size_check这几个文件。根据uboot的配置情况也可能包含其他的文件，比如：
ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin
CONFIG_ONENAND_U_BOOT就是uboot中跟ONENAND配置有关的，如果我们使能了ONENAND，那么在.config配置文件中就会有“CONFIG_ONENAND_U_BOOT=y”这一句。相当于CONFIG_ONENAND_U_BOOT是个变量，这个变量的值为“y”，所以展开以后就是：
ALL-y += u-boot-onenand.bin
这个就是.config里面的配置参数的含义，这些参数其实都是变量，后面跟着变量值，会在顶层Makefile或者其他Makefile中调用这些变量。
ALL-y里面有个u-boot.bin，这个就是我们最终需要的uboot二进制可执行文件，所作的所有工作就是为了它。在顶层Makefile中找到u-boot.bin目标对应的规则，如下所示：
示例代码31.3.15.4 顶层Makefile代码段
825 ifeq ($(CONFIG_OF_SEPARATE),y)
826 u-boot-dtb.bin: u-boot-nodtb.bin dts/dt.dtb FORCE
827 $(call if_changed,cat)
828
829 u-boot.bin: u-boot-dtb.bin FORCE
830 $(call if_changed,copy)
831else
832 u-boot.bin: u-boot-nodtb.bin FORCE
833 $(call if_changed,copy)
834 endif
第825行判断CONFIG_OF_SEPARATE是否等于y，如果相等，那条件就成立，在.config中搜索“CONFIG_OF_SEPARAT”，没有找到，说明条件不成立。
第832行就是目标u-boot.bin的规则，目标u-boot.bin依赖于u-boot-nodtb.bin，命令为$(call if_changed,copy)，这里调用了if_changed，if_changed是一个函数，这个函数在scripts/Kbuild.include中有定义，而顶层Makefile中会包含scripts/Kbuild.include文件，这个前面已经说过了。
if_changed在Kbuild.include中的定义如下：
示例代码31.3.15.5 Kbuild.include代码段
226 ###
227 # if_changed - execute command if any prerequisite is newer than
228 # target,or command line has changed
229 # if_changed_dep - as if_changed, but uses fixdep to reveal
230 # dependencies including used config symbols
231 # if_changed_rule - as if_changed but execute rule instead
232 # See Documentation/kbuild/makefiles.txt for more info
233
234 ifneq ($(KBUILD_NOCMDDEP),1)
235 # Check if both arguments has same arguments. Result is empty string if equal.
236 # User may overridethis check using make KBUILD_NOCMDDEP=1
237 arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \
238 $(filter-out $(cmd_$@), $(cmd_$(1))))
239else
240 arg-check = $(if $(strip $(cmd_$@)),,1)
241 endif
242
243 # Replace >[ DISCUZ_CODE_6506 ]lt; with >[ DISCUZ_CODE_56 ]lt; to preserve $ when reloading the .cmd file
244 # (needed for make)
245 # Replace >#< with >\#< to avoid starting a comment in the .cmd file
246 # (needed for make)
247 # Replace >'< with >'\''< to be able to enclose the whole string in '...'
248 # (needed for the shell)
249 make-cmd = $(call escsq,$(subst \#,\\\#,$(subst $,$,$(cmd_$(1)))))
250
251 # Find any prerequisites that is newer than target or that does not exist.
252 # PHONY targets skipped in both cases.
253 any-prereq = $(filter-out $(PHONY),$?) $(filter-out $(PHONY) $(wildcard $^),$^)
254
255 # Execute command if command has changed or prerequisite(s) are updated.
256 #
257 if_changed = $(if $(strip $(any-prereq) $(arg-check)), \
258 @set -e; \
259 $(echo-cmd) $(cmd_$(1)); \
260 printf '%s\n''cmd_$@ := $(make-cmd)'> $(dot-target).cmd)
261
第227行为 if_changed的描述，根据描述，在一些先决条件比目标新的时候，或者命令行有改变的时候，if_changed就会执行一些命令。
第257行就是函数if_changed，if_changed函数引用的变量比较多，也比较绕，我们只需要知道它可以从u-boot-nodtb.bin生成u-boot.bin就行了。
既然u-boot.bin依赖于u-boot-nodtb.bin，那么肯定要先生成u-boot-nodtb.bin文件，顶层Makefile中相关代码如下：
示例代码31.3.15.6 顶层Makefile代码段
866 u-boot-nodtb.bin: u-boot FORCE
867 $(call if_changed,objcopy)
868 $(call DO_STATIC_RELA,[ DISCUZ_CODE_6507 ]lt;,$@,$(CONFIG_SYS_TEXT_BASE))
869 $(BOARD_SIZE_CHECK)
目标u-boot-nodtb.bin又依赖于u-boot，顶层Makefile中u-boot相关规则如下：
示例代码31.3.15.7 顶层Makefile代码段
1170 u-boot: $(u-boot-init) $(u-boot-main) u-boot.lds FORCE
1171 $(call if_changed,u-boot__)
1172 ifeq ($(CONFIG_KALLSYMS),y)
1173 $(call cmd,smap)
1174 $(call cmd,u-boot__) common/system_map.o
1175 endif
目标u-boot依赖于u-boot_init、u-boot-main和u-boot.lds，u-boot_init和u-boot-main是两个变量，在顶层Makefile中有定义，值如下：
示例代码31.3.15.8 顶层Makefile代码段
678 u-boot-init := $(head-y)
679 u-boot-main := $(libs-y)
$(head-y)跟CPU架构有关，我们使用的是ARM芯片，所以head-y在arch/arm/Makefile中被指定为：
head-y := arch/arm/cpu/$(CPU)/start.o
根据31.3.12小节的分析，我们知道CPU=armv7，因此head-y展开以后就是：
head-y := arch/arm/cpu/armv7/start.o
因此：
u-boot-init= arch/arm/cpu/armv7/start.o
$(libs-y)在顶层Makefile中被定义为uboot所有子目录下build-in.o的集合，代码如下：
示例代码31.3.15.9 顶层Makefile代码段
620 libs-y += lib/
621 libs-$(HAVE_VENDOR_COMMON_LIB)+= board/$(VENDOR)/common/
622 libs-$(CONFIG_OF_EMBED)+= dts/
623 libs-y += fs/
624 libs-y += net/
625 libs-y += disk/
626 libs-y += drivers/
627 libs-y += drivers/dma/
628 libs-y += drivers/gpio/
629 libs-y += drivers/i2c/
......
660 libs-y += cmd/
661 libs-y += common/
662 libs-$(CONFIG_API)+= api/
663 libs-$(CONFIG_HAS_POST)+= post/
664 libs-y += test/
665 libs-y += test/dm/
666 libs-$(CONFIG_UT_ENV)+= test/env/
667
668 libs-y += $(if $(BOARDDIR),board/$(BOARDDIR)/)
669
670 libs-y := $(sort $(libs-y))
671
672 u-boot-dirs := $(patsubst %/,%,$(filter %/, $(libs-y))) tools examples
673
674 u-boot-alldirs:= $(sort $(u-boot-dirs) $(patsubst %/,%,$(filter %/, $(libs-))))
675
676 libs-y := $(patsubst %/, %/built-in.o, $(libs-y))
从上面的代码可以看出，libs-y都是uboot各子目录的集合，最后：
libs-y := $(patsubst %/, %/built-in.o, $(libs-y))
这里调用了函数patsubst，将libs-y中的“/”替换为”/built-in.o”，比如“drivers/dma/”就变为了“drivers/dma/built-in.o”，相当于将libs-y改为所有子目录中built-in.o文件的集合。那么u-boot-main就等于所有子目录中built-in.o的集合。
这个规则就相当于将以u-boot.lds为链接脚本，将arch/arm/cpu/armv7/start.o和各个子目录下的built-in.o链接在一起生成u-boot。
u-boot.lds的规则如下：
示例代码31.3.15.10 顶层Makefile代码段
u-boot.lds: $(LDSCRIPT) prepare FORCE
$(call if_changed_dep,cpp_lds)
接下来的重点就是各子目录下的built-in.o是怎么生成的，以drivers/gpio/built-in.o为例，在drivers/gpio/目录下会有个名为.built-in.o.cmd的文件，此文件内容如下：
示例代码31.3.15.11 drivers/gpio/.built-in.o.cmd代码
1 cmd_drivers/gpio/built-in.o :=arm-linux-gnueabihf-ld.bfd -r -o drivers/gpio/built-in.o drivers/gpio/mxc_gpio.o
从命令“cmd_drivers/gpio/built-in.o”可以看出，drivers/gpio/built-in.o这个文件是使用ld命令由文件drivers/gpio/mxc_gpio.o生成而来的，mxc_gpio.o是mxc_gpio.c编译生成的.o文件，这个是NXP的I.MX系列的GPIO驱动文件。这里用到了ld的“-r”参数，参数含义如下：
-r –relocateable: 产生可重定向的输出，比如，产生一个输出文件它可再次作为‘ld’的输入，这经常被叫做“部分链接”，当我们需要将几个小的.o文件链接成为一个.o文件的时候，需要使用此选项。
最终将各个子目录中的built-in.o文件链接在一起就形成了u-boot，使用如下命令编译uboot就可以看到链接的过程：
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mx6ull_14x14_ddr512_emmc_
defconfig V=1
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- V=1
编译的时候会有如图31.3.15.1所示内容输出：
图31.3.15.1 编译内容输出
将其整理一下，内容如下：
arm-linux-gnueabihf-ld.bfd -pie--gc-sections -Bstatic -Ttext 0x87800000 \
-o u-boot -T u-boot.lds \
arch/arm/cpu/armv7/start.o \
--start-grouparch/arm/cpu/built-in.o \
arch/arm/cpu/armv7/built-in.o \
arch/arm/imx-common/built-in.o \
arch/arm/lib/built-in.o \
board/freescale/common/built-in.o \
board/freescale/mx6ull_alientek_emmc/built-in.o \
cmd/built-in.o\
common/built-in.o\
disk/built-in.o\
drivers/built-in.o\
drivers/dma/built-in.o\
drivers/gpio/built-in.o\
……
drivers/spi/built-in.o\
drivers/usb/dwc3/built-in.o\
drivers/usb/emul/built-in.o\
drivers/usb/eth/built-in.o\
drivers/usb/gadget/built-in.o\
drivers/usb/gadget/udc/built-in.o\
drivers/usb/host/built-in.o\
drivers/usb/musb-new/built-in.o\
drivers/usb/musb/built-in.o\
drivers/usb/phy/built-in.o\
drivers/usb/ulpi/built-in.o\
fs/built-in.o\
lib/built-in.o\
net/built-in.o\
test/built-in.o\
test/dm/built-in.o \
--end-group arch/arm/lib/eabi_compat.o\
-L /usr/local/arm/gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.4 -lgcc -Map u-boot.map
可以看出最终是用arm-linux-gnueabihf-ld.bfd命令将arch/arm/cpu/armv7/start.o和其他众多的built_in.o链接在一起，形成u-boot。
目标all除了u-boot.bin以外还有其他的依赖，比如u-boot.srec 、u-boot.sym 、System.map、u-boot.cfg和binary_size_check等等，这些依赖的生成方法和u-boot.bin很类似，大家自行查看一下顶层Makefile，我们就不详细的讲解了。
总结一下“make”命令的流程，如图31.3.15.2所示：
图31.3.15.2 make命令流程
图31.3.15.2就是“make”命令的执行流程，关于uboot的顶层Makefile就分析到这里，重点是“makexxx_defconfig”和“make”这两个命令的执行流程：
makexxx_defconfig：用于配置uboot，这个命令最主要的目的就是生成.config文件。
make：用于编译uboot，这个命令的主要工作就是生成二进制的u-boot.bin文件和其他的一些与uboot有关的文件，比如u-boot.imx等等。
关于uboot的顶层Makefile就分析到这里，有些内容我们没有详细、深入的去研究，因为我们的重点是使用uboot，而不是uboot的研究者，我们要做的是缕清uboot的流程。至于更具体的实现，有兴趣的可以参考一下其他资料。
页:
[1]