这东西已经写,我们没有时间发布,如今,终于有时间稍微长送记录汇总uboot学习过程。具体了。以后忘了也能够再温习回来嘛有些特殊字符显示得乱掉了

Makefile追踪技巧:

技巧1:能够先从编译目标開始顺藤摸瓜地分析,先不要关注详细细节,着重关注基本的代码结构和编译过程

技巧2:追踪分析时要通过文本或者其它途径临时记录重要的线索

技巧3:将基本的Makefile文件里export出来的变量以及include的文件提取出来,看看include的文件大致是些什么文件,当看到一些来历不明的变量或者操作时能够从这些记录中查找是否有相关记录(将Make涉及的配置文件找出来,相当于形成了一个闭合的环境)

为什么要去研究uboot的Makefile?由于要研究一个project代码,最好的方法就是阅读其Makefile,Makefile会告诉我们project的模块结构以及目标的详细编译和连接过程,读懂了Makefile无疑就是对project结构和代码结构了如指掌。相当于一张地图,是移植以及学习其技术的基础。

在这里,是以smart210的uboot_smart210作为剖析对象。其原生uboot版本号是u-boot-2011.06。uboot的全部Makefile有2000行左右的代码,当中的关系也比較复杂,要想读懂其Makefile,必需要对Make工具的的语法规则和shell脚本比較熟悉,这是阅读的基础,里面非常多非常关键的地方用到了grep、sed和awk等文本处理工具,当然能够边看边学。

此外。还要善于使用搜索,最好能够自己写一些简单的自己主动搜索脚本,由于Makefile里面有非常多变量并非在同一个文件中面定义或赋值,善用搜索。必然能够节约非常多的精力。

怎样编译smart10的uboot?

编译smart210的uboot命令是:

make samrt210

这是相对于曾经的老版本号进行的改进,老版本号一般是现用make xx_config进行配置,然后再用make进行编译,当然后来的版本号也依旧能够使用这种方式进行编译。后来版本号的Makefile结构有了较大的变动。

Make主要过程

在uboot的整个编译过程中,源代码根文件夹下的主Makefile被make读取运行了两次。第一次是完毕编译环境的配置以及相关编译參数的配置;第二次是開始真正的编译过程。

u-bootMakefile主要流程

第一次读入运行Makefile:

1.产生编译目标和对应规则。

从编译命令入手,可是我们在Makefile中根本就无法搜索到smart210的字眼,更不要说smart210这个目标。在代码根文件夹搜索会发现,smart210的字眼出如今boards.cfg。

原来是uboot为了易于拓展对平台和各种开发板,将各种开发板的相关信息集中放在这个文件里,例如以下图:

smart210                        arm   armv7      smart210    samsung   s5pc1xx

那么这个文件是怎么被引入到Makefile中的呢?

在这里:

sinclude $(obj).boards.depend

$(obj).boards.depend:     boards.cfg

awk'(NF && $$1 !~ /^#/) { print $$1 ": " $$1 "_config;$$(MAKE)" }' $< > $@

要理解3句语句,必需要知道make的工作过程。

运行make smart210指令时,make会把全部引用的文件展开到Makefile中,假设发现有文件无法找到时便会查找使用对应规则来尝试创建对应的文件。

sinclude$(obj).boards.depend这句语句运行时,代码文件夹下是没有这个文件的,那么make便运行

$(obj).boards.depend:     boards.cfg

awk'(NF && $$1 !~ /^#/) { print $$1 ": " $$1 "_config;$$(MAKE)" }' $< > $@

规则来生成.boards.depend文件,.boards.depend是依赖boards.cfg来生成的,当中的内容类似为:

……….

smart210: smart210_config; $(MAKE)

smdkc100: smdkc100_config; $(MAKE)

………..

可见。各种开发板的编译目标和规则现都已产生,而且被引入到Makefile中。因此此时Makefile中便已存在各种开发板的编译目标和规则。

2.配置编译环境。

在(1)中生成了编译目标和对应的规则:

smart210: smart210_config; $(MAKE)

这句规则的依赖的规则是smart210_config,故先运行规则生成依赖。

smart210_config的生成规则:

%_config::        unconfig

@$(MKCONFIG)-A $(@:_config=)

其运行的命令就是:./mkconfig –A smart210,uboot的编译环境绝大部分就是在这个脚本中进行配置的。接下来看看这个脚本到底主要做了些什么事情。

if [ \( $# -eq 2 \) -a \( "$1" ="-A" \) ] ; then

#Automatic mode

##从boards.cfg抽取出smart210那一行信息

line=`egrep-i "^[[:space:]]*${2}[[:space:]]" boards.cfg` || {

echo"make: *** No rule to make target \`$2_config'.  Stop." >&2

exit1

}

set${line}         ##将line中的字符串分别赋值给位置參数$1,$2,$3.....

#add default board name if needed

[$# = 3 ] && set ${line} ${1}

fi

语句line=`egrep -i"^[[:space:]]*${2}[[:space:]]" boards.cfg`从boards.cfg抽取出smart210那一行信息。并保存到变量line中。set ${line}将line中的字符串分别赋值给位置參数$1,$2,$3.....,由boards.cfg中说保存的信息类型可知。这里相当于是将Target、ARCH、CPU、Board name 、Vendor、SoC等平台相关或者板级相关的将用于配置编译环境的必要信息提取了出来。

echo "ARCH   = ${arch}"  > config.mk

echo "CPU    = ${cpu}"   >> config.mk

echo "BOARD  = ${board}" >> config.mk

[ "${vendor}" ] && echo"VENDOR = ${vendor}" >> config.mk

[ "${soc}"    ] && echo "SOC    = ${soc}"    >> config.mk

上面的语句将提取的ARCH、CPU、BOARD、VENDOR、SOC保存到config.mk文件里。这个文件将被Makefile引用以获取平台相关或者板级相关的信息来进行编译。

……

else

cd./include

rm-f asm

ln-s ../arch/${arch}/include/asm asm

echo"ln -s ../arch/${arch}/include/asm asm"

fi

上面先删除曾经建立的连接,然后ln -s../arch/${arch}/include/asm asm在include文件夹下创建一个平台相关的头文件夹连接。

rm -f asm/arch

……

else

ln-s ${LNPREFIX}arch-${soc} asm/arch

echo"ln -s ${LNPREFIX}arch-${soc} asm/arch"

fi

上面先include/asm/文件夹下的旧的连接, 然后ln -s${LNPREFIX}arch-${soc} asm/arch在include/asm/中创建一个片上系统(也就是同一平台下的一类芯片)相关的连接。

…….

cat << EOF>> config.h

#defineCONFIG_BOARDDIR board/$BOARDDIR

#include<config_cmd_defaults.h>

#include<config_defaults.h>

#include<configs/${CONFIG_NAME}.h>  #即#include<configs/smart210.h>

#include<asm/config.h>

EOF

最后,生成include/config.h,将配置相关的头文件集中在config.h中引用。

编译环境配置小结:

(1)      提取ARCH、CPU、BOARD、VENDOR、SOC等平台相关或者板级相关的信息保存到config.mk文件里备用。

(2)      在include文件夹下创建一个平台相关的头文件夹连接。

(3)      在include/asm/中创建一个片上系统相关的头文件连接。

(4)      将配置相关的头文件集中在config.h中引用。

3.生成Makefile编译时所依赖的配置文件及其依赖关系

           Makefile编译时依赖的配置文件是include/autoconf.mk。其头文件依赖关系存放在include/autoconf.mk.dep文件里。那么这两个文件是怎么被引入到Makefile中的呢?

sinclude$(obj)include/autoconf.mk.dep

sinclude$(obj)include/autoconf.mk

make展开Makefile中上面这两句语句时,没有发现对应文件,便使用规则生成它们。

project中的文件的数量的是很庞大的数字。而每一个文件依赖的文件也是许多。如要要将每一个文件的依赖手工一一列出,那工作量是相当繁重的,也不利于代码的移植,因此uboot利用make工具和gcc编译器的特性自己主动生成以及维护文件依赖关系。Make支持多规则目标。可是仅仅能在一个规则中定义命令。换句话来说就是说同一目标的依赖能够不止出如今一个规则中,而gcc的选项-M可生成源文件和头文件的make可用的依赖关系,自己主动生成依赖关系就是利用了这个make特性和gcc的特性。

autoconf.mk.dep的生成规则例如以下:

$(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 > $@

gcc的选项-M可用于生成文件的make可用的依赖关系,-MQ用于指定目标名。-x指定语言类型。

生成的autoconf.mk.dep的内容例如以下:

include/autoconf.mk:include/common.h /home/zqb/uboot/uboot_smart210/include/config.h\

……..

显然,这就是autoconf.mk的依赖关系,autoconf.mk.dep中的规则仅仅有依赖关系而没有命令。

Uboot的配置主要是通过改动include/configs/中的头文件里宏来实现,有非常多的编译选项也是在当中改动,那么问题就来了,make工具可不认识头文件里的宏语法。所以Makefile中通过一些规则调用sed文本处理工具来生成我们想要的配置格式。

$(obj)include/autoconf.mk:$(obj)include/config.h

@$(XECHO) Generating $@ ; \

set -e ; \

: Extract the config macros ; \

$(CPP) $(CFLAGS) -DDO_DEPS_ONLY -dMinclude/common.h | \

sed -n -ftools/scripts/define2mk.sed > $@.tmp && \

mv $@.tmp $@

上面的规则是利用sed工具来进行的,sed的工作方式由tools/scripts/define2mk.sed来指定,头文件里的配置方式是宏。如#define CONFIG_xx xxx。而成的make可用的配置的autoconf.mk文件格式例如以下:

……..

CONFIG_CMD_ITEST=y

CONFIG_CMD_BDI=y

CONFIG_SYS_MAX_NAND_DEVICE=y

……….

事实上就是将头文件里的宏定义转化为了make的变量作为控制开关。比如:

Ifeq($(CONFIG_CMD_ITEST),y)

#do_something

Endif

用上述的方式来生成Makefile编译时所依赖的配置文件及其依赖关系,便可实现自己主动生成相关依赖关系以及因相关的配置文件的修改而又一次编译project,不再须要人工去生成及维护其依赖关系。

第二次读入运行Makefile:

规则smart210: smart210_config;$(MAKE)完毕了依赖smart210_config更新后再次调用make,開始了第二次读入运行Makefile。

1.展开全部的配置文件的配置

主要展开的是:

sinclude $(obj)include/autoconf.mk.dep

sinclude $(obj)include/autoconf.mk         #基本的编译配置都在这个文件里。故其很重要

…….

include $(obj)include/config.mk                #平台相关或板级相关的信息

……

include $(TOPDIR)/config.mk

源代码根文件夹下的config.mk中语句主要完毕了依据配置项进行的编译选项的配置。如使用什么编译器、连接器,这些编译器、连接器的编译选项是什么:

AS     = $(CROSS_COMPILE)as  #汇编器

LD    = $(CROSS_COMPILE)ld           #连接器

CC    = $(CROSS_COMPILE)gcc        #编译器

CPP  = $(CC) -E                  #预处理

AR    = $(CROSS_COMPILE)ar          #归档器

………

此外。config.mk还包括了一些通用的源文件编译规则,例如以下:

$(obj)%.s:         %.S

$(CPP) $(ALL_AFLAGS) -o $@ $<

$(obj)%.o:         %.S

$(CC) $(ALL_AFLAGS) -o $@ $< -c

$(obj)%.o:         %.c

$(CC) $(ALL_CFLAGS) -o $@ $< -c

$(obj)%.i: %.c

$(CPP) $(ALL_CFLAGS) -o $@ $< -c

$(obj)%.s:         %.c

$(CC)  $(ALL_CFLAGS) -o $@ $< -c –S

2.生成终于目标

第二次读入并运行Makefile并没有指定终极目标,故其终极目标默觉得第一个目标,也即是:

all:

sinclude $(obj)include/autoconf.mk.dep

……..

all:             $(ALL-y)

你会发现,第一个目标all在Makefile中出现了两次。这是为什么呢?第一个目标规则仅仅有一个目标名,而没有依赖和命令,其出现是为了防止autoconf.mk.dep中的目标成为了终极目标,而后面出现的all:  $(ALL-y)才是真正的终极目标。这里也利用了make支持多规则目标的特性。all:  $(ALL-y)展开后:

all:    u-boot.srec u-boot.binSystem.map spl/u-boot-spl.bin

那么便可知道,终于生成的目标有u-boot.srec u-boot.bin System.map spl/u-boot-spl.bin。

先看看当中两个目标的规则:

…….

$(obj)u-boot.srec:    $(obj)u-boot

$(OBJCOPY) -O srec $< $@

$(obj)u-boot.bin:      $(obj)u-boot

$(OBJCOPY) ${OBJCFLAGS} -Obinary $< $@

$(BOARD_SIZE_CHECK)

……

你会发现终于的那几个目标都依赖u-boot目标,u-boot的规则例如以下:

$(obj)u-boot:    depend \

$(SUBDIRS) $(OBJS)$(LIBBOARD) $(LIBS) $(LDSCRIPT) $(obj)u-boot.lds

$(GEN_UBOOT)

在这之后里,逐个调用依赖的生成规则继续进行编译,如depend、$(OBJS) $(LIBBOARD)等的生成。

源文件的编译看后面的“3.各个子文件夹下须要编译生成的目标文件被分门别类地编译”。

各源文件编译完毕后,连接生成目标u-boot:

GEN_UBOOT = \

UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD)$(LIBS) | \

sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\

cd $(LNDIR) && $(LD) $(LDFLAGS)$(LDFLAGS_$(@F)) $$UNDEF_SYM $(__OBJS) \

--start-group $(__LIBS) --end-group$(PLATFORM_LIBS) \

-Map u-boot.map -o u-boot

elf格式的u-boot被连接生成后,u-boot.srec u-boot.bin System.map spl/u-boot-spl.bin就接着被生成了。其过程并不复杂。

3.各个子文件夹下须要编译生成的目标文件被分门别类地编译

uboot的開始运行的代码目标:

OBJS  =$(CPUDIR)/start.o

uboot板级密切相关的代码编译打包为:

LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o

其它的同一处理器通用的源文件打包为:

LIBS  = lib/libgeneric.o

LIBS +=lib/lzma/liblzma.o

LIBS += lib/lzo/liblzo.o

…….

接下来看看怎样进行编译:

$(OBJS):   depend

$(MAKE) -C $(CPUDIR) $(if$(REMOTE_BUILD),$@,$(notdir $@))

$(LIBS):    depend $(SUBDIRS)

$(MAKE) -C $(dir $(subst$(obj),,$@))

$(LIBBOARD):  depend $(LIBS)

$(MAKE)-C $(dir $(subst $(obj),,$@))

make的dir函数可将文件的路径提取出来,$(MAKE) -C $(dir $(subst $(obj),,$@))的意思是到目标所在文件夹下去读取该文件夹下的Makefile进行编译,这样全部的目标和库都能够生成了。

4.子文件夹下的Makefile

make会像前面所说的那样调用子文件夹中的Makefile进行编译。

在这里drivers/bios_emulator/文件夹下的Makefile进行剖析。其它文件夹的Makefile都是以类似的方式工作。

include$(TOPDIR)/config.mk

makefile通过引用源代码顶层文件夹下的config.mk来配置编译选项,并引入了一些通用的源文件编译规则,如:

AS     =$(CROSS_COMPILE)as  #汇编器

LD    =$(CROSS_COMPILE)ld           #连接器

CC    =$(CROSS_COMPILE)gcc        #编译器

………

$(obj)%.o:         %.S

$(CC)  $(ALL_AFLAGS) -o $@ $< -c

$(obj)%.o:         %.c

Makefile中通过include$(SRCTREE)/rules.mk引入了源代码顶层文件夹下的rules.mk文件。该文件里的规则完毕了头文件依赖关系的自己主动生成,这也是如前面提到的一样。利用了make和gcc的特性。此外,rules.mk文件里还包括了编译宿主机下的目标的规则。那些在宿主机中使用的工具会用到这些规则来编译。

Makefile的all:         $(LIB)便是终于目标,依据依赖关系。便能完毕子文件夹的编译。

5.生成S5PV210可启动的smart210-uboot.bin程序

前面生成的u-boot.bin还不能直接在S5PV210了上执行,由于其没有加上S5PV210所要求的特定的校验格式。

S5PV210在启动的时候会自己主动从所选择的启动方式相应的设备中读取其前16kb的内容到内存中,S5PV210要求前面的16字节存放校验和之类的信息,详细内容请參阅S5PV210的datasheet。

在顶层主Makefile的终于目标中有一个目标spl/u-boot-spl.bin,spl也就是第二阶段程序载入程序(Secondary Program Loader),S5PV210内置的ROM中固化的代码是第一阶段载入程序。载入前24Kb(也就是第二阶段程序载入城程序u-boot-spl.bin)到内存中,并跳转到当中执行;而第二阶段载入程序则将完整的u-boot.bin载入到内存中,然后跳转到u-boot.bin中执行。这个时候。uboot就算是启动起来了。

在顶层主Makefile中,目标spl/u-boot-spl.bin的规则是:

$(obj)spl/u-boot-spl.bin:           depend

$(MAKE)-C spl all

可见,make会载入spl文件夹下的Makefile进行编译。接下来便看看这个子Makefile的工作方式。

因为硬件的限制。u-boot-spl.bin必须不超过(24*1024-16)字节。所以编译时仅仅须要一些载入完整uboot所须要的模块,其它统统不编译进来。

其它的方面,与Makefile的做法差点儿一样。这里不再赘述,而值得一的是smart210-uboot.bin的终于生成。

在u-boot-spl.bin生成后。例如以下的规则便执行了:

ifdef CONFIG_SAMSUNG

$(obj)$(BOARD)-spl.bin:$(obj)u-boot-spl.bin

$(TOPDIR)/board/$(BOARDDIR)/tools/mk$(BOARD)spl.exe\

$(obj)u-boot-spl.bin$(obj)$(BOARD)-spl.bin

cat$(obj)$(BOARD)-spl.bin $(TOPDIR)/u-boot.bin > $(TOPDIR)/$(BOARD)-uboot.bin

endif

mk$(BOARD)spl.exe是在board/Samsung/smart210/tools/中已经被编译好了的工具。就是用来给第二阶段程序载入程序加入S5PV210所要求的头部信息的,加入了头部信息的u-boot-spl.bin就能够被载入并运行了,加了头部信息的u-boot-spl.bin命名为smart210-spl.bin。cat $(obj)$(BOARD)-spl.bin $(TOPDIR)/u-boot.bin >$(TOPDIR)/$(BOARD)-uboot.bin语句将第二阶段程序载入程序smart210-spl.bin和完整的u-boot.bin打包成为一个总体,生成的可运行文件为smart210-uboot.bin,那么smart210-uboot.bin完成后,将能烧成完整的uboot开端。

版权声明:本文博主原创文章。博客,未经同意不得转载。

tiny210——uboot移植Makefile文章分析的更多相关文章

  1. uboot 顶层makefile细节分析

    uboot的源文件众多,学习庞然大物首先找到脊椎--顶层的makfile,逐一破解.但是,uboot的makefile同样是一个庞然大物,所以也要找到它的主线.倘若过分专注部分细节,很难做到把握全局, ...

  2. 第二章、Tiny4412 U-BOOT移植二 启动分析【转】

    本文转载自:http://blog.csdn.net/eshing/article/details/37521481 版权声明:本文为博主原创文章,未经博主允许不得转载. 一.启动过程说明 讲解启动过 ...

  3. [学习资料] Tiny210(S5PV210) u-boot移植

    Tiny210(S5PV210) u-boot移植http://www.microoh.com/bbs/forum.php?mod=viewthread&tid=254&fromuid ...

  4. u-boot移植总结(四)u-boot-2010.09框架分析

    (一)本次移植是基于FL2440,板子的基本硬件: CPU 型号为S3C2440,基于ARM920T,指令集ARMV4,时钟主频400MHz SDRAM H57V2562GTR-75C 2片*32MB ...

  5. uboot主Makefile分析(t配置和编译过程详解)

    1.编译uboot前需要三次make make distcleanmake x210_sd_configmake -j4 make distclean为清楚dist文件. make x210_sd_c ...

  6. uboot makefile构建分析

    前言 几年前分析过uboot的构建及启动过程,做了笔记,但最终没有转为文章.这次又有机会开发嵌入式产品了(之前一年多都是在搞x86 linux),看了下uboot的构建过程,觉得有必要写下整个分析过程 ...

  7. uboot主Makefile分析

    VERSION = 1 PATCHLEVEL = 3 SUBLEVEL = 4 EXTRAVERSION = U_BOOT_VERSION = $(VERSION).$(PATCHLEVEL).$(S ...

  8. 第四章、TIny4412 U-BOOT移植四 配置时钟频率源码分析【转】

    本文转载自:http://blog.csdn.net/eshing/article/details/37542459 版权声明:本文为博主原创文章,未经博主允许不得转载.   目录(?)[+]   上 ...

  9. uboot makefile构建分析-续

    前言 这篇博文是 uboot makefile构建分析的续篇,继续分析uboot构建u-boot.bin的过程 构建u-boot.bin过程分析 makefile一开始,就是确定链接脚本.在构建ubo ...

随机推荐

  1. CF(427D-Match &amp; Catch)后缀数组应用

    题意:给两个字符串,求一个最短的子串.使得这个子串在两个字符串中出现的次数都等于1.出现的定义为:能够重叠的出现. 解法:后缀数组的应用.从小枚举长度.假设一个长度len合法的话:则一定存在这个样的s ...

  2. JAVA 公众微信的开放源码项目管理合作伙伴招募的版本号

    大家好:       jeecg开源社区.现在正在进行"JAVA 开放源码的版本号项目微信公共账号"工作,有兴趣的朋友一起參与. 截止时间:20140510 採用技术: 1. JE ...

  3. C# DataTable详细用法

    通过经常使用的项目中的DataTable,假设DataTable使用得当,不仅能使程序简洁有用,并且可以提高性能,达到事半功倍的效果,现对DataTable的使用技巧进行一下总结. 一.DataTab ...

  4. Visual Studio中开发

    如何在Visual Studio中开发自己的代码生成器插件    Visual Studio是美国微软公司开发的一个基本完整的开发工具集,它包括了整个软件生命周期中所需要的大部分工具,如UML工具.代 ...

  5. JProgressBar的一个框架

    Frame: package swing.progress; import java.awt.BorderLayout; import java.awt.Frame; import java.awt. ...

  6. MCC460MNC08

    因为搜得辛苦,正好也写点关于我morto工作有关的事情,给大家和我一样扫盲,哈哈   The GSM Mobile Country Code (MCC) is different from the i ...

  7. 复制(6)——分发者(Distributor)

    如简介中提到,分发者(Distributor)是SQLServer 复制过程的核心组件.因为它是控制和执行实际的数据移动的过程,并且存放了发布(Publications)和订阅(Subscriptio ...

  8. 【Leetcode】Partition List (Swap)

    Given a linked list and a value x, partition it such that all nodes less than x come before nodes gr ...

  9. PreparedStatement批量处理的一个Framework(原创)

    场景:批量进行DML操作,但涉及的表不同,不能使用executeBatch() 需求:(1)如果DML中有一个错误时,要全部回滚:(2)如果全部正确,要全部执行: 解决方案: package jdbc ...

  10. Tri_integral Summer Training 5 总结

    比赛 题目 B D E G H I J 这是泰国的一场区域赛,除了C题英语非常抽以外,其余题目还不算难读. 一开场就发现了三道很水的题目,0:21:34就把三道题给过了,都是1A,赞Moor的手速. ...