目录
一、S5PV210官方uboot配置编译实践
1、找到官方(SOC/开发板厂商)移植好的uboot
(1)源头的源代码是uboot官网下载的。这个下载的源代码可能没有你当前使用的开发板的移植，甚至找不到当前开发板使用的SoC对应的移植版本。
(2)SoC厂商在推出一款SoC后，厂商的工程师会去uboot官网下载一个uboot，根据自己的SoC进行第一步的移植，移植的目标是厂商推出的开发板。（譬如三星的S5PV210芯片厂商出的开发板就叫SMDKV210）.所以三星的工程师移植的uboot是根据他们自己的SMDKV210开发板移植的。
(3)具体的开发板供应商（譬如X210的生产商深圳市九鼎科技）首先购买三星的SMDKV210开发板，然后进行裁剪（把一些无用的接口功能裁剪去，配置降低一下，某些配置会被替换）。硬件替换和裁剪之后生成的新的开发板（譬如X210）和三星官方的SMDKV210有所不同，因此uboot也不同。但是因为SoC是相同的，所以相似度至少有60%以上。所以具体开发板供应商会以三星SMDKV210中移植的uboot为蓝本来移植得到自己的开发板的一个uboot移植
总结：uboot可以有3种获取途径：uboot官方、SoC官方、具体开发板的官方。
2、在ubuntu下配置编译
(1)BSP就是board support package(板级支持包，一般由开发板供应商提供)，里面的内容就是这个开发板的所有相关的源代码、文档、教程等。
(2)将整个BSP打包文件弄到linux的源生目录中去解压分析，不要在windows中的共享文件夹中解压开。（除非你的代码只在windows下去分析而不去编译，如果你想编译工程就一定不要在windows共享文件夹下，否则会出错）
(3)tar -jxvf qt_x210v3_130807.tar.bz2
(4)我们在linux(ubuntu)下维持一份uboot，在windows下也维持一份uboot，在我们没有开始任何工作之前，这两份uboot内容一样的。我们这样做目的是：在linux中进行编译、在windwos下进行代码分析和观看。（windwos下有SourceInsight等很好的工具辅助我们看代码、编辑代码，在linux下编译和看代码都很麻烦·····）
(5)配置
(1)uboot和linux kernel等复杂项目，都不能直接编译，都要先配置才能编译。
(2)uboot也要先配置，配置方法是(以我的开发板为例)：首先cd进入uboot源码的根目录，
然后在根目录下执行：make x210_sd_config。执行配置命令后，如果出现：Configuring
for x210_sd board...说明配置好了，如果不是这个是别的说明配置出错了
(6)编译得到uboot.bin
(1)编译之前一定要注意检查arm-linux-gcc对不对，检查份2步：
第一步：检查当前编译环境中有没有安装合适的arm-linux-gcc。我装的是arm-2009q3，
因为这个是三星官方、开发板厂商官方开发uboot时使用的。
第二步：检查当前目录下（uboot根目录）的Makefile中编译器的设置是否正确。在工
程的总Makefile中会设置交叉编译工具链的路径和名字，必须确保这个路径和名字和我们自
己装的一致，否则编译会出错。
(2)确保了以上2点，即可进行编译。编译很简单，直接make即可。或者可以make -j4 (多线
程编译，主机如果是多核心电脑，可以尝试多线程编译，会快一些)
二、uboot的源码目录分析
1、开发板厂商提供的uboot和三星原版uboot对比
(1)以开发板厂商提供的uboot为蓝本来学习的，以三星官方的这份为对照。
(2)不同版本的uboot或者同一版本不同人移植的uboot，可能目录结构和文件内容都有所不同。将来大家懂了后也可以自己根据需要去添加/删除/更改目录结构。
(3)开发板厂商在以三星的uboot为原材料进行移植时，可能把三星版本的uboot中很多不必要的文件夹、文件给删除掉了。这个删除把很多完全用不到的文件清除出去，减少了整体的文件数量，便于工作。
2、各文件介绍(以开发板厂商九鼎科技的uboot为例)
(1).gitignore，git工具的文件，git是一个版本管理工具（类似的还有个svn），这个文件
和git有关，和uboot本身无关的，不用去管。
(2)arm_config.mk，后缀是.mk，是一个Makefile文件，将来在某个Makefile中会去调用它。
(3)三个Changelog文件，修改记录文件，该文件记录了这个uboot项目的版本变迁以及每个
版本较上个版本修改的记录。正式的项目都有这些记录的。可以直接忽略，主要是给维护
uboot的人用的。
(4)config.mk，和arm_config.mk差不多性质。
(5)COPYING，版权声明，uboot本身是GPL许可证的。
(6)CREDITS，鸣谢，里面记录了对uboot有贡献的人，感谢目录。
(7)image_split，一个脚本，用来分割uboot.bin到BL1的。
(8)MAINTAINERS，维护者，就是当前在参与维护uboot源码的社区工作者。
(9)MAKEALL，一个脚本，应该是帮助编译uboot的。
(10)Makefile，这个很重要，是uboot源代码的主Makefile，将来整个uboot被编译时就是
用这个Makefile管理编译的。
(11)mk，快速编译的脚本，其实就是先清理然后配置然后编译而已。
(12)mkconfig，这个很重要，是uboot配置阶段的主要配置脚本。uboot的可移植性很大程度
就是靠这个配置脚本在维护的。
(13)mkmovi，一个脚本，和iNand/SD卡启动有关
(14)README，所有的软件都有README，一般拿到一个东西要先读README，这个东西其实就
是个简单的使用说明书。
(15)rules.mk，这个文件是我们uboot的Makefile使用的规则，本身非常重要，但是我们
不去分析他，不去看他。
总结：以上这些文件中，对我们比较重要，需要认真看的有2个：mkconfig和Makefile。一个负责uboot的配置，一个负责编译。
3、各文件夹介绍
(1)api，硬件无关的功能函数的API。uboot移植时基本不用管，这些函数是uboot本身使用
的。
(2)api_examples，API相关的测试事例代码。
(3)board，board是板的意思，板就是开发板。board文件夹下每一个文件都代表一个开发板，这个文件夹下面放的文件就是用来描述这一个开发板的信息的。board目录下有多少个文件夹，
就表示当前这个uboot已经被移植到多少个开发板上了（当前的uboot支持多少个开发板）。
问题一：board下有这么多文件夹，究竟如何确定具体使用的是哪一个？
uboot在配置阶段会有一些手段帮助我们来确定具体使用的是board目录下的哪一个文件夹。（想想为什么不能直接编译而要先配置）
问题二：开发板越来越多，board目录下文件夹越来越多不方便管控，如何解决
于是乎uboot就新增了一种机制，可以在board目录下不直接放开发板目录，而是在board下放厂家目录（vendor目录，以具体芯片厂商名字命名），然后将这个IC厂商的所有芯片开发板都丢到这个vendor目录下面去。
X210对应的开发板目录在board/samsung/x210。多了这层目录会影响配置阶段，在uboot的配置阶段要注意配置时的路径深度和实际存放要对应，不然配置后编译时找不到文件，编译就会失败。注意一个细节就是历史原因造成的兼容性麻烦。最开始时board目录下就是开发板名字，后来才改成厂商名字的。但是因为要向前兼容，同一个厂商原来还是外面的开发板并没有挪移到厂商目录下面去。这样就造成后来的人不知道原委的感到很奇怪，感觉很混乱。
注意：强调一下，uboot的配置阶段（其实就是根目录下面的mkconfig脚本和Makefile中配置有关的部分）主要解决的问题就是在可移植性领域能够帮助我们确定具体的文件夹的路径，然后编译时可以找到应该找到的文件，才能编译成功。因此board目录下的不同会造成配置时的不同。如果移植时没注意这里肯定要失败。
(4)common。common是普遍的普通的，这个文件夹下放的是一些与具体硬件无关的普遍适用的一些代码。譬如控制台实现、crc校验的。但是更多的主要是两类：一类是cmd开头的，是用来实现uboot的命令系统的；另一类是env开头的，是用来实现环境变量的。
(5)cpu。这个目录是SoC相关的，里面存放的代码都是SoC相关初始化和控制代码（譬如CPU的、中断的、串口等SoC内部外设的，包括起始代码start.S也在这里）。里面很多子文件夹，每一个子文件夹就是一个SoC系列。
注意：这个问价是严格和硬件相关的，因此移植时也是要注意的。但是因为这个文件夹内都是SoC有关的，我们自己的开发板和三星的开发板虽然板子设计不同但是SoC都是同一个，因此实际移植时这个目录几乎不用动。
(6)disk。磁盘有关的，没研究过，没用过。
(7)doc。文档目录，里面存放了很多uboot相关文档，这些文档可以帮助我们理解uboot代码。但是因为是纯英文的，而且很杂乱，所以几乎没用。
(8)drivers。顾名思义，驱动。这里面放的就是从linux源代码中扣出来的原封不动的linux设备驱动，主要是开发板上必须用到的一些驱动，如网卡驱动、Inand/SD卡、NandFlash等的驱动。要知道：uboot中的驱动其实就是linux中的驱动，uboot在一定程度上移植了linux的驱动给自己用。但是linux是操作系统而uboot只是个裸机程序，因此这种移植会有不同，让我说：uboot中的驱动其实是linux中的驱动的一部分。
(9)examples。示例代码，没用过。
(10)fs。filesystem，文件系统。这个也是从linux源代码中移植过来的，用来管理Flash等资源。
(11)include。头文件目录。uboot和linux kernel在管理头文件时都采用了同一个思路，就是把所有的头文件全部集中存放在include目录下，而不是头文件跟着自己对应的c文件。所以在uboot中头文件包含时路径结构要在这里去找。
(12)lib_开头的一坨。（典型的lib_arm和lib_generic）架构相关的库文件。譬如lib_arm里面就是arm架构使用的一些库文件。lib_generic里是所有架构通用的库文件。这类文件夹中的内容移植时基本不用管。
(13)libfdt。设备树有关的。linux内核在3.4左右的版本的时候更改了启动传参的机制，改用设备树来进行启动传参，进行硬件信息的描述了。
(14)nand_spl。nand相关的，不讲。
(15)net。网络相关的代码，譬如uboot中的tftp nfs ping命令 都是在这里实现的。
(16)onenand开头的，是onenand相关的代码，是三星加的，标准uboot中应该是没有的。
(17)post。没关注过，不知道干嘛的。
(18)sd_fusing。这里面代码实现了烧录uboot镜像到SD卡的代码。后面要仔细研究的。
(19)tools。里面是一些工具类的代码。譬如mkimage。
总结：文件夹里面比较重要的，后面会分析涉及到的有：board、common、cpu、drivers、include、lib_arm、lib_generic、sd_fusing
三、uboot主Makefile分析
分析Makefile比较大，故将链接放在这，务必下载后结合博客文章学习分析：
「Makefile」https://www.aliyundrive.com/s/fkNHpf17Ut8
点击链接保存，或者复制本段内容，打开「阿里云盘」APP ，无需下载极速在线查看，
视频原画倍速播放。
1、uboot version确定（Makefile的24-29行）
(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打印出来的版本信息，看看变化是不是和自己的分析一致。
VERSION = 1
PATCHLEVEL = 3
SUBLEVEL = 4
EXTRAVERSION =
U_BOOT_VERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
VERSION_FILE = $(obj)include/version_autogenerated.h
HOSTARCH := $(shell uname -m | \
sed -e s/i.86/i386/ \
-e s/sun4u/sparc64/ \
-e s/arm.*/arm/ \
-e s/sa110/arm/ \
-e s/powerpc/ppc/ \
-e s/ppc64/ppc/ \
-e s/macppc/ppc/)
HOSTOS := $(shell uname -s | tr '[:upper:]' '[:lower:]' | \
sed -e 's/\(cygwin\).*/cygwin/')
export HOSTARCH HOSTOS
# Deal with colliding definitions from tcsh etc.
VENDOR=
#########################################################################
# Allow for silent builds
ifeq (,$(findstring s,$(MAKEFLAGS)))
XECHO = echo
else
XECHO = :
endif
2、HOSTARCH和HOSTOS
(1)直接在ubuntu命令行(shell)中执行uname -m得到i686，得到的值其实你当前执行这个命令的电脑的CPU的版本号。
(2)shell中的“ | ”叫做管道，管道的作用就是把管道前面一个运算式的输出作为后面一个的输入再去做处理，最终的输出才是我们整个式子的输出。
(3)HOSTARCH这个名字：HOST是主机，就是当前在做开发用的这台电脑就叫主机；ARCH是architecture(架构)的缩写，表示CPU的架构。所以HOSTARCH就表示主机的CPU的架构。
(4)这两个环境变量是主机的操作系统和主机的CPU架构，得出后保存备用，后面自然会用到。
3、静默编译（50-54行）
(1)平时默认编译时命令行会打印出来很多编译信息。但是有时候我们不希望看到这些编译信息，就后台编译即可。这就叫静默编译。
(2)使用方法就是编译时make -s，-s会作为MAKEFLAGS传给Makefile，在50-54行这段代码作用下XECHO变量就会被变成空（默认等于echo），于是实现了静默编译。
4、2种编译方法（原地编译和单独输出文件夹编译）
(1)编译复杂项目，Makefile提供2种编译管理方法。默认情况下是当前文件夹中的.c文件，编译出来的.o文件会放在同一文件夹下。这种方式叫原地编译。原地编译的好处就是处理起来简单。
(2)原地编译有一些坏处：第一，污染了源文件目录。第二的缺陷就是一套源代码只能按照一种配置和编译方法进行处理，无法同时维护2个或2个以上的配置编译方式。
(3)为了解决以上2种缺陷，uboot支持单独输出文件夹方式的编译（linux kernel也支持，而且uboot的这种技术就是从linux kernel学习来的）。基本思路就是在编译时另外指定一个输出目录，将来所有的编译生成的.o文件或生成的其他文件全部丢到那个输出目录下去。源代码目录不做任何污染，这样输出目录就承载了本次配置编译的所有结果。
(4)具体用法：默认的就是原地编译。如果需要指定具体的输出目录编译则有2种方式来指定输出目录。（具体参考Makefile 56-76行注释内容）
#########################################################################
#
# U-boot build supports producing a object files to the separate external
# directory. Two use cases are supported:
#
# 1) Add O= to the make command line
# 'make O=/tmp/build all'
#
# 2) Set environement variable BUILD_DIR to point to the desired location
# 'export BUILD_DIR=/tmp/build'
# 'make'
#
# The second approach can also be used with a MAKEALL script
# 'export BUILD_DIR=/tmp/build'
# './MAKEALL'
#
# Command line 'O=' setting overrides BUILD_DIR environent variable.
#
# When none of the above methods is used the local build is performed and
# the object files are placed in the source directory.
#
第一种：make O=输出目录
第二种：export BUILD_DIR=输出目录 然后再make
如果两个都指定了（既有BUILD_DIR环境变量存在，又有O=xx），则O=xx具有更高优先级，
听他的。
(5)两种编译的实现代码在Makefile的78-123行。
ifdef O
ifeq ("$(origin O)", "command line")
BUILD_DIR := $(O)
endif
endif
ifneq ($(BUILD_DIR),)
saved-output := $(BUILD_DIR)
# Attempt to create a output directory.
$(shell [ -d ${
BUILD_DIR} ] || mkdir -p ${
BUILD_DIR})
# Verify if it was successful.
BUILD_DIR := $(shell cd $(BUILD_DIR) && /bin/pwd)
$(if $(BUILD_DIR),,$(error output directory "$(saved-output)" does not exist))
endif # ifneq ($(BUILD_DIR),)
OBJTREE := $(if $(BUILD_DIR),$(BUILD_DIR),$(CURDIR))
SRCTREE := $(CURDIR)
TOPDIR := $(SRCTREE)
LNDIR := $(OBJTREE)
export TOPDIR SRCTREE OBJTREE
MKCONFIG := $(SRCTREE)/mkconfig
export MKCONFIG
ifneq ($(OBJTREE),$(SRCTREE))
REMOTE_BUILD := 1
export REMOTE_BUILD
endif
# $(obj) and (src) are defined in config.mk but here in main Makefile
# we also need them before config.mk is included which is the case for
# some targets like unconfig, clean, clobber, distclean, etc.
ifneq ($(OBJTREE),$(SRCTREE))
obj := $(OBJTREE)/
src := $(SRCTREE)/
else
obj :=
src :=
endif
export obj src
# Make sure CDPATH settings don't interfere
unexport CDPATH
5、OBJTREE、SRCTREE、TOPDIR、MKCONFIG
(1)OBJTREE：编译出的.o文件存放的目录的根目录。在默认编译下，OBJTREE等于当前目录；在make O=xx编译下，OBJTREE就等于我们设置的那个输出目录。
(2)SRCTREE: 源码目录，其实就是源代码的根目录，也就是当前目录。
总结：在默认编译下，OBJTREE和SRCTREE相等；在O=xx这种编译下OBJTREE和SRCTREE不相等。Makefile中定义这两个变量，其实就是为了记录编译后的.o文件往哪里放，就是为了实现O=xx的这种编译方式的。
(3)Makefile中定义的一个变量（在这里定义，在后面使用），它的值就是我们源码根目录下面的mkconfig。这个mkconfig是一个脚本，这个脚本就是uboot配置阶段的配置脚本。
OBJTREE := $(if $(BUILD_DIR),$(BUILD_DIR),$(CURDIR))
SRCTREE := $(CURDIR)
TOPDIR := $(SRCTREE)
LNDIR := $(OBJTREE)
export TOPDIR SRCTREE OBJTREE
MKCONFIG := $(SRCTREE)/mkconfig
export MKCONFIG
6、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个值是可以被人很容易的、集中的配置的。
# load ARCH, BOARD, and CPU configuration
include $(obj)include/config.mk #配置过程生成的
export ARCH CPU BOARD VENDOR SOC
(4)这里的配置值来自于Makefile 2589行那里的配置项。如果我们要更改这里的某个配置值要到2589行那里调用MKCONFIG脚本传参时的参数。
x210_sd_config : unconfig
@$(MKCONFIG) $(@:_config=) arm s5pc11x x210 samsung s5pc110
@echo "TEXT_BASE = 0xc3e00000" > $(obj)board/samsung/x210/config.mk
7、ARCH、CROSS_COMPILE
ifndef CROSS_COMPILE
ifeq ($(HOSTARCH),$(ARCH))
CROSS_COMPILE =
else
ifeq ($(ARCH),ppc)
CROSS_COMPILE = ppc_8xx-
endif
ifeq ($(ARCH),arm)
#CROSS_COMPILE = arm-linux-
#CROSS_COMPILE = /usr/local/arm/4.4.1-eabi-cortex-a8/usr/bin/arm-linux-
#CROSS_COMPILE = /usr/local/arm/4.2.2-eabi/usr/bin/arm-linux-
CROSS_COMPILE = /usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-
endif
ifeq ($(ARCH),i386)
CROSS_COMPILE = i386-linux-
endif
ifeq ($(ARCH),mips)
CROSS_COMPILE = mips_4KC-
endif
ifeq ($(ARCH),nios)
CROSS_COMPILE = nios-elf-
endif
ifeq ($(ARCH),nios2)
CROSS_COMPILE = nios2-elf-
endif
ifeq ($(ARCH),m68k)
CROSS_COMPILE = m68k-elf-
endif
ifeq ($(ARCH),microblaze)
CROSS_COMPILE = mb-
endif
ifeq ($(ARCH),blackfin)
CROSS_COMPILE = bfin-uclinux-
endif
ifeq ($(ARCH),avr32)
CROSS_COMPILE = avr32-linux-
endif
ifeq ($(ARCH),sh)
CROSS_COMPILE = sh4-linux-
endif
ifeq ($(ARCH),sparc)
CROSS_COMPILE = sparc-elf-
endif # sparc
endif # HOSTARCH,ARCH
endif # CROSS_COMPILE
export 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里面的设置。
8、$(TOPDIR)/config.mk（主Makefile的185行）
(1)编译工具定义（config.mk 94-107行）
#
# Include the make variables (CC, etc...)
#
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
CC = $(CROSS_COMPILE)gcc
CPP = $(CC) -E
AR = $(CROSS_COMPILE)ar
NM = $(CROSS_COMPILE)nm
LDR = $(CROSS_COMPILE)ldr
STRIP = $(CROSS_COMPILE)strip
OBJCOPY = $(CROSS_COMPILE)objcopy
OBJDUMP = $(CROSS_COMPILE)objdump
RANLIB = $(CROSS_COMPILE)RANLIB
#########################################################################
# Load generated board configuration
sinclude $(OBJTREE)/include/autoconf.mk
(2)包含开发板配置项目（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的关键所在。
(3)链接脚本（config.mk 142-149行）
ifndef LDSCRIPT
#LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds.debug
ifeq ($(CONFIG_NAND_U_BOOT),y)
LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds
else
LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds
endif
endif
(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的编译链接过程时就要考虑这个链接脚本。
(4)TEXT_BASE（config.mk 156-158行）
ifneq ($(TEXT_BASE),)
CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE)
endif
(1)Makefile中在配置X210开发板时，在board/samsung/x210目录下生成了一个文件
config.mk，其中的内容就是：TEXT_BASE = 0xc3e00000相当于定义了一个变量。
(2)TEXT_BASE是将来我们整个uboot链接时指定的链接地址。因为uboot中启用了虚拟地址
映射，因此这个C3E00000地址就等于0x23E00000(也可能是33E00000具体地址要取决于
uboot中做的虚拟地址映射关系)。
(5)自动推导规则（config.mk 239-256行）
#########################################################################
ifndef REMOTE_BUILD
%.s: %.S
$(CPP) $(AFLAGS) -o $@ $<
%.o: %.S
$(CC) $(AFLAGS) -c -o $@ $<
%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $<
else
$(obj)%.s: %.S
$(CPP) $(AFLAGS) -o $@ $<
$(obj)%.o: %.S
$(CC) $(AFLAGS) -c -o $@ $<
$(obj)%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $<
endif
#########################################################################
9、目标all
all: $(ALL)
$(obj)u-boot.hex: $(obj)u-boot
$(OBJCOPY) ${
OBJCFLAGS} -O ihex $< $@
$(obj)u-boot.srec: $(obj)u-boot
$(OBJCOPY) ${
OBJCFLAGS} -O srec $< $@
$(obj)u-boot.bin: $(obj)u-boot
$(OBJCOPY) ${
OBJCFLAGS} -O binary $< $@
$(obj)u-boot.ldr: $(obj)u-boot
$(LDR) -T $(CONFIG_BFIN_CPU) -f -c $@ $< $(LDR_FLAGS)
$(obj)u-boot.ldr.hex: $(obj)u-boot.ldr
$(OBJCOPY) ${
OBJCFLAGS} -O ihex $< $@ -I binary
$(obj)u-boot.ldr.srec: $(obj)u-boot.ldr
$(OBJCOPY) ${
OBJCFLAGS} -O srec $< $@ -I binary
$(obj)u-boot.img: $(obj)u-boot.bin
./tools/mkimage -A $(ARCH) -T firmware -C none \
-a $(TEXT_BASE) -e 0 \
-n $(shell sed -n -e 's/.*U_BOOT_VERSION//p' $(VERSION_FILE) | \
sed -e 's/"[ ]*$$/ for $(BOARD) board"/') \
-d $< $@
$(obj)u-boot.sha1: $(obj)u-boot.bin
$(obj)tools/ubsha1 $(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $< > $@
$(obj)u-boot: depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT)
UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \
sed -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot. Map -o u-boot
(1)291行出现了整个主Makefile中第一个目标all（也就是默认目标，我们直接在uboot根目录下make其实就等于make all，就等于make这个目标）
(2)目标中有一些比较重要的。譬如：u-boot是最终编译链接生成的elf格式的可执行文件，
(3)unconfig字面意思来理解就是未配置(主Makefile 473行)。这个符号用来做为我们各个开发板配置目标的依赖。目标是当我们已经配置过一个开发板后再次去配置时还可以配置。
unconfig:
@rm -f $(obj)include/config.h $(obj)include/config.mk \
$(obj)board/*/config.tmp $(obj)board/*/*/config.tmp \
$(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep \
$(obj)board/$(VENDOR)/$(BOARD)/config.mk
(4)我配置开发板时使用：make x210_sd_config，因此分析x210_sd_config肯定是主Makefile中的一个目标(2589行)。
x210_sd_config : unconfig
@$(MKCONFIG) $(@:_config=) arm s5pc11x x210 samsung s5pc110
@echo "TEXT_BASE = 0xc3e00000" > $(obj)board/samsung/x210/config.mk
四、uboot配置过程详解：mkconfig
#!/bin/sh -e
# Script to create header files and links to configure
# U-Boot for a specific board.
#
# Parameters: Target Architecture CPU Board [VENDOR] [SOC]
#
# (C) 2002-2006 DENX Software Engineering, Wolfgang Denk <[email protected]>
#
APPEND=no # Default: Create new config file
BOARD_NAME="" # Name to print in make output
while [ $# -gt 0 ] ; do
case "$1" in
--) shift ; break ;;
-a) shift ; APPEND=yes ;;
-n) shift ; BOARD_NAME="${1%%_config}" ; shift ;;
*) break ;;
esac
done
[ "${BOARD_NAME}" ] || BOARD_NAME="$1"
[ $# -lt 4 ] && exit 1
[ $# -gt 6 ] && exit 1
echo "Configuring for ${BOARD_NAME} board..."
#
# Create link to architecture specific headers
#
if [ "$SRCTREE" != "$OBJTREE" ] ; then
mkdir -p ${
OBJTREE}/include
mkdir -p ${
OBJTREE}/include2
cd ${
OBJTREE}/include2
rm -f asm
ln -s ${
SRCTREE}/include/asm-$2 asm
LNPREFIX="../../include2/asm/"
cd ../include
rm -rf asm-$2
rm -f asm
mkdir asm-$2
ln -s asm-$2 asm
else
cd ./include
rm -f asm
ln -s asm-$2 asm
fi
rm -f asm-$2/arch
if [ -z "$6" -o "$6" = "NULL" ] ; then
ln -s ${
LNPREFIX}arch-$3 asm-$2/arch
else
ln -s ${
LNPREFIX}arch-$6 asm-$2/arch
fi
# create link for s3c24xx SoC
if [ "$3" = "s3c24xx" ] ; then
rm -f regs.h
ln -s $6.h regs.h
rm -f asm-$2/arch
ln -s arch-$3 asm-$2/arch
fi
# create link for s3c64xx SoC
if [ "$3" = "s3c64xx" ] ; then
rm -f regs.h
ln -s $6.h regs.h
rm -f asm-$2/arch
ln -s arch-$3 asm-$2/arch
fi
# create link for s5pc1xx SoC
if [ "$3" = "s5pc1xx" ] ; then
rm -f regs.h
ln -s $6.h regs.h
rm -f asm-$2/arch
ln -s arch-$3 asm-$2/arch
fi
# create link for s5pc11x SoC
if [ "$3" = "s5pc11x" ] ; then
rm -f regs.h
ln -s $6.h regs.h
rm -f asm-$2/arch
ln -s arch-$3 asm-$2/arch
fi
# create link for s5p64xx SoC
if [ "$3" = "s5p64xx" ] ; then
rm -f regs.h
ln -s $6.h regs.h
rm -f asm-$2/arch
ln -s arch-$3 asm-$2/arch
fi
# create link for s5p644x SoC
if [ "$3" = "s5p644x" ] ; then
rm -f regs.h
ln -s $6.h regs.h
rm -f asm-$2/arch
ln -s arch-$3 asm-$2/arch
fi
if [ "$2" = "arm" ] ; then
rm -f asm-$2/proc
ln -s ${
LNPREFIX}proc-armv asm-$2/proc
fi
# create link for s3c64xx-mp SoC
if [ "$3" = "s3c64xx-mp" ] ; then
rm -f regs.h
ln -s $6.h regs.h
rm -f asm-$2/arch
ln -s arch-$3 asm-$2/arch
fi
#
# Create include file for Make
#
echo "ARCH = $2" > config.mk
echo "CPU = $3" >> config.mk
echo "BOARD = $4" >> config.mk
[ "$5" ] && [ "$5" != "NULL" ] && echo "VENDOR = $5" >> config.mk
[ "$6" ] && [ "$6" != "NULL" ] && echo "SOC = $6" >> config.mk
#
# Create board specific header file
#
if [ "$APPEND" = "yes" ] # Append to existing config file
then
echo >> config.h
else
> config.h # Create new config file
fi
echo "/* Automatically generated - do not edit */" >>config.h
echo "#include <configs/$1.h>" >>config.h
exit 0
(1)mkconfig脚本的6个参数
$(@:_config=) arm s5pc11x x210 samsung s5pc110（Makefile 2593-2595行）
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（56行）
第三个：在include目录下创建regs.h文件，指向include/s5pc110.h
删除第二个。（84-87行）
第四个：在inlcude/asm-arm下创建一个arch文件，指向include/asm-arm/arch-s5pc11x（88行）
第五个：在include/asm-arm下创建一个proc文件，指向include/asm-arm/proc-armv（107-109行）
总结：一共创建了4个符号链接。这4个符号链接将来在写代码过程中，头文件包含时非常有用。譬如一个头文件包含可能是：#include <asm/xx.h>
(7)创建include/config.mk文件（mkconfig文件123-129行）,创建include/config.mk文件是为了让主Makefile在第133行去包含的。理解这些脚本时，时刻要注意自己当前所处的路径。
创建（默认情况）/追加（make -a时追加）include/config.h文件（mkconfig文件的134-141行）。
这个文件里面的内容就一行#include <configs/x210_sd.h>，这个头文件是我们移植x210开发板时，对开发板的宏定义配置文件。这个文件是我们移植x210时最主要的文件。
x210_sd.h文件会被用来生成一个autoconfig.mk文件，这个文件会被主Makefile引入，指导整个编译过程。这里面的这些宏定义会影响我们对uboot中大部分.c文件中一些条件编译的选择。从而实现最终的可移植性。
注意：uboot的整个配置过程，很多文件之间是有关联的（有时候这个文件是在那个文件中创建出来的；有时候这个文件被那个文件包含进去；有时候这个文件是由那个文件的内容生成的决定的）
注意：uboot中配置和编译过程，所有的文件或者全局变量都是字符串形式的（不是指的C语言字符串的概念，指的是都是字符组成的序列）。这意味着我们整个uboot的配置过程都是字符串匹配的，所以一定要细节，注意大小写，要注意不要输错字符，因为一旦错一个最后会出现一些莫名其妙的错误，很难排查，这个是uboot移植过程中新手来说最难的地方。
五、uboot的链接脚本u-boot.lds
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
/*OUTPUT_FORMAT("elf32-arm", "elf32-arm", "elf32-arm")*/
OUTPUT_ARCH(arm)// 输出的架构是ARM
ENTRY(_start) //指定整个程序的入口地址
SECTIONS
{
. = 0x00000000;
. = ALIGN(4);/*指示编译器将接下来的代码进行4字节对齐编译*/
.text :/*也就是在分配地址时，以4的整数倍分配*/
{
cpu/s5pc11x/start.o (.text)
cpu/s5pc11x/s5pc110/cpu_init.o (.text)
board/samsung/x210/lowlevel_init.o (.text)
cpu/s5pc11x/onenand_cp.o (.text)
cpu/s5pc11x/nand_cp.o (.text)
cpu/s5pc11x/movi.o (.text)
common/secure_boot.o (.text)
common/ace_sha1.o (.text)
cpu/s5pc11x/pmic.o (.text)
*(.text)
}
. = ALIGN(4);
.rodata : {
*(.rodata) }
. = ALIGN(4);
.data : {
*(.data) }
. = ALIGN(4);
.got : {
*(.got) }
__u_boot_cmd_start = .;//自定义的段，起始地址
.u_boot_cmd : {
*(.u_boot_cmd) }
__u_boot_cmd_end = .;//结束地址
. = ALIGN(4);
.mmudata : {
*(.mmudata) }
. = ALIGN(4);
__bss_start = .;
.bss : {
*(.bss) }
_end = .;
}
(1)ENTRY(_start)用来指定整个程序的入口地址。所谓入口地址就是整个程序的开头地址，可以认为就是整个程序的第一句指令。有点像C语言中的main。
(2)指定程序的链接地址有2种方法：一种是在Makefile中ld的flags用-Ttext 0x20000000来指定；第二种是在链接脚本的SECTIONS开头用 .=0x20000000 来指定。两种都可以实现相同效果。其实，这两种技巧是可以共同配合使用的，也就是说既在链接脚本中指定也在ld flags中用-Ttext来指定。两个都指定以后以-Ttext指定的为准。
(3)uboot的最终链接起始地址就是在Makefile中用-Ttext 来指定的。注意Makfile中TEXT_BASE的值。最终来源是Makefile中配置对应的命令中，在make xxx_config时得到的。
x210_sd_config : unconfig
@$(MKCONFIG) $(@:_config=) arm s5pc11x x210 samsung s5pc110
@echo "TEXT_BASE = 0xc3e00000" > $(obj)board/samsung/x210/config.mk
(4)在代码段中注意文件排列的顺序。指定必须放在前面部分的那些文件就是那些必须安排在前面，先存放一些重要的东西;
(5)链接脚本中除了.text .data .rodata .bss段等编译工具自带的段之外，编译工具还允许我们自定义段。譬如uboot总的.u_boot_cmd段(与命令实现机制有关)就是自定义段。自定义段很重要。
注：本资料大部分由朱老师物联网大讲堂课程笔记整理而来、引用了百度百科、部分他人博客的内容并结合自己实际开发经历，如有侵权，联系删除！水平有限，如有错误，欢迎各位在评论区交流。