一、uboot主Makefile分析

内容源于朱有鹏物联网大讲堂的笔记

(1)uboot的版本号分3个级别：

VERSION：主板本号

PATCHLEVEL：次版本号

SUBLEVEL：再次版本号

EXTRAVERSION:另外附加的版本信息

这4个用.分隔开共同构成了最终的版本号。

(2)Makefile中版本号最终生成了一个变量U_BOOT_VERSION，这个变量记录了Makefile中配置的版本号。

(3)include/version_autogenerated.h文件是编译过程中自动生成的一个文件，所以源目录中没有，但是编译过后的uboot中就有了。它里面的内容是一个宏定义

，宏定义的值内容就是我们在Makefile中配置的uboot的版本号。

(4)验证方法：自己修改主Makefile中几个Version有关的变量，然后重新编译uboot，然后烧录到SD卡中，从SD卡启动，然后去看启动时uboot打印出来的版本信

息，看看变化是不是和自己的分析一致。

2.4.1.2、HOSTARCH和HOSTOS

(1)直接在shell中执行uname -m得到i686，得到的值其实你当前执行这个命令的电脑的CPU的版本号。

(2)shell中的|叫做管道，管道的作用就是把管道前面一个运算式的输出作为后面一个的输入再去做处理，最终的输出才是我们整个式子的输出。

(3)HOSTARCH这个名字：HOST是主机，就是当前在做开发用的这台电脑就叫主机；ARCH是architecture(架构)的缩写，表示CPU的架构。所以HOSTARCH就表示主机

的CPU的架构。

(4)这两个环境变量是主机的操作系统和主机的CPU架构，得出后保存备用，后面自然会用到。

2.4.2.uboot主Makefile分析2

2.4.2.1、静默编译（50-54行）

(1)平时默认编译时命令行会打印出来很多编译信息。但是有时候我们不希望看到这些编译信息，就后台编译即可。这就叫静默编译。

(2)使用方法就是编译时make -s，-s会作为MAKEFLAGS传给Makefile，在50-54行这段代码作用下XECHO变量就会被变成空（默认等于echo），于是实现了静默编

译。

2.4.2.2、2种编译方法（原地编译和单独输出文件夹编译）

(1)编译复杂项目，Makefile提供2种编译管理方法。默认情况下是当前文件夹中的.c文件，编译出来的.o文件会放在同一文件夹下。这种方式叫原地编译。原地

编译的好处就是处理起来简单。

(2)原地编译有一些坏处：第一，污染了源文件目录。第二的缺陷就是一套源代码只能按照一种配置和编译方法进行处理，无法同时维护2个或2个以上的配置编

译方式。

(3)为了解决以上2种缺陷，uboot支持单独输出文件夹方式的编译（linux kernel也支持，而且uboot的这种技术就是从linux kernel学习来的）。基本思路就

是在编译时另外指定一个输出目录，将来所有的编译生成的.o文件或生成的其他文件全部丢到那个输出目录下去。源代码目录不做任何污染，这样输出目录就

承载了本次配置编译的所有结果。

(4)具体用法：默认的就是原地编译。如果需要指定具体的输出目录编译则有2种方式来指定输出目录。（具体参考Makefile 56-76行注释内容）

第一种：make O=输出目录

第二种：export BUILD_DIR=输出目录 然后再make

如果两个都指定了（既有BUILD_DIR环境变量存在，又有O=xx），则O=xx具有更高优先级，听他的。

(5)两种编译的实现代码在Makefile的78-123行。

2.4.2.3、编译方法实践

2.4.2.4、相关Makefile分析

2.4.3.uboot主Makefile分析3

2.4.3.1、OBJTREE、SRCTREE、TOPDIR

(1)OBJTREE：编译出的.o文件存放的目录的根目录。在默认编译下，OBJTREE等于当前目录；在O=xx编译下，OBJTREE就等于我们设置的那个输出目录。

(2)SRCTREE: 源码目录，其实就是源代码的根目录，也就是当前目录。

总结：在默认编译下，OBJTREE和SRCTREE相等；在O=xx这种编译下OBJTREE和SRCTREE不相等。Makefile中定义这两个变量，其实就是为了记录编译后的.o文件往

哪里放，就是为了实现O=xx的这种编译方式的。

2.4.3.2、MKCONFIG（Makefile的101行）

(1)Makefile中定义的一个变量（在这里定义，在后面使用），它的值就是我们源码根目录下面的mkconfig。

这个mkconfig是一个脚本，这个脚本就是uboot配置阶段的配置脚本。后面要用至少3节课详细讲这个配置脚本的工作。

****2.4.3.3、include $(obj)include/config.mk（133行）

(1)include/config.mk不是源码自带的（你在没有编译过的源码目录下是找不到这个文件的），要在配置过程（make x210_sd_config）中才会生成这个文件。

因此这个文件的值和我们配置过程有关，是由配置过程根据我们的配置自动生成的。

(2)我们X210在iNand情况下配置生成的config.mk内容为：

ARCH  = arm

CPU    = s5pc11x

BOARD  = x210

VENDOR = samsung

SOC    = s5pc110

(3)我们在下一行（134行）export导出了这5个变量作为环境变量。所以着两行加起来其实就是为当前makefile定义了5个环境变量而已。之所以不直接给出这

5个环境变量的值，是因为我们希望这5个值是可以被人很容易的、集中的配置的。

(4)这里的配置值来自于2589行那里的配置项。如果我们要更改这里的某个配置值要到2589行那里调用MKCONFIG脚本传参时的参数。

2.4.3.4、ARCH CROSS_COMPILE

(1)接下来有2个很重要的环境变量。一个是ARCH，上面导出的，值来自于我们的配置过程，它的值会影响后面的CROSS_COMPILE环境变量的值。ARCH的意义是定

义当前编译的目标CPU的架构。

(2)CROSS_COMPILE是定义交叉编译工具链的前缀的。定义这些前缀是为了在后面用（用前缀加上后缀来定义编译过程中用到的各种工具链中的工具）。我们把

前缀和后缀分开还有一个原因就是：在不同CPU架构上的交叉编译工具链，只是前缀不一样，后缀都是一样的。因此定义时把前缀和后缀分开，只需要在定义

前缀时区分各种架构即可实现可移植性。

(3)CROSS_COMPILE在136-182行来确定。CROSS_COMPILE是被ARCH所确定的，只要配置了ARCH=arm，那么我们就只能在ARM的那个分支去设置CROSS_COMPILE的值。

这个设置值只要能保证找到那个交叉编译工具链即可，不一定非得是全路径的，相对路径也可以。（如果已经将工具链导出到环境变量，并且设置了符号链接，

这样CROSS_COMPILE = arm-linux-就可以）

(4)实际运用时，我们可以在Makefile中去更改设置CROSS_COMPILE的值，也可以在编译时用make CROSS_COMPILE=xxxx来设置，而且编译时传参的方法可以覆盖

Makefile里面的设置。

2.4.4.uboot主Makefile分析4

2.4.4.1、$(TOPDIR)/config.mk（主Makefile的185行）

2.4.4.2、编译工具定义（config.mk 94-107行）

2.4.4.3、包含开发板配置项目（config.mk, 112行）

(1)autoconfig.mk文件不是源码提供的，是配置过程自动生成的。

(2)这个文件的作用就是用来指导整个uboot的编译过程。这个文件的内容其实就是很多CONFIG_开头的宏（可以理解为变量），这些宏/变量会影响我们uboot编

译过程的走向（原理就是条件编译）。在uboot代码中有很多地方使用条件编译进行编写，这个条件编译是用来实现可移植性的。（可以说uboot的源代码在很

大程度来说是拼凑起来的，同一个代码包含了各种不同开发板的适用代码，用条件编译进行区别。）

(3)这个文件不是凭空产生的，配置过程也是需要原材料来产生这个文件的。原材料在源码目录的inlcude/configs/xxx.h头文件。（X210开发板中为include/

configs/x210_sd.h）。这个h头文件里面全都是宏定义，这些宏定义就是我们对当前开发板的移植。每一个开发板的移植都对应这个目录下的一个头文件，这个

头文件里每一个宏定义都很重要，这些配置的宏定义就是我们移植uboot的关键所在。

2.4.5.uboot主Makefile分析5

2.4.5.1、链接脚本（config.mk 142-149行）

(1)如果定义了CONFIG_NAND_U_BOOT宏，则链接脚本叫u-boot-nand.lds，如果未定义这个宏则链接脚本叫u-boot.lds。

(2)从字面意思分析，即可知：CONFIG_NAND_U_BOOT是在Nand版本情况下才使用的，我们使用的X210都是iNand版本的，因此这个宏没有的。

(3)实际在board\samsung\x210目录下有u-boot.lds，这个就是链接脚本。我们在分析uboot的编译链接过程时就要考虑这个链接脚本。

2.4.5.2、TEXT_BASE（config.mk 156-158行）

(1)Makefile中在配置X210开发板时，在board/samsung/x210目录下生成了一个文件config.mk，其中的内容就是：TEXT_BASE = 0xc3e00000相当于定义了一个

变量。

(2)TEXT_BASE是将来我们整个uboot链接时指定的链接地址。因为uboot中启用了虚拟地址映射，因此这个C3E00000地址就等于0x23E00000(也可能是33E00000具

体地址要取决于uboot中做的虚拟地址映射关系)。

(3)回顾裸机中讲的链接地址的问题，再想想dnw方式先下载x210_usb.bin然后再下载uboot.bin时为什么第二个地址是23E00000.

2.4.5.3、自动推导规则（config.mk 239-256行）

(1)我们在讲Makefile时提到过自动推导规则，具体理解可以参考《跟我一起学Makefile》

2.4.6.uboot主Makefile分析6

(1)291行出现了整个主Makefile中第一个目标all（也就是默认目标，我们直接在uboot根目录下make其实就等于make all，就等于make这个目标）

(2)目标中有一些比较重要的。譬如：u-boot是最终编译链接生成的elf格式的可执行文件，

(3)unconfig字面意思来理解就是未配置。这个符号用来做为我们各个开发板配置目标的依赖。目标是当我们已经配置过一个开发板后再次去配置时还可以配置。

(4)我们配置开发板时使用：make x210_sd_config，因此分析x210_sd_config肯定是主Makefile中的一个目标。

2.4.7.uboot配置过程详解1

(1)mkconfig脚本的6个参数

$(@:_config=) arm s5pc11x x210 samsung s5pc110(Makefile中2590行)

x210_sd_config里的_config部分用空替换，得到：x210_sd，这就是第一个参数，所以：

$1: x210_sd

$2: arm

$3: s5pc11x

$4: x210

$5: samsumg

$6: s5pc110

所以，$# = 6

(2)第23行：其实就是看BOARD_NAME变量是否有值，如果有值就维持不变；如果无值就给他赋值为$1，实际分析结果：BOARD_NAME=x210_sd

(3)第25行：如果$#小于4，则exit 1（mkconfig脚本返回1）

(4)第26行：如果$#大于6，则也返回1.

所以：mkconfig脚本传参只能是4、5、6，如果大于6或者小于4都不行。

(5)从第33行到第118行，都是在创建符号链接。为什么要创建符号链接？这些符号链接文件的存在就是整个配置过程的核心，这些符号链接文件（文件夹）

的主要作用是给头文件包含等过程提供指向性连接。根本目的是让uboot具有可移植性。

uboot可移植性的实现原理：在uboot中有很多彼此平行的代码，各自属于各自不同的架构/CPU/开发板，我们在具体到一个开发板的编译时用符号连接的方式提

供一个具体的名字的文件夹供编译时使用。这样就可以在配置的过程中通过不同的配置使用不同的文件，就可以正确的包含正确的文件。

(6)创建的符号链接：

第一个：在include目录下创建asm文件，指向asm-arm。（46-48行）

第二个：在inlcude/asm-arm下创建一个arch文件，指向include/asm-arm/arch-s5pc110

第三个：在include目录下创建regs.h文件，指向include/s5pc110.h

删除第二个。

第四个：在inlcude/asm-arm下创建一个arch文件，指向include/asm-arm/arch-s5pc11x

第五个：在include/asm-arm下创建一个proc文件，指向include/asm-arm/proc-armv

总结：一共创建了4个符号链接。这4个符号链接将来在写代码过程中，头文件包含时非常有用。譬如一个头文件包含可能是：#include <asm/xx.h>

2.4.8.uboot配置过程详解2

(1)创建include/config.mk文件（mkconfig文件123-129行）

(2)创建include/config.mk文件是为了让主Makefile在第133行去包含的（详解见2.4.3.3节）。

(3)思考：uboot的配置和编译过程的配合。编译的时候需要ARCH=arm、CPU=xx等这些变量来指导编译，配置的时候就是为编译阶段提供这些变量。那为什么不

在Makefile中直接定义这些变量去使用，而要在mkconfig脚本中创建config.mk文件然后又在Makefile中include这些文件呢？

(4)理解这些脚本时，时刻要注意自己当前所处的路径。

(5)创建（默认情况）/追加（make -a时追加）include/config.h文件（mkconfig文件的134-141行）。

(6)这个文件里面的内容就一行#include <configs/x210_sd.h>，这个头文件是我们移植x210开发板时，对开发板的宏定义配置文件。这个文件是我们移植x210

时最主要的文件。

(7)x210_sd.h文件会被用来生成一个autoconfig.mk文件，这个文件会被主Makefile引入，指导整个编译过程。这里面的这些宏定义会影响我们对uboot中大部分.c文件中一些条件编译的选择。从而实现最终的可移植性。

注意：uboot的整个配置过程，很多文件之间是有关联的（有时候这个文件是在那个文件中创建出来的；有时候这个文件被那个文件包含进去；有时候这个文件

是由那个文件的内容生成的决定的）

注意：uboot中配置和编译过程，所有的文件或者全局变量都是字符串形式的（不是指的C语言字符串的概念，指的是都是字符组成的序列）。这意味着我们整

个uboot的配置过程都是字符串匹配的，所以一定要细节，注意大小写，要注意不要输错字符，因为一旦错一个最后会出现一些莫名其妙的错误，很难排查，

这个是uboot移植过程中新手来说最难的地方。

2.4.9.uboot的链接脚本

(1)uboot的链接脚本和我们之前裸机中的链接脚本并没有本质区别，只是复杂度高一些，文件多一些，使用到的技巧多一些。

(2)ENTRY(_start)用来指定整个程序的入口地址。所谓入口地址就是整个程序的开头地址，可以认为就是整个程序的第一句指令。有点像C语言中的main。

(3)之前在裸机中告诉大家，指定程序的链接地址有2种方法：一种是在Makefile中ld的flags用-Ttext 0x20000000来指定；第二种是在链接脚本的SECTIONS开头

用.=0x20000000来指定。两种都可以实现相同效果。其实，这两种技巧是可以共同配合使用的，也就是说既在链接脚本中指定也在ld flags中用-Ttext来指定。

两个都指定以后以-Ttext指定的为准。

(4)uboot的最终链接起始地址就是在Makefile中用-Ttext 来指定的，具体参见2.4.5.2节，注意TEXT_BASE变量。最终来源是Makefile中配置对应的命令中，在

make xxx_config时得到的。

(5)在代码段中注意文件排列的顺序。指定必须放在前面部分的那些文件就是那些必须安排在前16KB内的文件，这些文件中的函数在前16KB会被调用。在后面第

二部分（16KB之后）中调用的程序，前后顺序就无所谓了。

(6)链接脚本中除了.text  .data .rodata .bss段等编译工具自带的段之外，编译工具还允许我们自定义段。譬如uboot总的.u_boot_cmd段就是自定义段。自

定义段很重要。