嵌入式Linux驱动学习之路(四)u-boot编译分析

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*) }
}

.