u-boot的Makefile分析
U－BOOT是一个LINUX下的工程，在编译之前必须已经安装对应体系结构的交叉编译环境，这里只针对ARM，编译器系列软件为arm-linux-*。
U－BOOT的下载地址： http://sourceforge.net/projects/u-boot
我下载的是1.1.6版本，一开始在FTP上下载了一个次新版，结果编译失败。1.1.6是没问题的。
u-boot源码结构
解压就可以得到全部u-boot源程序。在顶层目录下有18个子目录，分别存放和管理不同的源程序。这些目录中所要存放的文件有其规则，可以分为3类。
第1类目录与处理器体系结构或者开发板硬件直接相关；
第2类目录是一些通用的函数或者驱动程序；
第3类目录是u-boot的应用程序、工具或者文档。
u-boot的源码顶层目录说明
目 录 特 性 解 释 说 明
board 平台依赖 存放电路板相关的目录文件，
例如：RPXlite(mpc8xx)、
smdk2410(arm920t)、
sc520_cdp(x86) 等目录
cpu 平台依赖 存放CPU相关的目录文件
例如：mpc8xx、ppc4xx、
arm720t、arm920t、 xscale、i386等目录
lib_ppc 平台依赖 存放对PowerPC体系结构通用的文件，
主要用于实现PowerPC平台通用的函数
lib_arm 平台依赖 存放对ARM体系结构通用的文件，
主要用于实现ARM平台通用的函数
lib_i386 平台依赖 存放对X86体系结构通用的文件，
主要用于实现X86平台通用的函数
include 通用 头文件和开发板配置文件，
所有开发板的配置文件都在configs目录下
common 通用 通用的多功能函数实现
lib_generic 通用 通用库函数的实现
net 通用 存放网络的程序
fs 通用 存放文件系统的程序
post 通用 存放上电自检程序
drivers 通用 通用的设备驱动程序，主要有以太网接口的驱动
disk 通用 硬盘接口程序
rtc 通用 RTC的驱动程序
dtt 通用 数字温度测量器或者传感器的驱动
examples 应用例程 一些独立运行的应用程序的例子，例如helloworld
tools 工具 存放制作S-Record或者u-boot格式的映像等工具，
例如mkimage
doc 文档 开发使用文档
u-boot的源代码包含对几十种处理器、数百种开发板的支持。可是对于特定的开发板，配置编译过程只需要其中部分程序。这里具体以S3C2410 & arm920t处理器为例，具体分析S3C2410处理器和开发板所依赖的程序，以及u-boot的通用函数和工具。
编译
以smdk_2410板为例，编译的过程分两部：
# make smdk2410_config
# make
顶层Makefile分析
要了解一个LINUX工程的结构必须看懂Makefile，尤其是顶层的，没办法，UNIX世界就是这么无奈，什么东西都用文档去管理、配置。首先在这方面我是个新手，时间所限只粗浅地看了一些Makefile规则。
以smdk_2410为例，顺序分析Makefile大致的流程及结构如下：
1) Makefile中定义了源码及生成的目标文件存放的目录,目标文件存放目录BUILD＿DIR可以通过make O=dir 指定。如果没有指定，则设定为源码顶层目录。一般编译的时候不指定输出目录，则BUILD＿DIR为空。其它目录变量定义如下：
#OBJTREE和LNDIR为存放生成文件的目录，TOPDIR与SRCTREE为源码所在目录
OBJTREE := $(if $(BUILD_DIR),$(BUILD_DIR),$(CURDIR))
SRCTREE := $(CURDIR)
TOPDIR := $(SRCTREE)
LNDIR := $(OBJTREE)
export TOPDIR SRCTREE OBJTREE
2）定义变量MKCONFIG：这个变量指向一个脚本，即顶层目录的mkconfig。
MKCONFIG := $(SRCTREE)/mkconfig
export MKCONFIG
在编译U－BOOT之前，先要执行
# make smdk2410_config
smdk2410_config是Makefile的一个目标，定义如下：
smdk2410_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 NULL s3c24x0
unconfig::
@rm -f $(obj)include/config.h $(obj)include/config.mk /
$(obj)board*/config.tmp
显然，执行# make smdk2410_config时，先执行unconfig目标，注意不指定输出目标时，obj，src变量均为空，unconfig下面的命令清理上一次执行make *_config时生成的头文件和makefile的包含文件。主要是include/config.h 和include/config.mk文件。
然后才执行命令
@$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 NULL s3c24x0
MKCONFIG 是顶层目录下的mkcofig脚本文件，后面五个是传入的参数。
对于smdk2410_config而言，mkconfig主要做三件事：
在include文件夹下建立相应的文件（夹）软连接，
#如果是ARM体系将执行以下操作：
#ln -s asm-arm asm
#ln -s arch-s3c24x0 asm-arm/arch
#ln -s proc-armv asm-arm/proc
生成Makefile包含文件include/config.mk，内容很简单，定义了四个变量：
ARCH = arm
CPU = arm920t
BOARD = smdk2410
SOC = s3c24x0
生成include/config.h头文件，只有一行：
#include "config/smdk2410.h"
mkconfig脚本文件的执行至此结束，继续分析Makefile剩下部分。
3）包含include/config.mk，其实也就相当于在Makefile里定义了上面四个变量而已。
4) 指定交叉编译器前缀：
ifeq ($(ARCH),arm)#这里根据ARCH变量，指定编译器前缀。
CROSS_COMPILE = arm-linux-
endif
5)包含config.mk:
#包含顶层目录下的config.mk，这个文件里面主要定义了交叉编译器及选项和编译规则
# load other configuration
include $(TOPDIR)/config.mk
下面分析config.mk的内容：
＠包含体系，开发板，CPU特定的规则文件：
ifdef ARCH #指定预编译体系结构选项
sinclude $(TOPDIR)/$(ARCH)_config.mk # include architecture dependend rules
endif
ifdef CPU #定义编译时对齐，浮点等选项
sinclude $(TOPDIR)/cpu/$(CPU)/config.mk # include CPU specific rules
endif
ifdef SOC #没有这个文件
sinclude $(TOPDIR)/cpu/$(CPU)/$(SOC)/config.mk # include SoC specific rules
endif
ifdef BOARD #指定特定板子的镜像连接时的内存基地址，重要！
sinclude $(TOPDIR)/board/$(BOARDDIR)/config.mk # include board specific rules
endif
＠定义交叉编译链工具
# 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
STRIP = $(CROSS_COMPILE)strip
OBJCOPY = $(CROSS_COMPILE)objcopy
OBJDUMP = $(CROSS_COMPILE)objdump
RANLIB = $(CROSS_COMPILE)RANLIB
＠定义AR选项ARFLAGS，调试选项DBGFLAGS，优化选项OPTFLAGS
预处理选项CPPFLAGS，C编译器选项CFLAGS，连接选项LDFLAGS
LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE) $(PLATFORM_LDFLAGS) #指定了起始地址TEXT_BASE
＠指定编译规则：
$(obj)%.s: %.S
$(CPP) $(AFLAGS) -o $@ $<
$(obj)%.o: %.S
$(CC) $(AFLAGS) -c -o $@ $<
$(obj)%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $<
回到顶层makefile文件：
6）U-boot需要的目标文件。
OBJS = cpu/$(CPU)/start.o # 顺序很重要，start.o必须放第一位
7）需要的库文件：
LIBS = lib_generic/libgeneric.a
LIBS += board/$(BOARDDIR)/lib$(BOARD).a
LIBS += cpu/$(CPU)/lib$(CPU).a
ifdef SOC
LIBS += cpu/$(CPU)/$(SOC)/lib$(SOC).a
endif
LIBS += lib_$(ARCH)/lib$(ARCH).a
LIBS += fs/cramfs/libcramfs.a fs/fat/libfat.a fs/fdos/libfdos.a fs/jffs2/libjffs2.a /
fs/reiserfs/libreiserfs.a fs/ext2/libext2fs.a
LIBS += net/libnet.a
LIBS += disk/libdisk.a
LIBS += rtc/librtc.a
LIBS += dtt/libdtt.a
LIBS += drivers/libdrivers.a
LIBS += drivers/nand/libnand.a
LIBS += drivers/nand_legacy/libnand_legacy.a
LIBS += drivers/sk98lin/libsk98lin.a
LIBS += post/libpost.a post/cpu/libcpu.a
LIBS += common/libcommon.a
LIBS += $(BOARDLIBS)
LIBS := $(addprefix $(obj),$(LIBS))
.PHONY : $(LIBS)
根据上面的include/config.mk文件定义的ARCH、CPU、BOARD、SOC这些变量。硬件平台依赖的目录文件可以根据这些定义来确定。SMDK2410平台相关目录及对应生成的库文件如下。
board/smdk2410/ ：库文件board/smdk2410/libsmdk2410.a
cpu/arm920t/ ：库文件cpu/arm920t/libarm920t.a
cpu/arm920t/s3c24x0/ : 库文件cpu/arm920t/s3c24x0/libs3c24x0.a
lib_arm/ : 库文件lib_arm/libarm.a
include/asm-arm/ :下面两个是头文件。
include/configs/smdk2410.h
8）最终生成的各种镜像文件：
ALL = $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_NAND)
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 $< $@
#这里生成的是U-boot 的ELF文件镜像
$(obj)u-boot: depend version $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT)
UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) |sed -n -e ''''''''''''''''''''''''''''''''s/.*/(__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
分析一下最关键的u-boot ELF文件镜像的生成：
@依赖目标depend :生成各个子目录的.depend文件，.depend列出每个目标文件的依赖文件。生成方法，调用每个子目录的make _depend。
depend dep:
for dir in $(SUBDIRS) ; do $(MAKE) -C $$dir _depend ; done
@依赖目标version：生成版本信息到版本文件VERSION_FILE中。
version:
@echo -n "#define U_BOOT_VERSION /"U-Boot " > $(VERSION_FILE); /
echo -n "$(U_BOOT_VERSION)" >> $(VERSION_FILE); /
echo -n $(shell $(CONFIG_SHELL) $(TOPDIR)/tools/setlocalversion /
$(TOPDIR)) >> $(VERSION_FILE); /
echo "/"" >> $(VERSION_FILE)
@伪目标SUBDIRS: 执行tools ,examples ,post,post/cpu 子目录下面的make文件。
SUBDIRS = tools /
examples /
post /
post/cpu
.PHONY : $(SUBDIRS)
$(SUBDIRS):
$(MAKE) -C $@ all
@依赖目标$(OBJS)，即cpu/start.o
$(OBJS):
$(MAKE) -C cpu/$(CPU) $(if $(REMOTE_BUILD),$@,$(notdir $@))
@依赖目标$(LIBS)，这个目标太多，都是每个子目录的库文件*.a ，通过执行相应子目录下的make来完成：
$(LIBS):
$(MAKE) -C $(dir $(subst $(obj),,$@))
@依赖目标$(LDSCRIPT)：
LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds
LDFLAGS += -Bstatic -T $(LDSCRIPT) -Ttext $(TEXT_BASE) $(PLATFORM_LDFLAGS)
对于smdk2410,LDSCRIPT即连接脚本文件是board/smdk2410/u-boot.lds，定义了连接时各个目标文件是如何组织的。内容如下：
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
. = 0x00000000;
. = ALIGN(4);
.text :
{
cpu/arm920t/start.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);
__bss_start = .;
.bss : { *(.bss) }
_end = .;
}
@执行连接命令：
cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) /
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) /
-Map u-boot.map -o u-boot
其实就是把start.o和各个子目录makefile生成的库文件按照LDFLAGS连接在一起，生成ELF文件u-boot 和连接时内存分配图文件u-boot.map。
9)对于各子目录的makefile文件，主要是生成*.o文件然后执行AR生成对应的库文件。如lib_generic文件夹Makefile：
LIB = $(obj)libgeneric.a
COBJS = bzlib.o bzlib_crctable.o bzlib_decompress.o /
bzlib_randtable.o bzlib_huffman.o /
crc32.o ctype.o display_options.o ldiv.o /
string.o vsprintf.o zlib.o
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
$(LIB): $(obj).depend $(OBJS) #项层Makefile执行make libgeneric.a
$(AR) $(ARFLAGS) $@ $(OBJS)
整个makefile剩下的内容全部是各种不同的开发板的*_config:目标的定义了。
概括起来，工程的编译流程也就是通过执行执行一个make *_config传入ARCH，CPU，BOARD，SOC参数，mkconfig根据参数将include头文件夹相应的头文件夹连接好，生成 config.h。然后执行make分别调用各子目录的makefile 生成所有的obj文件和obj库文件*.a. 最后连接所有目标文件，生成镜像。不同格式的镜像都是调用相应工具由elf镜像直接或者间接生成的。
剩下的工作就是分析U-Boot源代码了。
限于个人水平，有谬误之处，欢迎指正交流。。
从U-Boot源码看C语言对汇编代码中的符号引用[转]
aaronwong: u-boot中代码的疑问(_armboot_start与_start)?
---------------------------
我使用的是u-boot-1.3.0-rc2。在cpu/pxa/start.S中，有如下的标号定义：
_TEXT_BASE:
.word TEXT_BASE
.globl _armboot_start
_armboot_start:
.word _start
.globl _bss_start
_bss_start:
.word __bss_start
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
按照上面的理解，__bss_start是uboot 的bss段起始地址，那么uboot映像的大小就是__bss_start - _start；在relocate代码段中计算uboot的大小时，也体现了这一点。
实际上，_armboot_start并没有实际意义，它只是在"ldr r2, _armboot_start"中用來寻址_start的值而已，_bss_start也是一样的道理，真正有意义的应该是_start和 __bss_start本身。
但是，令我不解的是，在C入口函数start_armboot()中(对应文件为lib_arm/board.c)，有如下代码：
void start_armboot (void)
{
.........
gd = (gd_t*)(_armboot_start - CFG_MALLOC_LEN - sizeof(gd_t)); //第一句话
..........
monitor_flash_len = _bss_start - _armboot_start; //第二句话
...............
mem_malloc_init (_armboot_start - CFG_MALLOC_LEN); //第三句话
..........
}
==============================================
按照上面的理解，_armboot_start与_bss_start都是没有实际意义的，它们只是一个地址，有实际意义的是地址中的内容_start和 __bss_start（虽然也还是地址）。象第一句话，其“意图”很明显，是把gd作为全局数据结构体的指针，并初始化为“SDRAM中的uboot起始地址(即TEXT_BASE)－CFG_MALLOC_LEN－全局数据结构体大小”。
要实现这个“意图”，应该是写成:gd = (gd_t*)(_start - CFG_MALLOC_LEN - sizeof(gd_t));或者gd = (gd_t*)(TEXT_BASE- CFG_MALLOC_LEN - sizeof(gd_t));才对阿？用_armboot_start来作运算应该是没有任何意义才对！？
第二句话也是一样的道理，它的意图是要计算u-boot映像的大小，应该写成__bss_start - _start才对阿？
我使用readelf工具查看编译所得到的uboot映像文件得到信息如下：
[[email protected] build]$ readelf -s u-boot|grep _start
1018: a1700048 0 NOTYPE GLOBAL DEFAULT 1 _bss_start
1083: a1700044 0 NOTYPE GLOBAL DEFAULT 1 _armboot_start
1142: a1700000 0 NOTYPE GLOBAL DEFAULT 1 _start
1197: a171b070 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
上面我删除了与该讨论无关的包含“_start""t的标号信息。
显然，我前面的理解应该是正确的(_start=TEXT_BASE=0xa170 0000)。那么u-boot源代码中的monitor_flash_len=_bss_start - _armboot_start=0xa1700048 - 0xa1700044 = 4，有什么意义？？
迷茫中，期盼大虾指点迷津，谢谢～！！！
eltshan: [Re: aaronwong]
-----------------
1018: a1700048 0 NOTYPE GLOBAL DEFAULT 1 _bss_start
1083: a1700044 0 NOTYPE GLOBAL DEFAULT 1 _armboot_start
1142: a1700000 0 NOTYPE GLOBAL DEFAULT 1 _start
1197: a171b070 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
我想:
_start所在的地址是a1700000,
_armboot_start 所在的地址是a1700044,
那么 根据这句:
_armboot_start: .word _start
所以_armboot_start的值应该是a1700000
所以
monitor_flash_len = _bss_start - _armboot_start = a171b070 - a1700000 = 1b070
而不是你说的 = 4
以上个人意见.
aaronwong: [Re: eltshan]
-------------------
谢谢，eltshan！你的理解是正确的，不过我看了之后还是没能想得很明白，因为我在想，按你所说，那么_start的值应该是多少呢？难道是“b reset”这条指令的机器码？所以我对ELF格式的u-boot映像文件作了反汇编，分析之后终于找到了症结所在。以下是部分分析过程，首先是反汇编：
arm-iwmmxt-linux-gnueabi-objectdump -D u-boot > u-boot.s
并提取了monitor_flash_len = _bss_start - _armboot_start;这条语句相关的反汇编代码如下：
==============================
a1700044 <_armboot_start>:
a1700044: a1700000 .word 0xa1700000
a1700048 <_bss_start>:
a1700048: a171b070 .word 0xa171b070
a171b070 :
a171b070: 00000000 .word 0x00000000
.....
a1700f40: e59f41d0 ldr r4, [pc, #464] ; a1701118
//r4=[a1701118]=a1700044
.....
a1700f7c: e59f3198 ldr r3, [pc, #408] ; a170111c
//r3=[a1700044]=a1700048
a1700f80: e5942000 ldr r2, [r4]
//r2=[a1700044]=a1700000
a1700f84: e59f4194 ldr r4, [pc, #404] ; a1701120
//r4=[a1701120]=a1719d24
a1700f88: e5933000 ldr r3, [r3]
//r3=[a1700048]=a171b070
a1700f8c: e0623003 rsb r3, r2, r3
//r3= r3-r2 = a171b070-a1700000 = 1b070;
a1700f90: e59f218c ldr r2, [pc, #396] ; a1701124
//r2=[a1701124]=a171b070
a1700f94: e5823000 str r3, [r2]
//monitor_flash_len=[r2]=r3=1b070
......
a1701118: a1700044 .word 0xa1700044
a170111c: a1700048 .word 0xa1700048
a1701120: a1719d24 .word 0xa1719d24
a1701124: a171b070 .word 0xa171b070
========================================
上面//是我自己的注释。这表明，你的理解的确是正确的。
经过这个过程之后，我终于认识到自己的误解在哪里了。原来，我是把"汇编语言中LDR伪指令对符号的引用"与"C语言中对汇编程序中符号/常量/变量的引用"搞混淆了。我想说明以下几点：
(1) readelf以及u-boot.map和System.map所给出的符号表中符号的值，实际上是表示符号所在的地址，而不是指符号本身的值。
(2) 汇编语言中没有指针的概念，因此对符号的引用是"赤裸裸"的。例如：
==========
.globl _armboot_start
_armboot_start: .word _start
ldr r2, _armboot_start
==========
实际上反汇编以后是：
============
a1700044 <_armboot_start>:
a1700044: a1700000 .word 0xa1700000
a1700074: e51f2038 ldr r2, [pc, #-56] ; a1700044 <_armboot_start>
============
也就是说，_armboot_start是一个地址0xa1700044，其中的内容是0xa1700000，上面对_armboot_start的引用是直接将其替换为其表示的地址0xa1700044，而非其中的内容0xa1700000。这就是"赤裸裸"的引用。
(3) C语言则不同，对变量/符号/常量的引用必须要通过地址来寻址，不管是全局变量还是局部变量，不同的是局部变量在生命期结束后，所占的地址空间会被释放而已。即使是函数调用时的参数传递，虽然是将实参的值"拷贝"给形参，但"拷贝"的过程也是通过实参和形参的地址来对两者进行访问的。
所以，在C语言中的 "monitor_flash_len = _bss_start - _armboot_start" 这句话中对_armboot_star的引用，实际上是把它用作了指针，把它作为访问对象的地址来使用，通过这个地址即a1700044 来访问对应存储空间所存放的内容亦即0xa1700000，_bss_start也是同样的道理。所以这句话实际上是monitor_flash_len =[a1700048]-[0xa1700044]=a171b070-a1700000 = 1b070，这样就得到了正确的结果。
现在，我们再回答最前面的问题：_start的值是什么？_start 表示地址0xa1700000 ，在汇编语言中，对_start的"绝对引用"(这里是与用相对寻址进行跳转进行区别)就是将其替换为0xa1700000，但其中存放的内容的的确确就是"b reset"这条指令的机器码，所以如果在C语言中引用_start，得到的结果反而就是这个指令的机器码了。其实这个问题很简单，只是和C语言的引用搅在一起，一些概念被偷换了而已。
以上是我的个人理解，有什么不对，还请指正。
再次感谢eltshan的提点。
U-Boot的移植之(一)基础篇：添加新的目标板定义
U-Boot的移植之(一)基础篇：添加新的目标板定义
本文使用最新的U-Boot-1.3.0-rc2。
U-Boot本身支持很多开发板，在其源代码中，每个板子都对应一个board/目录下的文件夹(笔者注：这并不确切，因为有的文件夹是供应商名称，下面可以有多个目标板目录，这里只考虑最简单的情况)，以及include/configs/目录下的目标板配置头文件。因此，要添加U-Boot对我们的目标板的支持，首先就是要建立目标板文件夹和配置头文件，并修改相关的Makefile。
下面以实例说明为U-Boot添加新的目标板定义的步骤和过程。
(1)在board/目录下建立目标板目录。
笔者的目标板是XSBASE270，处理器是PXA270。由于U-Boot中本身支持很多开发板和处理器，可以从中找出与自己处理器型号相同或相近的开发板，在此基础上再做后续修改。
adsvix使用的也是PXA27x处理器，因此可以把它作为模板。
cd board/
cp -arv adsvix xsbase270
mv xsbase270/adsvix.c xsbase270/xsbase270.c
(2)在include/configs/目录下建立目标板配置头文件。
cd include/configs/
cp adsvix.h xsbase270.h
(3)修改Makefile。
一是要在总的Makefile(U-Boot源码顶层目录下)中加入目标板的编译配置选项，这也可以参考adsvix的进行修改，只要把目标板名称改换为xsbase270即可：
adsvix_config: unconfig
@$(MKCONFIG) $(@:_config=) arm pxa adsvix
xsbase270_config: unconfig
@$(MKCONFIG) $(@:_config=) arm pxa xsbase270
这里xsbase270与board/目录下目标板文件夹名称xsbase270一致。
另外，还需要注意，该Makefile中定义了CROSS_COMPILE的值，以在交叉编译时指定交叉编译器。缺省情况下对ARM的CROSS_COMPILE定义如下：
ifeq ($(ARCH),arm)
CROSS_COMPILE = arm-linux-
endif
即定义交叉编译器名的前缀为arm-linux-，如果您使用的toolchain的名字不同，则需要作相应修改。例如笔者使用的是arm-iwmmxt-linux-gnueabi-gcc，因此要将上面改为：CROSS_COMPILE = arm-iwmmxt-linux-gnueabi- 。
二是要修改board/xsbase270下的Makefile。
#COBJS := adsvix.o pcmcia.o
COBJS := xsbase270.o pcmcia.o
这是因为前面将该目录下的源文件adsvix.c改为了xsbase270.c。
至此，将新的目标板xsbase270的定义添加到U-Boot中的工作就算完成了。下面的命令可以编译得到xsbase270的U-Boot：
# assuming you are at the top directory of u-boot
# define a build directory to keep object files during make process and also finally u-boot image
export BUILD_DIR=~/u-boot_xsbase270/build/
make xsbase270_config
# if you edit your source file and want to make again, just type “make distclean”and then call the above commands again.
make
当然，要使编译出来的这个u-boot能真正适用于我们的目标板，还有很多工作要做，包括处理器工作状态、存储器映射设置、网卡驱动的移植等等。所以，本篇的标题只是在U-Boot中添加对新目标板的“定义”，而非对新目标板的“支持”，这些工作需要对U-Boot的源代码有整体的认识，并结合自己的目标板的特性来完成。后续的篇章将继续介绍后面的内容。
作为本篇的补充内容，您也许仍有必要了解以下要点：
(1) 在MAKEALL文件中可以将新的目标板xsbase270添加到下面的list中：
#########################################################
## Xscale Systems
#########################################################
LIST_pxa=" /
adsvix /
cerf250 /
cradle /
csb226 /
delta /
innokom /
lubbock /
pleb2 /
pxa255_idp /
wepep250 /
xaeniax /
xm250 /
xsengine /
zylonite /
"
这并不是必须的，因为MAKEALL文件只用于为其中的所有目标板都编译一个u-boot时使用。
(2) 如何在U-Boot已有的目标板中找到与自己的目标板相近的目标板？
首要的是要找到与自己的目标板所用的处理器相同或统一系列的的目标板。在顶层目录下的Makefile中有各个板子的config列表，例如XScale系列的板子列表如下：
#########################################################
## XScale Systems
#########################################################
adsvix_config : unconfig
@$(MKCONFIG) $(@:_config=) arm pxa adsvix
xsbase270_config: unconfig
@$(MKCONFIG) $(@:_config=) arm pxa xsbase270
cerf250_config : unconfig
@$(MKCONFIG) $(@:_config=) arm pxa cerf250
cradle_config : unconfig
@$(MKCONFIG) $(@:_config=) arm pxa cradle
csb226_config : unconfig
@$(MKCONFIG) $(@:_config=) arm pxa csb226
delta_config :
@$(MKCONFIG) $(@:_config=) arm pxa delta
# ..... 以下省略。
(3) 修改目标板的编译优化选项。
在cpu/pxa/config.mk文件中定义了目标板的编译优化选项PLATFORM_RELFLAGS和
PLATFORM_CPPFLAGS，您可以根据自己的需要进行修改。
笔者的交叉编译器arm-iwmmxt-linux-gnueabi-gcc默认有-march=iwmmxt，遵循新的ARM EABI标准，但仍要保留PLATFORM_CPPFLAGS中的“-mapcs-32,-mabi=apcs-gnu”选项，使用旧的ABI标准来编译，因为u-boot的汇编代码并非按照新的ABI规范编写。可使用-march=armv5te来避免”warning: target CPU does not support interworking”警告。
如果编译过程中出现了关于IDE方面的错误，应修改include/configs/xsbase270.h,注释掉”#define CONFIG_CMD_IDE”这一行，以禁止编译IDE的操作命令，因为在目标板启动阶段不需要对IDE接口进行其他操作。
U-Boot的移植之(二)进阶篇：从源代码看系统启动过程（一）
U-Boot的移植之(二)进阶篇：从源代码看系统启动过程
为什么要分析源代码？分析优秀的源代码本身就是一个学习的过程，也是进行深入研究的必经之路。不过在此我们的主要目的并非要研究U-boot或Bootloader技术本身，而仅仅是为了成功的并且恰当的将U-Boot移植到我们的开发板上。只有结合源代码了解了U-boot的系统引导过程，才能在移植和调试过程中保持清晰的思路，才能在碰到困难和问题时从根本上加以解决。
在动手分析之前，至少应该对U-Boot的源代码结构有基本的了解，很多参考书都有这方面的介绍，华清远见的《嵌入式Linux系统开发技术详解——基于ARM》的讲解就比较清晰。
本文以lubbock开发板为例，以系统启动的流程为线索进行纵向分析：后续的移植工作也将以此开发板为模板。Lubbock使用PXA255处理器。
首先要找到程序入口点。从board/lubbock/u-boot.lds可以发现，u-boot的程序入口为_start，在cpu/pxa/start.o当中。因此首先要分析start.S程序，U-Boot中所有的PXA系列的处理器都从这里开始执行第一条语句。
.globl _start
_start: b reset
ldr pc, _undefined_instruction
ldr pc, _software_interrupt
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq
0x0地址开始是ARM异常向量表，学过ARM体系结构与编程的都明白，非常简单，不多废话。一上电的第一条指令是跳转到reset复位处理程序：
reset:
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
bl cpu_init_crit
#endif
#ifndef CONFIG_SKIP_RELOCATE_UBOOT
relocate:
......
一般不要定义CONFIG_SKIP_LOWLEVEL_INIT，因此，接下来跳转到cpu_init_crit处开始执行：
cpu_init_crit:
......
#ifdef CFG_CPUSPEED
ldr r0, CC_BASE
ldr r1, cpuspeed
str r1, [r0, #CCCR]
mov r0, #2
mcr p14, 0, r0, c6, c0, 0
setspeed_done:
#endif
mov ip, lr
bl lowlevel_init
mov lr, ip
ldr r0, =0x2001
......
mov pc, lr
可见，在cpu_init_crit中的主要工作是设置时钟，配置处理器主频(这时CPU的工作频率还没有改变)，调用lowlevel_init函数进行底层初始化(包括调整处理器工作频率、系统总线频率、存储器时钟频率以及存储系统的初始化等工作)，随后关闭MMU并使能I-Cache，再返回。
lowlevel_init函数在board/lubbock/lowlevel_init.S中定义，其流程都是按照PXA27X的开发手册来的，所以不再赘述。仅指出，其中的寄存器在include/asm-arm/arch-pxa/pxa-regs.h头文件中定义，寄存器初始化值在include/configs/lubbock.h中定义。另外，在后面的实际移植工作中，由于目标板XSBASE270使用的PXA270处理器，可使用adsvix开发板的lowlevel_init.S文件(lubbock中没有开启turbo模式)。
接着程序的执行线索进行分析。从cpu_init_crit返回后就开始relocate(重定位)，即将U-boot从FLASH存储器搬运到SDRAM中TEXT_BASE开始的存储空间(TEXT_BASE在board/lubbock/config.mk中定义)，并初始化堆栈(清零.bss段)，以在SDRAM中开始进入到Bootloader stage 2的C程序入口。Relocate部分开始的代码如下：
relocate:
adr r0, _start
ldr r1, _TEXT_BASE
cmp r0, r1
beq stack_setup
ldr r2, _armboot_start
ldr r3, _bss_start
sub r2, r3, r2
add r2, r0, r2
copy_loop:
ldmia r0!, {r3-r10}
stmia r1!, {r3-r10}
cmp r0, r2
ble copy_loop
stack_setup:
ldr r0, _TEXT_BASE
sub r0, r0, #CFG_MALLOC_LEN
sub r0, r0, #CFG_GBL_DATA_SIZE
#ifdef CONFIG_USE_IRQ
sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)
#endif
sub sp, r0, #12
clear_bss:
ldr r0, _bss_start
ldr r1, _bss_end
mov r2, #0x00000000
clbss_l:str r2, [r0]
add r0, r0, #4
cmp r0, r1
ble clbss_l
ldr pc, _start_armboot
_start_armboot: .word start_armboot
这是很经典的一段代码，相信学习凡是过ARM编程的，都分析过这段代码，所以也不再赘述。之所以列出这段代码，一是为了找到C程序入口start_armboot，二是为了给出U-Boot的一个存储器映射图
s
U-Boot的移植之(二)进阶篇：从源代码看系统启动过程（二）
接下来进入到Bootloader Stage 2即C语言代码部分，入口是start_armboot，对应的源文件是lib_arm/board.c，这一文件对所有的ARM处理器都是通用的，因此在移植的时候不用修改。相关源代码如下：
DECLARE_GLOBAL_DATA_PTR；
void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
#ifndef CFG_NO_FLASH
ulong size;
#endif
#if defined(CONFIG_VFD) || defined(CONFIG_LCD)
gd = (gd_t*)(_armboot_start - CFG_MALLOC_LEN - sizeof(gd_t));
......
memset ((void*)gd, 0, sizeof (gd_t));
gd->bd = (bd_t*)((char*)gd - sizeof(bd_t));
memset (gd->bd, 0, sizeof (bd_t));
monitor_flash_len = _bss_start - _armboot_start;
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) {
hang ();
}
}
#ifndef CFG_NO_FLASH
size = flash_init ();
display_flash_config (size);
#endif
mem_malloc_init (_armboot_start - CFG_MALLOC_LEN);
......
env_relocate ();
gd->bd->bi_ip_addr = getenv_IPaddr ("ipaddr");
{
int i;
ulong reg;
char *s, *e;
char tmp[64];
i = getenv_r ("ethaddr", tmp, sizeof (tmp));
s = (i > 0) ? tmp : NULL;
for (reg = 0; reg < 6; ++reg) {
gd->bd->bi_enetaddr[reg] = s ? simple_strtoul (s, &e, 16) : 0;
if (s)
s = (*e) ? e + 1 : e;
}
}
devices_init ();
.......
jumptable_init ();
console_init_r ();
enable_interrupts ();
#if defined(CONFIG_DRIVER_SMC91111)| |defined (CONFIG_DRIVER_LAN91C96)
if (getenv ("ethaddr"))
smc_set_mac_addr(gd->bd->bi_enetaddr);
#endif
if ((s = getenv ("loadaddr")) != NULL) {
load_addr = simple_strtoul (s, NULL, 16);
}
#if defined(CONFIG_CMD_NET)
if ((s = getenv ("bootfile")) != NULL)
copy_filename (BootFile, s, sizeof (BootFile));
#endif
#ifdef BOARD_LATE_INIT
board_late_init ();
#endif
......
for (;;) {
main_loop ();
}
}
gd_t是全局数据表类型，在include/asm-arm/global_data.h中定义如下：
typedef struct global_data {
bd_t *bd;
unsigned long flags;
unsigned long baudrate;
unsigned long have_console;
unsigned long reloc_off;
unsigned long env_addr;
unsigned long env_valid;
unsigned long fb_base;
.......
void **jt;
} gd_t;
其中，bd_t在include/asm-arm/u-boot.h中定义如下：
typedef struct bd_info {
int bi_baudrate;
unsigned long bi_ip_addr;
unsigned char bi_enetaddr[6];
struct environment_s *bi_env;
ulong bi_arch_number;
ulong bi_boot_params;
struct
{
ulong start;
ulong size;
}bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
jt是函数数组指针，随后将在jumptable_init()函数中初始化。
从lib_arm/board.c的源码不难分析出系统的启动流程：首先初始化全局数据表，然后顺序执行函数指针数组init_sequence中的一系列初始化函数——由其在本文件中的相关定义可得知初始化流程：
typedef int (init_fnc_t) (void);
init_fnc_t *init_sequence[] = {
cpu_init,
board_init,
interrupt_init,
env_init,
init_baudrate,
serial_init,
console_init_f,
display_banner,
#if defined(CONFIG_DISPLAY_BOARDINFO)
checkboard,
#endif
dram_init,
display_dram_config,
NULL,
};
在执行这个函数序列的过程中，任何一个函数异常返回都会导致u-boot“死锁”或说“挂起”在hang()函数的死循环当中。
若一切顺利，接下来就调用flash_init()函数初始化CFI FLASH(针对NOR型闪存而言)，该函数在drivers/cfi_flash.c中定义，不过，只有在目标板头文件中”#define CFG_FLASH_CFI_DRIVER”之后该驱动才会被编译；在lubbock的u-boot实现当中，include/configs/lubbock.h中没有定义CFG_FLASH_CFI_DRIVER，而是在board/lubbock/ flash.c中实现了自己的FLASH驱动，包括flash_init()在内。在移植U-Boot时，可以根据实际情况选择使用U-Boot自带的FLASH驱动还是自己编写新的驱动。如果配置了NAND闪存，还会对其进行初始化；笔者的XSABSE270板没有焊接NAND FLASH，故对此不作讨论。
接下来调用env_relocate()函数初始化环境变量，该函数在common/env_common.c文件中定义。在同一文件中可以发现还定义了一个字符数组default_environment[]，用于描述缺省的环境变量，这些都要在include/configs/lubbock.h头文件中进行设置，包括启动命令CONFIG_BOOTCOMMAND，波特率CONFIG_BAUDRATE，IP地址CONFIG_IPADDR等等。
然后是获取自设置的目标板的网络地址，包括IP地址和MAC地址。
再然后是调用common/devices.c中定义的devices_init()函数来创建设备列表，并初始化相应的设备，主要是”stdin”,”stdout”,”stderr”以及自定义的设备如I2C，LCD等。这些相关代码是与平台无关的，因此从移植的角度考虑，不必作细致的研究与分析。
接着调用common/exports.c中定义的jumptable_init()函数，初始化全局数据表中的跳转表gd->jt，跳转表是一个函数指针数组，定义了u-boot中基本的常用的函数库；而gd->jt是这个函数指针数组的首指针。部分代码如下：
void jumptable_init (void) {
int i;
gd->jt = (void **) malloc (XF_MAX * sizeof (void *));
for (i = 0; i < XF_MAX; i++)
gd->jt[i] = (void *) dummy;
gd->jt[XF_get_version] = (void *) get_version;
gd->jt[XF_malloc] = (void *) malloc;
gd->jt[XF_free] = (void *) free;
gd->jt[XF_getenv] = (void *) getenv;
gd->jt[XF_setenv] = (void *) setenv;
......
}
上面的XF_get_version， XF_malloc， XF_free等在include/exports.h的枚举变量中定义，因此，实际上是作为”Label式整型序号”使用，即XF_get_version=1, XF_malloc=2, XF_free=3 ...，相关代码如下：
enum {
#define EXPORT_FUNC(x) XF_ ## x ,
#include <_exports.h>
#undef EXPORT_FUNC
XF_MAX
};
EXPORT_FUNC(get_version)
EXPORT_FUNC(getc)
EXPORT_FUNC(tstc)
EXPORT_FUNC(putc)
EXPORT_FUNC(puts)
EXPORT_FUNC(printf)
.........
由于这些也是平台无关的代码，因此在移植过程中也不必深究。
然后是调用common/console.c中定义的函数console_init_r()初始化串口控制台，这同样是平台无关的代码，所以不必关心。
这时U-Boot的基本功能已经初始化完毕，便可开中断，并进行附加功能的配置与初始化，包括网卡驱动配置，目标板使用LAN91C1111网卡，对应SMC91111网卡驱动，可以根据需要配置其他的网卡驱动如CS8900等，这些都在include/configs/lubbock.h中定义。
然后是调用board/lubbock/lubbock.c中定义的board_late_init()函数进行板级的后期初始化，实际上是配置stdout和stderr的硬件设备。相关源代码如下：
int board_late_init(void)
{
setenv("stdout", "serial");
setenv("stderr", "serial");
return 0;
}
最后需要注意的一个很重要的文件是lib_arm/armlinux.c，它实现的功能包括设置内核启动参数，并负责将这些参数传递给内核，最后跳转到Linux内核入口函数，将控制权交给内核。
具体传递哪些参数，是通过在include/configs/lubbock.c中指定条件编译选项来控制的，对应于lib_arm/armlinux.c中的部分源代码形式如下：
#if defined (CONFIG_SETUP_MEMORY_TAGS) || /
defined (CONFIG_CMDLINE_TAG) || /
defined (CONFIG_INITRD_TAG) || /
defined (CONFIG_SERIAL_TAG) || /
defined (CONFIG_REVISION_TAG)
static void setup_start_tag (bd_t *bd);
# ifdef CONFIG_SETUP_MEMORY_TAGS
static void setup_memory_tags (bd_t *bd);
# endif
static void setup_commandline_tag (bd_t *bd, char *commandline);
# ifdef CONFIG_INITRD_TAG
static void setup_initrd_tag (bd_t *bd, ulong initrd_start,
ulong initrd_end);
# endif
static void setup_end_tag (bd_t *bd);
static struct tag *params;
#endif
......
void do_bootm_linux (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
ulong addr, ulong *len_ptr, int verify)
{
......
void (*theKernel)(int zero, int arch, uint params);
......
#ifdef CONFIG_CMDLINE_TAG
char *commandline = getenv ("bootargs");
#endif
theKernel = (void (*)(int, int, uint))ntohl(hdr->ih_ep);
......
theKernel (0, bd->bi_arch_number, bd->bi_boot_params);
}
关于这个参数列表中各个参数的定义及含义，以及参数列表的初始化过程，可以参考Booting ARM Linux一文。内核是如何找到这个参数列表在内存中的位置，以接收这些参数的呢？实际上，参数列表(tag list)在内存中的起始地址会保存在通用寄存器R2中，并传递给内核。而按照习惯或说惯例，通常tag list的首地址(物理地址)会设置为RAM起始地址+ 0x100偏移量，因此R2的值实际上是确定不变的。另外，还要正确设置R0和R1的值，在呼叫内核时，R0的值应为0，R1中则应保存机器类型(machine type)编号。R0,R1和R2都会作为参数传递给内核。
在上面的代码中，定义了一个函数指针theKernel，通过倒数第二条语句将内核入口地址赋给theKernel(hdr是include/image.h中定义的一个image_header结构体类型的数据，hdr->ih_ep中保存了内核入口地址，ntohl的功能是字节顺序的大小端转换，相关代码可以参考tools/mkimage.c)，最后，根据APCS规则，将0, bd->bi_arch_number, bd->bi_boot_params 依次作为参数通过R0，R1和R2传递给theKernel函数，并进入内核启动部分。
至此，我们已经从源代码入手简要分析了U-Boot的启动流程，在这个过程中，我们对前一篇文章“添加新的目标板定义”也有了更进一步的理解和认识：为什么要添加这些文件；哪些文件是平台相关的并且必须要根据平台特性进行修改的；哪些文件是平台无关的，是不需要修改的，只需在头文件中作适当配置即可。
下一节，我们将给出移植U-Boot到XSBASE270开发板的实例。
U-Boot的移植之(三)实战篇：移植U-Boot到XSBASE270开发板（一）
U-Boot的移植之(三)实战篇：移植U-Boot到XSBASE270开发板
1. 在U-Boot中添加XSBASE270目标板的定义
具体方法可参考第一节，本篇给出部分细节和要点，假定$U-BOOT为源码根目录。
############################################################
# (1)建立目标板目录
# 其中lowlevel_init.S采用adsvix的文件，以开启turbo mode，并注释掉
# 其中对pxavoltage.S文件中initPXAvolatage函数的调用。
############################################################
cd board/
cp -arv lubbock xsbase270
mv xsbase270/lubbock.c xsbase270/xsbase270.c
cp adsvix/lowlevel_init.S xsbase270/
vim xsbase270/lowlevel_init.S
@setvoltage:
@ mov r10, lr
@ bl initPXAvoltage
@ mov lr, r10
############################################################
# (2)建立目标板配置头文件
############################################################
cd $U-BOOT/include/configs
cp lubbock.h xsbase270.h
############################################################
# (3)修改Makefile
############################################################
#########在$U-BOOT/Makefile中添加：
xsbase270_config: unconfig
@$(MKCONFIG) $(@:_config=) arm pxa xsbase270
#########在$U-BOOT/Makefile中修改CROSS_COMPILE：
CROSS_COMPILE = arm-iwmmxt-linux-gnueabi-
#########在$U-BOOT/board/xsbase270/Makefile中修改：
#COBJS := lubbock.o flash.o
COBJS := xsbase270.o
这里去掉了flash.c文件，因为它是在lubbock板中自定义的FLASH存储器驱动，lubbock不使用U-Boot自带的FLASH驱动；而在本次移植中，我们将使用U-Boot自带的drivers/cfi_flash.c作为XSBASE270开发板的NOR型闪存28F128K18C的驱动程序，具体过程后述。
实际移植过程中还可能要作如下改动：
#############################################################
# (1) cpu/pxa/config.mk
#############################################################
#armv5-->armv5te, modified by aaron wong
PLATFORM_CPPFLAGS += -march=armv5te -mtune=xscale
#############################################################
# (2) include/asm-arm/mach-types.h
#############################################################
#define MACH_TYPE_XSBASE270 1141
编译U-Boot:
export BUILD_DIR=~/u-boot_xsbase270/build/
make xsbase270_config
make
作其他必要修改，直至能正常编译通过。然后再进行后续的针对目标板的定制步骤。
2. 修改U-Boot Stage 1(汇编级)的平台相关代码
U-Boot第一阶段的代码包括：
(1) cpu/pxa/start.S (平台无关，处理器架构相关)
(2) board/xsbase270/lowlevel_init.S (平台与处理器型号相关)
(3) board/xsbase270/config.mk (平台相关，设置TEXT_BASE)
(4) include/configs/xsbase270.h (平台相关，设置寄存器初值等)
lowlevel_init.S已在第一步作了相应修改。config.mk中设置TEXT_BASE(U-Boot的链接起始地址)，暂时不改动(0xa3080000)。
xsbase270.h中定义了系统初始化时的寄存器初值(主要是GPIO配置，时钟与处理器频率设置，片上存储器控制器与存储系统的初始化)，这需要根据平台进行配置。下面给出部分代码示例及注释：
#define CONFIG_PXA27X 1
#define CONFIG_XSBASE270 1
#define BOARD_LATE_INIT 1
#undef CONFIG_USE_IRQ
......
#define CFG_MALLOC_LEN (CFG_ENV_SIZE + 128*1024)
#define CFG_GBL_DATA_SIZE 128
#define CONFIG_STACKSIZE (128*1024)
#ifdef CONFIG_USE_IRQ
#define CONFIG_STACKSIZE_IRQ (4*1024)
#define CONFIG_STACKSIZE_FIQ (4*1024)
#endif
#define CFG_CPUSPEED 0x207
#define CFG_GPSR0_VAL 0x00003000
#define CFG_GPSR1_VAL 0x00000000
#define CFG_GPSR2_VAL 0x00010000
#define CFG_GPSR3_VAL 0x00020000
#define CFG_GPCR0_VAL 0x00000800
......
#define CFG_CKEN 0x00400200
#define CFG_CCCR 0x08000290
#define CFG_MSC0_VAL 0x7FF82BD0
#define CFG_MSC1_VAL 0x7FF87FF8
#define CFG_MSC2_VAL 0x7FF87FF8
#define CFG_MDCNFG_VAL 0x00001AC9
#define CFG_MDREFR_VAL 0x0000001E
#define CFG_MDMRS_VAL 0x00000000
......
#define CFG_MECR_VAL 0x00000001
#define CFG_MCMEM0_VAL 0x00010504
#define CFG_MCMEM1_VAL 0x00010504
......
3. 修改U-Boot Stage 2(C语言级)的平台相关代码
U-Boot第二阶段的大部分代码是平台无关的。从移植的角度，我们仅需要关注下面一些平台相关的代码：
(1) include/configs/xsbase270.h：通过使用定义或取消定义相关的预编译变量，用于对平台无关的代码进行平台相关的定制，包括定制U-Boot命令、缺省的环境变量、存储器映射、串口控制台配置、驱动程序等。
(2) board/xsbase270/xsbase270.c：板级初始化，只需进行最基本的配置，包括设置mach-type，启动参数列表首地址，设置标准输入输出设备，获取系统RAM配置信息等。
(3) 驱动程序的移植。最基本的是FLASH存储器驱动程序和以太网卡驱动程序。对于U-Boot中已经支持的器件，可以进行简单移植，否则需要自己加入相关的设备驱动程序。
下面对以上三部分分别阐述。
U-Boot的移植之(三)实战篇：移植U-Boot到XSBASE270开发板2
3.1 配置xsbase270.h
可以参考lubbock.h，adsvix.h等相关开发板的设置，另外也可以从U-Boot源码的README文件获取更多信息。
(1) 存储器映射配置：
#define CONFIG_NR_DRAM_BANKS 4
#define PHYS_SDRAM_1 0xa0000000
#define PHYS_SDRAM_1_SIZE 0x04000000
#define PHYS_SDRAM_2 0xa4000000
#define PHYS_SDRAM_2_SIZE 0x00000000
#define PHYS_SDRAM_3 0xa8000000
#define PHYS_SDRAM_3_SIZE 0x00000000
#define PHYS_SDRAM_4 0xac000000
#define PHYS_SDRAM_4_SIZE 0x00000000
#define PHYS_FLASH_1 0x00000000
#define PHYS_FLASH_2 0x04000000
#define PHYS_FLASH_SIZE 0x02000000
#define PHYS_FLASH_BANK_SIZE 0x02000000
#define PHYS_FLASH_SECT_SIZE 0x00040000
#define CFG_DRAM_BASE 0xa0000000
#define CFG_DRAM_SIZE 0x04000000
#define CFG_FLASH_BASE PHYS_FLASH_1
//you can also add other IO address map here, such as a FPGA
(2) 定制U-Boot命令：
在include/config_cmd_default.h头文件中已经预定义了一些常用的U-Boot命令，我们可以在include/configs/xsbase270.h中包含该头文件，对于其中已定义的不需要的命令，可用undef去除；对于要添加的命令，使用define定义相关的符号即可。
#include
#define CONFIG_CMD_PING
(3) 控制台串口配置：
包括指定控制台所用的PXA27X串口，缺省的串口通信波特率等。
#define CONFIG_FFUART 1
#define CONFIG_BAUDRATE 115200
(4) 环境变量设置
包括BOOTP选项设置，缺省环境变量设置，启动参数列表配置等。
#define CONFIG_BOOTP_BOOTFILESIZE
#define CONFIG_BOOTP_BOOTPATH
#define CONFIG_BOOTP_HOSTNAME
#define CONFIG_BOOTDELAY 3
#define CONFIG_ETHADDR 08:00:3e:26:0a:5b
#define CONFIG_NETMASK 255.255.255.0
#define CONFIG_IPADDR 192.168.0.21
#define CONFIG_SERVERIP 192.168.0.250
#define CONFIG_BOOTCOMMAND "bootm 80000"
#define CONFIG_BOOTARGS "root=/dev/ram0,rw mem=64M console=ttyS0, 115200"
#define CONFIG_CMDLINE_TAG
#define CONFIG_TIMESTAMP
#define CONFIG_ENV_OVERWRITE
其中，CONFIG_BOOTCOMMAND和CONFIG_BOOTARGS在后续的引导内核实验中还需要进行修正。
(5) 网卡驱动程序配置：
#define CONFIG_DRIVER_SMC91111
#define CONFIG_SMC91111_BASE 0x0C000000
#define CONFIG_SMC_USE_32_BIT 1
XSBASE270采用的网卡是LAN91C111，U-Boot自带的驱动程序drivers/smc91111.c可支持这款网卡，因此只要在这里作相应的配置即可。CONFIG_SMC91111_BASE要根据PXA27X对网卡的地址译码来决定(片选信号CSx和高位地址线)，CONFIG_SMC_USE_32_BIT指定了网卡工作于32位数据总线模式。可以查看驱动程序源代码得到更多配置选项。
(6) NOR型闪存驱动程序配置：
U-Boot本身支持一系列符合CFI(Common Flash Interface)接口规范的闪存，其缺省支持的闪存芯片信息在include/flash.h中定义，该头文件中还定义了CFI闪存驱动所必需的数据结构和其他物理及结构特性描述符。NAND闪存驱动在drivers/nand目录下，这里不予考虑。CFI是针对NOR型FLASH所提出的一种获取闪存芯片物理和结构参数的操作规程和标准。
XSBASE270采用两片Intel 28F128K18C的兼容CFI标准的NOR型闪存，单片容量为16MB，数据线宽度为16-bit，两片并作一个32MB容量的数据宽度为32-bit的BANK来使用。在头文件include/flash.h中没有定义该芯片的相关信息，可以手动添加；这并不是必须的，如果你并不需要使用这些信息的话(例如将CFI驱动所检测到的Device Id与头文件中定义的Device ID进行比对与验证)。
#define INTEL_ID_28F128K18 0x88068806
#define FLASH_28F128K18 0x00BA
要使用U-Boot自带的CFI闪存驱动，必须要作的是在include/configs/xsbase270.h中添加如下定义:
#define CFG_FLASH_CFI
#define CFG_FLASH_CFI_DRIVER 1
#define CFG_FLASH_CFI_WIDTH FLASH_CFI_32BIT
#define CFG_MAX_FLASH_BANKS 1
#define CFG_MAX_FLASH_SECT 128
#define CFG_FLASH_ERASE_TOUT (25*CFG_HZ)
#define CFG_FLASH_WRITE_TOUT (25*CFG_HZ)
#define CFG_FLASH_USE_BUFFER_WRITE 1
另外，如果把环境变量保存在FLASH中，还有如下相关定义：
#define CFG_MONITOR_BASE 0
#define CFG_MONITOR_LEN PHYS_FLASH_SECT_SIZE
#define CFG_ENV_IS_IN_FLASH 1
#define CFG_ENV_ADDR (PHYS_FLASH_1 + PHYS_FLASH_SECT_SIZE)
#define CFG_ENV_SECT_SIZE PHYS_FLASH_SECT_SIZE
#define CFG_ENV_SIZE (PHYS_FLASH_SECT_SIZE / 16)
#define CFG_FLASH_PROTECTION
(7) 其他配置：
#define CFG_HUSH_PARSER 1
#define CFG_PROMPT_HUSH_PS2 "> "
#define CFG_LONGHELP
#ifdef CFG_HUSH_PARSER
#define CFG_PROMPT "$ "
#endif
#define CFG_CBSIZE 256
#define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)
#define CFG_MAXARGS 16
#define CFG_BARGSIZE CFG_CBSIZE
#define CFG_DEVICE_NULLDEV 1
#define CFG_MEMTEST_START 0xa0400000
#define CFG_MEMTEST_END 0xa0800000
#undef CFG_CLKS_IN_HZ
#define CFG_LOAD_ADDR (CFG_DRAM_BASE + 0x8000)
#define CFG_HZ 3686400
#define CFG_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
至此，目标板配置头文件xsbase270.h就完成了。
3.2 板级初始化代码xsbase270.c
只需修改board_init()函数即可，完整代码如下：
#include
DECLARE_GLOBAL_DATA_PTR;
int board_init (void)
{
gd->bd->bi_arch_number = MACH_TYPE_XSBASE270;
gd->bd->bi_boot_params = 0xa0000100;
return 0;
}
int board_late_init(void)
{
setenv("stdout", "serial");
setenv("stderr", "serial");
return 0;
}
int dram_init (void)
{
gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
gd->bd->bi_dram[2].size = PHYS_SDRAM_3_SIZE;
gd->bd->bi_dram[3].start = PHYS_SDRAM_4;
gd->bd->bi_dram[3].size = PHYS_SDRAM_4_SIZE;
return 0;
}
3.3 驱动程序移植
最主要的是闪存和网卡驱动程序的移植。由于使用U-Boot自带的CFI闪存驱动程序和SMC91111网卡驱动程序，应此只要在头文件中进行相关配置即可完成。具体见3.1节。如果需要自行添加相关的设备驱动，则需要在board/xsbase270/目录下添加驱动源文件，并将其添加到该目录下的Makefile中进行编译与链接。
至此，针对特定目标板的U-Boot软件移植工作基本完成。在下一节中，将简单讨论U-Boot的基本的硬件调试方法与技巧。
U-Boot的移植之(四)调试篇：下载U-Boot到目标板进行调试
U-Boot的移植之(四)调试篇：下载U-Boot到目标板进行调试
编译完成之后，得到的几个重要文件是：
(1) u-boot.bin: 116K，原始二进制文件，用于下载到启动ROM进行系统引导；
(2) u-boot: 384K，ELF格式映像文件，可加载到SDRAM或SRAM中进行调试；
(3) u-boot.srec: Motorola S-Records格式映像。
(4) System.map: U-Boot映像文件的符号表，各符号的链接地址。
最有效的调试方法是下载到目标板的启动闪存，使用硬件仿真器进行跟踪调试。使用Skyeye，Qemu等软件仿真器不能达到真实的调试效果，尤其不能真实反映第一阶段的底层初始化过程，只适合作U-Boot的学习与研究之用。有人提出在没有硬件仿真器的情况下，使用“点灯大法(利用目标板的LED指示程序运行阶段)”进行跟踪调试，这实际上无异于盲人摸象，特别是在底层初始化阶段，一条指令就可能导致异常。也有人提出注释掉start.S中的lowlevel_init调用，将U-Boot映像加载到SDRAM中进行调试，这实际上只能对U-Boot进行功能调试，而无法跟踪U-Boot的底层初始化过程。当然，如果实在嫌烧写FLASH的速度较慢，又心疼其擦写寿命，也可以将U-Boot映像加载到片上SRAM中调试，因为U-Boot的开始一部分代码是位置无关的(除了后6个异常向量外，不过并不构成影响)；这要求片上SRAM够大，因为U-Boot的映像大小约有300K－400K。
笔者使用Banyan-U ARM EMULATOR JTAG仿真器，结合AXD软件平台进行调试。
首先将u-boot.bin下载到FLASH地址0x0，连接好串口，启动minicom或超级终端，目标板上电后，串口控制台无任何输出。这很有可能是lowlevel_init那段代码出了问题，因为它牵涉到GPIO的配置，处理器时钟频率设置，系统总线频率与存储器的时序匹配及初始化，稍有差错就会当机。当然也有可能是串口的配置不正确，但这部分比较简单，出错的可能性比较小。
对于下载到FLASH存储器的原始二进制文件，只能进行汇编级的跟踪调试。先利用objdump工具生成U-Boot映像的反汇编代码：
arm-iwmmxt-linux-gnueabi-objdump -S u-boot > u-boot.S
反汇编代码u-boot.S和符号表System.map将是跟踪调试过程中的得力助手。
另一个重要的调试技巧是在AXD中现场修改寄存器和存储单元的内容，这样可以帮助我们找到问题所在，而不必每次改动都重新编译u-boot，也避免了FLASH的频繁烧写。
例如，笔者在单步跟踪调试时，发现在地址0xa30804b4处，使用指令”str r1, [r0]”配置GPDR1(GPIO方向寄存器1)后，存储器0x0地址开始的大片内容全部被更改，导致异常终止。这时可以在该处设置一个断点，复位目标板全速运行到断点处，修改寄存器r1的值(GPDR1的初值)，再执行该条指令。经试验发现，对于XSBASE270开发板，必须要先初始化GAFRx，再初始化GPDRx，才不致于发生上述异常。而在start.S中，是先完成GPDRx的初始化之后，再初始化GAFRx的，因此需要在源代码中将这两段代码的位置互换，重新编译后，再下载到FLASH中。
U-Boot的串口控制台输出如下：
U-Boot 1.3.0-rc2 (Oct 16 2007 - 01:57:29)
DRAM: 64 MB
Flash: 32 MB
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
$
另一个问题是环境变量的设置与保存。将环境变量保存在FLASH中，使用setenv命令设置环境变量，再使用saveenv命令保存，这样在下次开机时，就会使用新的环境变量。如果使用的是U-Boot自带的CFI闪存驱动，在保存环境变量时可能会出现如下问题：
$ setenv ipaddr 192.168.1.21
$ saveenv
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...
Flash erase error at address 40000
Block Erase Error.
Block locked.
done
Erased 1 sectors
这是因为缺省情况下U-Boot对FLASH有软件写保护，这时在U-Boot启动完毕后即使使用jflashmm工具也无法对FLASH进行烧写：
[a[email protected] Jflash-XSBase270]$ sudo ./jflashmm u-boot.bin
JFLASH Version 5.01.007
COPYRIGHT (C) 2000 - 2003 Intel Corporation
PLATFORM SELECTION:
Processor= PXA27x
Development System= XSBase270
Data Version= 1.00.001
PXA27x revision ??
Found flash type: 28F128K18
Erasing block at address 0
Error, Block erase timed out
解决办法可参考Uboot-Users邮件列表Erase error on dual P30(CFI) flash chips主题讨论，具体是在include/configs/xsbase270.h中定义CFG_FLASH_PROTECTION，该选项在README文件中的描述如下：
- CFG_FLASH_PROTECTION
If defined, hardware flash sectors protection is used
instead of U-Boot software protection.
修改完毕重新编译U-Boot，在目标板上电后U-Boot启动完毕之前，使用jflashmm工具将新的u-boot.bin烧写到目标板启动闪存。这时可成功修改环境变量并保存到FLASH中：
$ setenv ipaddr 192.168.1.21
$ saveenv
Saving Environment to Flash...
. done
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... done
. done
Protected 1 sectors
一旦U-Boot的基本功能调试通过，能正常在目标板运行，剩余的工作就是根据实际情况调整TEXT_BASE以及内核引导参数，使用U-Boot来引导Linux内核。在下一节中，将给出U-Boot引导Linux内核的实例。
![写在工作13周年[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)