u-boot编译分析
在配置完成后，执行make开始编译。这里打开Makefile。
首先在目标all前有一句话首先检查是否有include/config.mk文件来判断是否成功配置过。
ifeq ($(obj)include/config.mk,$(wildcard $(obj)include/config.mk))
下面分析“make”命令正常执行的过程。
include/autoconf.mk生成过程
首先包含头文件autoconf.mk.dep、autoconf.mk。这是与开发板相关的一些宏定义。在Makefile执行过程中，需要根据某些宏定义来确定执行哪些操作。
all:
sinclude $(obj)include/autoconf.mk.dep
sinclude $(obj)include/autoconf.mk # load ARCH, BOARD, and CPU configuration
include $(obj)include/config.mk //配置时生成的
export ARCH CPU BOARD VENDOR SOC
（在配置时会删除autoconf.mk.dep和autoconf.mk这两个文件，在执行make后创建它。这两个文件该如何更新？我在GUN make使用手册中发现这句话。
make 在读入所有 makefile 文件之后，首先将所读取的每个 makefile 作为一个目标，寻找更新它们的规则。如果存在一个更新某一个 makefile 文件明确规则或者隐含规则，就去更新对应的 makefile 文件。完成对所有的 makefile 文件的更新之后，如果之前所读取任何一个 makefile 文件被更新，那么 make 就清除本次执行的状态重新读取一遍所有的 makefile 文件（此过程中，同样在读取完成以后也会去试图更新所有的已经读取的 makefile 文件，但是一般这些文件不会再次被重建，因为它们在时间戳上 已经是最新的）。读取完成以后再开始解析已经读取的 makefile 文件并开始执行必要 的动作。
故在包含头文件后，会把头文件作为目标在Makefile寻找相应的规则，执行后会再次包含更新后的规则。)
$(obj)include/autoconf.mk.dep: $(obj)include/config.h include/common.h
@$(XECHO) Generating $@ ; \
set -e ; \
: Generate the dependancies ; \
$(CC) -x c -DDO_DEPS_ONLY -M $(HOSTCFLAGS) $(CPPFLAGS) \
-MQ $(obj)include/autoconf.mk include/common.h > $@ $(obj)include/autoconf.mk: $(obj)include/config.h
@$(XECHO) Generating $@ ; \
set -e ; \
: Extract the config macros ; \
$(CPP) $(CFLAGS) -DDO_DEPS_ONLY -dM include/common.h | \
sed -n -f tools/scripts/define2mk.sed > $@.tmp && \
mv $@.tmp $@
编译选项-dM的作用是输出 include/common.h中定义的所有宏。然后输出给 tools/scripts/define2mk.sed。而该脚本主要完成了在common.h中查找和处理以CONFIG_开头的宏定义。
然后包含该include/config.mk 配置 ARCH CPU BOARD VENDOR SOC
之后判断主机架构和开发板是否相同，若相同则用主机的架构。
然后包含顶层目录中的config.mk。
# load other configuration
include $(TOPDIR)/config.mk
config.mk文件执行过程。
首先设置src和obj为空。
cc-option保存编译选项
使用FLAGS +$=（call cc-option ,option1, option2）来调用。
然后是指定交叉工具链。
CROSS_COMPILE在 arch/$(ARCH)/config.mk 中指定
包含开发板的相关配置文件。
指定隐含的编译规则。
u-boot镜像生成过程
在顶层目录下的Makefile中有两个all：
第一个all:没有依赖，也没有命令。后面接的是两条
sinclude sinclude $(obj)include/autoconf.mk.dep
sinclude $(obj)include/autoconf.mk
第二个all：
all: $(ALL)
这个all才是我们真正需要执行的
要理解这里的all 空命令的作用。必须了解下面几个点
1. 当makefile中有两个相同目标的时候，会执行后一个目标。因为后一个目标会重载前一个。比如：
all:
echo all1
all:
echo all2
执行make 会输出后一个all2
2. 伪目标
一个使用地方是 当不需要产生一个实际的目标文件的时候（比如只要执行指令）。
clean:
rm *.o
这样是不产生文件。只需要执行指令。如果当前目录没有一个文件叫做clean。执行make clean是正常的 。如果目录下有一个clean文件。那么由于这个clean文件是最新的，因此就不会执行rm *.o操作。因此需要定义一个伪目标。不管目录下是否存在这个目标。都会执行clean的操作rm *.o
.PHONY clean
clean:
rm *.o
3. 空命令
可以存在依赖文件，但是没有命令行。比如
all:
或者
all: $(obj)
空命令的唯一作用是防止make在执行时，试图为重建这个目标去查找隐含命令
这句话暂时不好理解。先看后面的再说。
4. makefile的执行规则和include 这个是关键点
makefile首先被解析。
遇到include。先去解析include的文件（假设为inc.mk），解析完毕以后再回头来解析原makefile。
关键点是如果这个inc.mk不存在。make不会退出。而是先提出一个警告，继续处理原makefile的内容。
等到原makefile的内容处理完毕以后。会尝试使用规则来重建这个inc.mk文件,也就是尝试将这个inc.mk文件当做一个目标来执行。如果不能重建出这个inc.mk。那么报告一个错误，make退出。如果这个inc.mk重建成功了。那么将原makefile的状态重置，重新开始执行这个makefile。
参考：http://blog.csdn.net/groundhappy/article/details/52708792
可以这样理解。第一个all是为了避免将include中包含的Makefile的第一个目标作为终极目标而设置的。主要是第二个all：，这个才是make中执行的
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_NAND) $(U_BOOT_ONENAND)
all: $(ALL)
下面分析u-boot.bin文件的生成过程。
$(obj)u-boot.bin: $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
$(BOARD_SIZE_CHECK)
而u-boot.bin依赖于u-boot。这里的uboot就是ELF格式的u-boot文件
$(obj)u-boot: depend \
$(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) $(obj)u-boot.lds
$(GEN_UBOOT)
下面分析u-boot的各个依赖。
1）depend依赖。依次进入$(SUBDIRS) $(CPUDIR) $(dir $(LDSCRIPT))表示的子目录中，并执行make _depend命令，生成各个子目录的.depend文件，在.depend文件中列出每个目标文件的依赖文件。
depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) \
$(obj)include/autoconf.mk \
$(obj)include/generated/generic-asm-offsets.h
for dir in $(SUBDIRS) $(CPUDIR) $(dir $(LDSCRIPT)) ; do \
$(MAKE) -C $$dir _depend ; done
2）$(SUBDIRS)依赖。
SUBDIRS = tools \
examples/standalone \
examples/api
其依赖的规则如下。这表示生成它的方式是执行tool、example/standalone、examples/api目录下的Makefile。
$(SUBDIRS): depend
$(MAKE) -C $@ all
3）$(OBJS)依赖，其变量值是$(CPUDIR) $(dir $(LDSCRIPT)
$(OBJS): depend
$(MAKE) -C $(CPUDIR) $(if $(REMOTE_BUILD),$@,$(notdir $@))
以上规则表明，$(OBJS)表示的目标文件，都是通过进入$(CPUDIR)目录执行make命令编译得到的。
4） $(LIBBOARD) 、$(LIBS) 、$(LDSCRIPT) 同上。
5） $(obj)u-boot.lds依赖。LDSCRIPT定义在arch/arm/config.mk中。board/samsung/$(BOARD)/u-boot.lds
$(obj)u-boot.lds: $(LDSCRIPT)
$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@
u-boot.lds内容如下：
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") //指定输出可执行文件是32位ARM指令，小端模式的ELF格式。
OUTPUT_ARCH(arm) //指定输出可执行文件的平台为ARM
ENTRY(_start) //指定程序的入口为_start
SECTIONS
{
. = 0x00000000; //指明目标代码的起始地址从0x0位置开始， ‘.’代表当前位置
. = ALIGN(4); //表示此处4字节对齐
.text :
{
arch/arm/cpu/armv7/start.o (.text) //表示start.o是代码段的第一个.o文件
board/samsung/tiny4412/libtiny4412.o (.text) //这是代码段的其他部分
arch/arm/cpu/armv7/exynos/libexynos.o (.text)
*(.text)
}
. = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } //表示这是只读数据段
. = ALIGN(4);
.data : { //这是数据段
*(.data)
}
. = ALIGN(4);
. = .;
__u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;
. = ALIGN(4);
.rel.dyn : {
__rel_dyn_start = .;
*(.rel*)
__rel_dyn_end = .;
}
.dynsym : {
__dynsym_start = .;
*(.dynsym)
}
.bss __rel_dyn_start (OVERLAY) : {
__bss_start = .; //表示_bss_start标号指向bss段的开始位置
*(.bss) //这是bss段
. = ALIGN(4);
_end = .;
}
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
/DISCARD/ : { *(.plt*) }
/DISCARD/ : { *(.interp*) }
/DISCARD/ : { *(.gnu*) }
}
.