1.1 U-Boot工作过程
U-Boot启动内核的过程可以分为两个阶段，两个阶段的功能如下：
（1）第一阶段的功能
Ø 硬件设备初始化
Ø 加载U-Boot第二阶段代码到RAM空间
Ø 设置好栈
Ø 跳转到第二阶段代码入口
（2）第二阶段的功能
Ø 初始化本阶段使用的硬件设备
Ø 检测系统内存映射
Ø 将内核从Flash读取到RAM中
Ø 为内核设置启动参数
Ø 调用内核
1.1.1 U-Boot启动第一阶段代码分析
第一阶段对应的文件是cpu/arm920t/start.S和board/samsung/mini2440/lowlevel_init.S。
U-Boot启动第一阶段流程如下：
图 2.1 U-Boot启动第一阶段流程
根据cpu/arm920t/u-boot.lds中指定的连接方式：
ENTRY(_start)
SECTIONS
{
. = 0x00000000;
. = ALIGN(4);
.text :
{
cpu/arm920t/start.o (.text)
board/samsung/mini2440/lowlevel_init.o (.text)
board/samsung/mini2440/nand_read.o (.text)
*(.text)
}
… …
}
第一个链接的是cpu/arm920t/start.o，因此u-boot.bin的入口代码在cpu/arm920t/start.o中，其源代码在cpu/arm920t/start.S中。下面我们来分析cpu/arm920t/start.S的执行。
1. 硬件设备初始化
（1）设置异常向量
cpu/arm920t/start.S开头有如下的代码：
.globl _start
_start: b start_code /*复位 */
ldr pc, _undefined_instruction /* 未定义指令向量 */
ldr pc, _software_interrupt /* 软件中断向量 */
ldr pc, _prefetch_abort /* 预取指令异常向量 */
ldr pc, _data_abort /* 数据操作异常向量 */
ldr pc, _not_used /* 未使用 */
ldr pc, _irq /* irq中断向量 */
ldr pc, _fiq /* fiq中断向量 */
/* 中断向量表入口地址 */
_undefined_instruction: .word undefined_instruction
_software_interrupt: .word software_interrupt
_prefetch_abort: .word prefetch_abort
_data_abort: .word data_abort
_not_used: .word not_used
_irq: .word irq
_fiq: .word fiq
.balignl 16,0xdeadbeef
以上代码设置了ARM异常向量表，各个异常向量介绍如下：
表 2.1 ARM异常向量表
| 地址 | 异常 | 进入模式 | 描述 |
| 0x00000000 | 复位 | 管理模式 | 复位电平有效时，产生复位异常，程序跳转到复位处理程序处执行 |
| 0x00000004 | 未定义指令 | 未定义模式 | 遇到不能处理的指令时，产生未定义指令异常 |
| 0x00000008 | 软件中断 | 管理模式 | 执行SWI指令产生，用于用户模式下的程序调用特权操作指令 |
| 0x0000000c | 预存指令 | 中止模式 | 处理器预取指令的地址不存在，或该地址不允许当前指令访问，产生指令预取中止异常 |
| 0x00000010 | 数据操作 | 中止模式 | 处理器数据访问指令的地址不存在，或该地址不允许当前指令访问时，产生数据中止异常 |
| 0x00000014 | 未使用 | 未使用 | 未使用 |
| 0x00000018 | IRQ | IRQ | 外部中断请求有效，且CPSR中的I位为0时，产生IRQ异常 |
| 0x0000001c | FIQ | FIQ | 快速中断请求引脚有效，且CPSR中的F位为0时，产生FIQ异常 |
在cpu/arm920t/start.S中还有这些异常对应的异常处理程序。当一个异常产生时，CPU根据异常号在异常向量表中找到对应的异常向量，然后执行异常向量处的跳转指令，CPU就跳转到对应的异常处理程序执行。
其中复位异常向量的指令“b start_code”决定了U-Boot启动后将自动跳转到标号“start_code”处执行。
（2）CPU进入SVC模式
start_code:
/*
* set the cpu to SVC32 mode
*/
mrs r0, cpsr
bic r0, r0, #0x1f /*工作模式位清零 */
orr r0, r0, #0xd3 /*工作模式位设置为“10011”（管理模式），并将中断禁止位和快中断禁止位置1 */
msr cpsr, r0
以上代码将CPU的工作模式位设置为管理模式，并将中断禁止位和快中断禁止位置一，从而屏蔽了IRQ和FIQ中断。
（3）设置控制寄存器地址
# if defined(CONFIG_S3C2400)
# define pWTCON 0x15300000
# define INTMSK 0x14400008
# define CLKDIVN 0x14800014
#else /* s3c2410与s3c2440下面4个寄存器地址相同 */
# define pWTCON 0x53000000 /* WATCHDOG控制寄存器地址 */
# define INTMSK 0x4A000008 /* INTMSK寄存器地址 */
# define INTSUBMSK 0x4A00001C /* INTSUBMSK寄存器地址 */
# define CLKDIVN 0x4C000014 /* CLKDIVN寄存器地址 */
# endif
对与s3c2440开发板，以上代码完成了WATCHDOG，INTMSK，INTSUBMSK，CLKDIVN四个寄存器的地址的设置。各个寄存器地址参见参考文献[4] 。
（4）关闭看门狗
ldr r0, =pWTCON
mov r1, #0x0
str r1, [r0] /*看门狗控制器的最低位为0时，看门狗不输出复位信号 */
以上代码向看门狗控制寄存器写入0，关闭看门狗。否则在U-Boot启动过程中，CPU将不断重启。
（5）屏蔽中断
/*
* mask all IRQs by setting all bits in the INTMR - default
*/
mov r1, #0xffffffff /* 某位被置1则对应的中断被屏蔽 */
ldr r0, =INTMSK
str r1, [r0]
INTMSK是主中断屏蔽寄存器，每一位对应SRCPND（中断源引脚寄存器）中的一位，表明SRCPND相应位代表的中断请求是否被CPU所处理。
根据参考文献4，INTMSK寄存器是一个32位的寄存器，每位对应一个中断，向其中写入0xffffffff就将INTMSK寄存器全部位置一，从而屏蔽对应的中断。
# if defined(CONFIG_S3C2440)
ldr r1, =0x7fff
ldr r0, =INTSUBMSK
str r1, [r0]
# endif
INTSUBMSK每一位对应SUBSRCPND中的一位，表明SUBSRCPND相应位代表的中断请求是否被CPU所处理。
根据参考文献4，INTSUBMSK寄存器是一个32位的寄存器，但是只使用了低15位。向其中写入0x7fff就是将INTSUBMSK寄存器全部有效位（低15位）置一，从而屏蔽对应的中断。
（6）设置MPLLCON,UPLLCON, CLKDIVN
# if defined(CONFIG_S3C2440)
#define MPLLCON 0x4C000004
#define UPLLCON 0x4C000008
ldr r0, =CLKDIVN
mov r1, #5
str r1, [r0]
ldr r0, =MPLLCON
ldr r1, =0x7F021
str r1, [r0]
ldr r0, =UPLLCON
ldr r1, =0x38022
str r1, [r0]
# else
/* FCLK:HCLK:PCLK = 1:2:4 */
/* default FCLK is 120 MHz ! */
ldr r0, =CLKDIVN
mov r1, #3
str r1, [r0]
#endif
CPU上电几毫秒后，晶振输出稳定，FCLK=Fin（晶振频率），CPU开始执行指令。但实际上，FCLK可以高于Fin，为了提高系统时钟，需要用软件来启用PLL。这就需要设置CLKDIVN，MPLLCON，UPLLCON这3个寄存器。
CLKDIVN寄存器用于设置FCLK，HCLK，PCLK三者间的比例，可以根据表2.2来设置。
表 2.2 S3C2440 的CLKDIVN寄存器格式
| CLKDIVN | 位 | 说明 | 初始值 |
| HDIVN | [2:1] | 00 : HCLK = FCLK/1. 01 : HCLK = FCLK/2. 10 : HCLK = FCLK/4 （当 CAMDIVN[9] = 0 时） HCLK= FCLK/8 （当 CAMDIVN[9] = 1 时） 11 : HCLK = FCLK/3 （当 CAMDIVN[8] = 0 时） HCLK = FCLK/6 （当 CAMDIVN[8] = 1时） | 00 |
| PDIVN | [0] | 0: PCLK = HCLK/1 1: PCLK = HCLK/2 | 0 |
设置CLKDIVN为5，就将HDIVN设置为二进制的10，由于CAMDIVN[9]没有被改变过，取默认值0，因此HCLK = FCLK/4。PDIVN被设置为1，因此PCLK= HCLK/2。因此分频比FCLK:HCLK:PCLK = 1:4:8 。
MPLLCON寄存器用于设置FCLK与Fin的倍数。MPLLCON的位[19:12]称为MDIV，位[9:4]称为PDIV，位[1:0]称为SDIV。
对于S3C2440，FCLK与Fin的关系如下面公式：
MPLL(FCLK) = (2×m×Fin)/(p×)
其中： m=MDIC+8，p=PDIV+2，s=SDIV
MPLLCON与UPLLCON的值可以根据参考文献4中“PLL VALUE SELECTION TABLE”设置。该表部分摘录如下：
表 2.3 推荐PLL值
| 输入频率 | 输出频率 | MDIV | PDIV | SDIV |
| 12.0000MHz | 48.00 MHz | 56(0x38) | 2 | 2 |
| 12.0000MHz | 405.00 MHz | 127(0x7f) | 2 | 1 |
当mini2440系统主频设置为405MHZ，USB时钟频率设置为48MHZ时，系统可以稳定运行，因此设置MPLLCON与UPLLCON为：
MPLLCON=(0x7f<<12) | (0x02<<4) | (0x01) = 0x7f021
UPLLCON=(0x38<<12) | (0x02<<4) | (0x02) = 0x38022
（7）关闭MMU，cache
接着往下看：
#ifndef CONFIG_SKIP_LOWLEVEL_INIT
bl cpu_init_crit
#endif
cpu_init_crit这段代码在U-Boot正常启动时才需要执行，若将U-Boot从RAM中启动则应该注释掉这段代码。
下面分析一下cpu_init_crit到底做了什么：
320 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
321 cpu_init_crit:
322 /*
323 * 使数据cache与指令cache无效 */
324 */
325 mov r0, #0
326 mcr p15, 0, r0, c7, c7, 0 /* 向c7写入0将使ICache与DCache无效*/
327 mcr p15, 0, r0, c8, c7, 0 /* 向c8写入0将使TLB失效 */
328
329 /*
330 * disable MMU stuff and caches
331 */
332 mrc p15, 0, r0, c1, c0, 0 /* 读出控制寄存器到r0中 */
333 bic r0, r0, #0x00002300 @ clear bits 13, 9:8 (--V- --RS)
334 bic r0, r0, #0x00000087 @ clear bits 7, 2:0 (B--- -CAM)
335 orr r0, r0, #0x00000002 @ set bit 2 (A) Align
336 orr r0, r0, #0x00001000 @ set bit 12 (I) I-Cache
337 mcr p15, 0, r0, c1, c0, 0 /* 保存r0到控制寄存器 */
338
339 /*
340 * before relocating, we have to setup RAM timing
341 * because memory timing is board-dependend, you will
342 * find a lowlevel_init.S in your board directory.
343 */
344 mov ip, lr
345
346 bl lowlevel_init
347
348 mov lr, ip
349 mov pc, lr
350 #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
代码中的c0，c1，c7，c8都是ARM920T的协处理器CP15的寄存器。其中c7是cache控制寄存器，c8是TLB控制寄存器。325~327行代码将0写入c7、c8，使Cache，TLB内容无效。
第332~337行代码关闭了MMU。这是通过修改CP15的c1寄存器来实现的，先看CP15的c1寄存器的格式（仅列出代码中用到的位）：
表 2.3 CP15的c1寄存器格式（部分）
| 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| . | . | V | I | . | . | R | S | B | . | . | . | . | C | A | M |
各个位的意义如下：
V : 表示异常向量表所在的位置，0：异常向量在0x00000000；1：异常向量在 0xFFFF0000
I : 0 ：关闭ICaches；1 ：开启ICaches
R、S : 用来与页表中的描述符一起确定内存的访问权限
B : 0 ：CPU为小字节序；1 ： CPU为大字节序
C : 0：关闭DCaches；1：开启DCaches
A : 0：数据访问时不进行地址对齐检查；1：数据访问时进行地址对齐检查
M : 0：关闭MMU；1：开启MMU
332~337行代码将c1的 M位置零，关闭了MMU。
（8）初始化RAM控制寄存器
其中的lowlevel_init就完成了内存初始化的工作，由于内存初始化是依赖于开发板的，因此lowlevel_init的代码一般放在board下面相应的目录中。对于mini2440，lowlevel_init在board/samsung/mini2440/lowlevel_init.S中定义如下：
45 #define BWSCON 0x48000000 /* 13个存储控制器的开始地址 */
… …
129 _TEXT_BASE:
130 .word TEXT_BASE
131
132 .globl lowlevel_init
133 lowlevel_init:
134 /* memory control configuration */
135 /* make r0 relative the current location so that it */
136 /* reads SMRDATA out of FLASH rather than memory ! */
137 ldr r0, =SMRDATA
138 ldr r1, _TEXT_BASE
139 sub r0, r0, r1 /* SMRDATA减 _TEXT_BASE就是13个寄存器的偏移地址 */
140 ldr r1, =BWSCON /* Bus Width Status Controller */
141 add r2, r0, #13*4
142 0:
143 ldr r3, [r0], #4 /*将13个寄存器的值逐一赋值给对应的寄存器*/
144 str r3, [r1], #4
145 cmp r2, r0
146 bne 0b
147
148 /* everything is fine now */
149 mov pc, lr
150
151 .ltorg
152 /* the literal pools origin */
153
154 SMRDATA: /* 下面是13个寄存器的值 */
155 .word … …
156 .word … …
… …
lowlevel_init初始化了13个寄存器来实现RAM时钟的初始化。lowlevel_init函数对于U-Boot从NAND Flash或NOR Flash启动的情况都是有效的。
U-Boot.lds链接脚本有如下代码：
.text :
{
cpu/arm920t/start.o (.text)
board/samsung/mini2440/lowlevel_init.o (.text)
board/samsung/mini2440/nand_read.o (.text)
… …
}
board/samsung/mini2440/lowlevel_init.o将被链接到cpu/arm920t/start.o后面，因此board/samsung/mini2440/lowlevel_init.o也在U-Boot的前4KB的代码中。
U-Boot在NAND Flash启动时，lowlevel_init.o将自动被读取到CPU内部4KB的内部RAM中。因此第137~146行的代码将从CPU内部RAM中复制寄存器的值到相应的寄存器中。
对于U-Boot在NOR Flash启动的情况，由于U-Boot连接时确定的地址是U-Boot在内存中的地址，而此时U-Boot还在NOR Flash中，因此还需要在NOR Flash中读取数据到RAM中。
由于NOR Flash的开始地址是0，而U-Boot的加载到内存的起始地址是TEXT_BASE，SMRDATA标号在Flash的地址就是SMRDATA－TEXT_BASE。
综上所述，lowlevel_init的作用就是将SMRDATA开始的13个值复制给开始地址[BWSCON]的13个寄存器，从而完成了存储控制器的设置。
（9）复制U-Boot第二阶段代码到RAM
cpu/arm920t/start.S原来的代码是只支持从NOR Flash启动的，经过修改现在U-Boot在NOR Flash和NAND Flash上都能启动了，实现的思路是这样的：
bl bBootFrmNORFlash /* 判断U-Boot是在NAND Flash还是NOR Flash启动 */
cmp r0, #0 /* r0存放bBootFrmNORFlash函数返回值，若返回0表示NAND Flash启动，否则表示在NOR Flash启动 */
beq nand_boot /* 跳转到NAND Flash启动代码 */
/* NOR Flash启动的代码 */
b stack_setup /*跳过NAND Flash启动的代码 */
nand_boot:
/* NAND Flash启动的代码 */
stack_setup:
/*其他代码 */
其中bBootFrmNORFlash函数作用是判断U-Boot是在NAND Flash启动还是NOR Flash启动，若在NOR Flash启动则返回1，否则返回0。根据ATPCS规则，函数返回值会被存放在r0寄存器中，因此调用bBootFrmNORFlash函数后根据r0的值就可以判断U-Boot在NAND Flash启动还是NOR Flash启动。bBootFrmNORFlash函数在board/samsung/mini2440/nand_read.c中定义如下：
int bBootFrmNORFlash(void)
{
volatile unsigned int *pdw = (volatile unsigned int *)0;
unsigned int dwVal;
dwVal = *pdw; /*先记录下原来的数据 */
*pdw = 0x12345678;
if (*pdw != 0x12345678) /* 写入失败，说明是在NOR Flash启动 */
{
return 1;
}
else /* 写入成功，说明是在NAND Flash启动 */
{
*pdw = dwVal; /* 恢复原来的数据 */
return 0;
}
}
无论是从NOR Flash还是从NAND Flash启动，地址0处为U-Boot的第一条指令“ b start_code”。
对于从NAND Flash启动的情况，其开始4KB的代码会被自动复制到CPU内部4K内存中，因此可以通过直接赋值的方法来修改。
对于从NOR Flash启动的情况，NOR Flash的开始地址即为0，必须通过一定的命令序列才能向NOR Flash中写数据，所以可以根据这点差别来分辨是从NAND Flash还是NOR Flash启动：向地址0写入一个数据，然后读出来，如果发现写入失败的就是NOR Flash，否则就是NAND Flash。
下面来分析NOR Flash启动部分代码：
208 adr r0, _start /* r0<- current position of code */
209 ldr r1, _TEXT_BASE /* test if we run from flash or RAM */
/* 判断U-Boot是否是下载到RAM中运行，若是，则不用 再复制到RAM中了，这种情况通常在调试U-Boot时才发生 */
210 cmp r0, r1 /*_start等于_TEXT_BASE说明是下载到RAM中运行 */
211 beq stack_setup
212 /* 以下直到nand_boot标号前都是NOR Flash启动的代码 */
213 ldr r2, _armboot_start
214 ldr r3, _bss_start
215 sub r2, r3, r2 /* r2<- size of armboot */
216 add r2, r0, r2 /* r2<- source end address */
217 /* 搬运U-Boot自身到RAM中*/
218 copy_loop:
219 ldmia r0!, {r3-r10} /* 从地址为[r0]的NOR Flash中读入8个字的数据 */
220 stmia r1!, {r3-r10} /* 将r3至r10寄存器的数据复制给地址为[r1]的内存 */
221 cmp r0, r2 /* until source end addreee [r2] */
222 ble copy_loop
223 b stack_setup /* 跳过NAND Flash启动的代码 */
下面再来分析NAND Flash启动部分代码：
nand_boot:
mov r1, #NAND_CTL_BASE
ldr r2, =( (7<<12)|(7<<8)|(7<<4)|(0<<0) )
str r2, [r1, #oNFCONF] /* 设置NFCONF寄存器 */
/*设置NFCONT，初始化ECC编/解码器，禁止NAND Flash片选 */
ldr r2, =( (1<<4)|(0<<1)|(1<<0) )
str r2, [r1, #oNFCONT]
ldr r2, =(0x6) /* 设置NFSTAT */
str r2, [r1, #oNFSTAT]
/*复位命令，第一次使用NAND Flash前复位 */
mov r2, #0xff
strb r2, [r1, #oNFCMD]
mov r3, #0
/* 为调用C函数nand_read_ll准备堆栈 */
ldr sp, DW_STACK_START
mov fp, #0
/* 下面先设置r0至r2，然后调用nand_read_ll函数将U-Boot读入RAM */
ldr r0, =TEXT_BASE /* 目的地址：U-Boot在RAM的开始地址 */
mov r1, #0x0 /* 源地址：U-Boot在NAND Flash中的开始地址 */
mov r2, #0x30000 /* 复制的大小，必须比u-boot.bin文件大，并且必须是NAND Flash块大小的整数倍，这里设置为0x30000（192KB） */
bl nand_read_ll /*跳转到nand_read_ll函数，开始复制U-Boot到RAM */
tst r0, #0x0 /*检查返回值是否正确 */
beq stack_setup
bad_nand_read:
loop2: b loop2 //infinite loop
.align 2
DW_STACK_START: .word STACK_BASE+STACK_SIZE-4
其中NAND_CTL_BASE，oNFCONF等在include/configs/mini2440.h中定义如下：
#define NAND_CTL_BASE 0x4E000000 // NAND Flash控制寄存器基址
#define STACK_BASE 0x33F00000 //base address of stack
#define STACK_SIZE 0x8000 //size of stack
#define oNFCONF 0x00 /* NFCONF相对于NAND_CTL_BASE偏移地址 */
#define oNFCONT 0x04 /* NFCONT相对于NAND_CTL_BASE偏移地址*/
#define oNFADDR 0x0c /* NFADDR相对于NAND_CTL_BASE偏移地址*/
#define oNFDATA 0x10 /* NFDATA相对于NAND_CTL_BASE偏移地址*/
#define oNFCMD 0x08 /* NFCMD相对于NAND_CTL_BASE偏移地址*/
#define oNFSTAT 0x20 /* NFSTAT相对于NAND_CTL_BASE偏移地址*/
#define oNFECC 0x2c /* NFECC相对于NAND_CTL_BASE偏移地址*/
NAND Flash各个控制寄存器的设置在S3C2440的数据手册有详细说明，这里就不介绍了。
代码中nand_read_ll函数的作用是在NAND Flash中搬运U-Boot到RAM，该函数在board/samsung/mini2440/nand_read.c中定义。
NAND Flash根据page大小可分为2种： 512B/page和2048B/page的。这两种NAND Flash的读操作是不同的。因此就需要U-Boot识别到NAND Flash的类型，然后采用相应的读操作，也就是说nand_read_ll函数要能自动适应两种NAND Flash。
参考S3C2440的数据手册可以知道：根据NFCONF寄存器的Bit3（AdvFlash (Read only)）和Bit2 （PageSize (Read only)）可以判断NAND Flash的类型。Bit2、Bit3与NAND Flash的block类型的关系如下表所示：
表 2.4 NFCONF的Bit3、Bit2与NAND Flash的关系
| Bit2 Bit3 | 0 | 1 |
| 0 | 256 B/page | 512 B/page |
| 1 | 1024 B/page | 2048 B/page |
由于的NAND Flash只有512B/page和2048 B/page这两种，因此根据NFCONF寄存器的Bit3即可区分这两种NAND Flash了。
完整代码见board/samsung/mini2440/nand_read.c中的nand_read_ll函数，这里给出伪代码：
int nand_read_ll(unsigned char *buf, unsigned long start_addr, int size)
{
//根据NFCONF寄存器的Bit3来区分2种NAND Flash
if( NFCONF & 0x8 ) /* Bit是1，表示是2KB/page的NAND Flash */
{
读取2K block 的NAND Flash
}
else /* Bit是0，表示是512B/page的NAND Flash */
{
/
读取512B block 的NAND Flash
/
}
return 0;
}
（10）设置堆栈
/* 设置堆栈*/
stack_setup:
ldr r0, _TEXT_BASE /* upper 128 KiB: relocated uboot */
sub r0, r0, #CONFIG_SYS_MALLOC_LEN /* malloc area */
sub r0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* 跳过全局数据区 */
#ifdef CONFIG_USE_IRQ
sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)
#endif
sub sp, r0, #12 /* leave 3 words for abort-stack */
只要将sp指针指向一段没有被使用的内存就完成栈的设置了。根据上面的代码可以知道U-Boot内存使用情况了，如下图所示：
图2.2 U-Boot内存使用情况
（11）清除BSS段
clear_bss:
ldr r0, _bss_start /* BSS段开始地址，在u-boot.lds中指定*/
ldr r1, _bss_end /* BSS段结束地址，在u-boot.lds中指定*/
mov r2, #0x00000000
clbss_l:str r2, [r0] /* 将bss段清零*/
add r0, r0, #4
cmp r0, r1
ble clbss_l
初始值为0，无初始值的全局变量，静态变量将自动被放在BSS段。应该将这些变量的初始值赋为0，否则这些变量的初始值将是一个随机的值，若有些程序直接使用这些没有初始化的变量将引起未知的后果。
（12）跳转到第二阶段代码入口
ldr pc, _start_armboot
_start_armboot: .word start_armboot
跳转到第二阶段代码入口start_armboot处。
1.1.2 U-Boot启动第二阶段代码分析
start_armboot函数在lib_arm/board.c中定义，是U-Boot第二阶段代码的入口。U-Boot启动第二阶段流程如下：
图 2.3 U-Boot第二阶段执行流程
在分析start_armboot函数前先来看看一些重要的数据结构：
（1）gd_t结构体
U-Boot使用了一个结构体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; /* serial_init() was called */
unsigned long env_addr; /* Address of Environment struct */
unsigned long env_valid; /* Checksum of Environment valid? */
unsigned long fb_base; /* base address of frame buffer */
void **jt; /* jump table */
} gd_t;
U-Boot使用了一个存储在寄存器中的指针gd来记录全局数据区的地址：
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")
DECLARE_GLOBAL_DATA_PTR定义一个gd_t全局数据结构的指针，这个指针存放在指定的寄存器r8中。这个声明也避免编译器把r8分配给其它的变量。任何想要访问全局数据区的代码，只要代码开头加入“DECLARE_GLOBAL_DATA_PTR”一行代码，然后就可以使用gd指针来访问全局数据区了。
根据U-Boot内存使用图中可以计算gd的值：
gd = TEXT_BASE －CONFIG_SYS_MALLOC_LEN － sizeof(gd_t)
（2）bd_t结构体
bd_t在include/asm-arm.u/u-boot.h中定义如下：
typedef struct bd_info {
int bi_baudrate; /*串口通讯波特率 */
unsigned long bi_ip_addr; /* IP 地址*/
struct environment_s *bi_env; /*环境变量开始地址 */
ulong bi_arch_number; /* 开发板的机器码 */
ulong bi_boot_params; /* 内核参数的开始地址 */
struct /* RAM配置信息 */
{
ulong start;
ulong size;
}bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
U-Boot启动内核时要给内核传递参数，这时就要使用gd_t，bd_t结构体中的信息来设置标记列表。
（3）init_sequence数组
U-Boot使用一个数组init_sequence来存储对于大多数开发板都要执行的初始化函数的函数指针。init_sequence数组中有较多的编译选项，去掉编译选项后init_sequence数组如下所示：
typedef int (init_fnc_t) (void);
init_fnc_t *init_sequence[] = {
board_init, /*开发板相关的配置--board/samsung/mini2440/mini2440.c */
timer_init, /* 时钟初始化-- cpu/arm920t/s3c24x0/timer.c */
env_init, /*初始化环境变量--common/env_flash.c 或common/env_nand.c*/
init_baudrate, /*初始化波特率-- lib_arm/board.c */
serial_init, /* 串口初始化-- drivers/serial/serial_s3c24x0.c */
console_init_f, /* 控制通讯台初始化阶段1-- common/console.c */
display_banner, /*打印U-Boot版本、编译的时间-- gedit lib_arm/board.c */
dram_init, /*配置可用的RAM-- board/samsung/mini2440/mini2440.c */
display_dram_config, /* 显示RAM大小-- lib_arm/board.c */
NULL,
};
其中的board_init函数在board/samsung/mini2440/mini2440.c中定义，该函数设置了MPLLCOM，UPLLCON，以及一些GPIO寄存器的值，还设置了U-Boot机器码和内核启动参数地址 ：
/* MINI2440开发板的机器码 */
gd->bd->bi_arch_number = MACH_TYPE_MINI2440;
/* 内核启动参数地址 */
gd->bd->bi_boot_params = 0x30000100;
其中的dram_init函数在board/samsung/mini2440/mini2440.c中定义如下：
int dram_init (void)
{
/* 由于mini2440只有 */
gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
return 0;
}
mini2440使用2片32MB的SDRAM组成了64MB的内存，接在存储控制器的BANK6，地址空间是0x30000000~0x34000000。
在include/configs/mini2440.h中PHYS_SDRAM_1和PHYS_SDRAM_1_SIZE 分别被定义为0x30000000和0x04000000（64M）。
分析完上述的数据结构，下面来分析start_armboot函数：
void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
… …
/*计算全局数据结构的地址gd */
gd = (gd_t*)(_armboot_start - CONFIG_SYS_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));
gd->flags |= GD_FLG_RELOC;
monitor_flash_len = _bss_start - _armboot_start;
/* 逐个调用init_sequence数组中的初始化函数 */
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) {
hang ();
}
}
/* armboot_start 在cpu/arm920t/start.S 中被初始化为u-boot.lds连接脚本中的_start */
mem_malloc_init (_armboot_start - CONFIG_SYS_MALLOC_LEN,
CONFIG_SYS_MALLOC_LEN);
/* NOR Flash初始化 */
#ifndef CONFIG_SYS_NO_FLASH
/* configure available FLASH banks */
display_flash_config (flash_init ());
#endif /* CONFIG_SYS_NO_FLASH */
… …
/* NAND Flash 初始化*/
#if defined(CONFIG_CMD_NAND)
puts ("NAND: ");
nand_init(); /* go init the NAND */
#endif
… …
/*配置环境变量，重新定位 */
env_relocate ();
… …
/*从环境变量中获取IP地址 */
gd->bd->bi_ip_addr = getenv_IPaddr ("ipaddr");
stdio_init (); /* get the devices list going. */
jumptable_init ();
… …
console_init_r (); /* fully init console as a device */
… …
/*enable exceptions */
enable_interrupts ();
#ifdef CONFIG_USB_DEVICE
usb_init_slave();
#endif
/* Initialize from environment */
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
… …
/*网卡初始化 */
#if defined(CONFIG_CMD_NET)
#if defined(CONFIG_NET_MULTI)
puts ("Net: ");
#endif
eth_initialize(gd->bd);
… …
#endif
/* main_loop() can return to retry autoboot, if so just run it again. */
for (;;) {
main_loop ();
}
/* NOTREACHED - no way out of command loop except booting */
}
main_loop函数在common/main.c中定义。一般情况下，进入main_loop函数若干秒内没有
1.1.3 U-Boot启动Linux过程
U-Boot使用标记列表（tagged list）的方式向Linux传递参数。标记的数据结构式是tag，在U-Boot源代码目录include/asm-arm/setup.h中定义如下：
struct tag_header {
u32 size; /* 表示tag数据结构的联合u实质存放的数据的大小*/
u32 tag; /* 表示标记的类型 */
};
struct tag {
struct tag_header hdr;
union {
struct tag_core core;
struct tag_mem32 mem;
struct tag_videotext videotext;
struct tag_ramdisk ramdisk;
struct tag_initrd initrd;
struct tag_serialnr serialnr;
struct tag_revision revision;
struct tag_videolfb videolfb;
struct tag_cmdline cmdline;
/*
* Acorn specific
*/
struct tag_acorn acorn;
/*
* DC21285 specific
*/
struct tag_memclk memclk;
} u;
};
U-Boot使用命令bootm来启动已经加载到内存中的内核。而bootm命令实际上调用的是do_bootm函数。对于Linux内核，do_bootm函数会调用do_bootm_linux函数来设置标记列表和启动内核。do_bootm_linux函数在lib_arm/bootm.c 中定义如下：
59 int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images)
60 {
61 bd_t *bd = gd->bd;
62 char *s;
63 int machid = bd->bi_arch_number;
64 void (*theKernel)(int zero, int arch, uint params);
65
66 #ifdef CONFIG_CMDLINE_TAG
67 char *commandline = getenv ("bootargs"); /* U-Boot环境变量bootargs */
68 #endif
… …
73 theKernel = (void (*)(int, int, uint))images->ep; /* 获取内核入口地址 */
… …
86 #if defined (CONFIG_SETUP_MEMORY_TAGS) || \
87 defined (CONFIG_CMDLINE_TAG) || \
88 defined (CONFIG_INITRD_TAG) || \
89 defined (CONFIG_SERIAL_TAG) || \
90 defined (CONFIG_REVISION_TAG) || \
91 defined (CONFIG_LCD) || \
92 defined (CONFIG_VFD)
93 setup_start_tag (bd); /* 设置ATAG_CORE标志 */
… …
100 #ifdef CONFIG_SETUP_MEMORY_TAGS
101 setup_memory_tags (bd); /* 设置内存标记 */
102 #endif
103 #ifdef CONFIG_CMDLINE_TAG
104 setup_commandline_tag (bd, commandline); /* 设置命令行标记 */
105 #endif
… …
113 setup_end_tag (bd); /* 设置ATAG_NONE标志 */
114 #endif
115
116 /* we assume that the kernel is in place */
117 printf ("\nStarting kernel ...\n\n");
… …
126 cleanup_before_linux (); /* 启动内核前对CPU作最后的设置 */
127
128 theKernel (0, machid, bd->bi_boot_params); /* 调用内核 */
129 /* does not return */
130
131 return 1;
132 }
其中的setup_start_tag，setup_memory_tags，setup_end_tag函数在lib_arm/bootm.c中定义如下：
（1）setup_start_tag函数
static void setup_start_tag (bd_t *bd)
{
params = (struct tag *) bd->bi_boot_params; /* 内核的参数的开始地址 */
params->hdr.tag = ATAG_CORE;
params->hdr.size = tag_size (tag_core);
params->u.core.flags = 0;
params->u.core.pagesize = 0;
params->u.core.rootdev = 0;
params = tag_next (params);
}
标记列表必须以ATAG_CORE开始，setup_start_tag函数在内核的参数的开始地址设置了一个ATAG_CORE标记。
（2）setup_memory_tags函数
static void setup_memory_tags (bd_t *bd)
{
int i;
/*设置一个内存标记 */
for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
params->hdr.tag = ATAG_MEM;
params->hdr.size = tag_size (tag_mem32);
params->u.mem.start = bd->bi_dram[i].start;
params->u.mem.size = bd->bi_dram[i].size;
params = tag_next (params);
}
}
setup_memory_tags函数设置了一个ATAG_MEM标记，该标记包含内存起始地址，内存大小这两个参数。
（3）setup_end_tag函数
static void setup_end_tag (bd_t *bd)
{
params->hdr.tag = ATAG_NONE;
params->hdr.size = 0;
}
标记列表必须以标记ATAG_NONE结束，setup_end_tag函数设置了一个ATAG_NONE标记，表示标记列表的结束。
U-Boot设置好标记列表后就要调用内核了。但调用内核前，CPU必须满足下面的条件：
（1） CPU寄存器的设置
Ø r0=0
Ø r1=机器码
Ø r2=内核参数标记列表在RAM中的起始地址
（2） CPU工作模式
Ø 禁止IRQ与FIQ中断
Ø CPU为SVC模式
（3） 使数据Cache与指令Cache失效
do_bootm_linux中调用的cleanup_before_linux函数完成了禁止中断和使Cache失效的功能。cleanup_before_linux函数在cpu/arm920t/cpu.中定义：
int cleanup_before_linux (void)
{
/*
* this function is called just before we call linux
* it prepares the processor for linux
*
* we turn off caches etc ...
*/
disable_interrupts (); /* 禁止FIQ/IRQ中断 */
/*turn off I/D-cache */
icache_disable(); /* 使指令Cache失效 */
dcache_disable(); /* 使数据Cache失效 */
/*flush I/D-cache */
cache_flush(); /* 刷新Cache */
return 0;
}
由于U-Boot启动以来就一直工作在SVC模式，因此CPU的工作模式就无需设置了。
do_bootm_linux中：
64 void (*theKernel)(int zero, int arch, uint params);
… …
73 theKernel = (void (*)(int, int, uint))images->ep;
… …
128 theKernel (0, machid, bd->bi_boot_params);
第73行代码将内核的入口地址“images->ep”强制类型转换为函数指针。根据ATPCS规则，函数的参数个数不超过4个时，使用r0~r3这4个寄存器来传递参数。因此第128行的函数调用则会将0放入r0，机器码machid放入r1，内核参数地址bd->bi_boot_params放入r2，从而完成了寄存器的设置，最后转到内核的入口地址。
到这里，U-Boot的工作就结束了，系统跳转到Linux内核代码执行。
1.1.4 U-Boot添加命令的方法及U-Boot命令执行过程
下面以添加menu命令（启动菜单）为例讲解U-Boot添加命令的方法。
（1） 建立common/cmd_menu.c
习惯上通用命令源代码放在common目录下，与开发板专有命令源代码则放在board/<board_dir>目录下，并且习惯以“cmd_<命令名>.c”为文件名。
（2） 定义“menu”命令
在cmd_menu.c中使用如下的代码定义“menu”命令：
_BOOT_CMD(
menu, 3, 0, do_menu,
"menu- display a menu, to select the items to do something\n",
"- display a menu, to select the items to do something"
);
其中U_BOOT_CMD命令格式如下：
U_BOOT_CMD(name,maxargs,rep,cmd,usage,help)
各个参数的意义如下：
name：命令名，非字符串，但在U_BOOT_CMD中用“#”符号转化为字符串
maxargs：命令的最大参数个数
rep：是否自动重复（按Enter键是否会重复执行）
cmd：该命令对应的响应函数
usage：简短的使用说明（字符串）
help：较详细的使用说明（字符串）
在内存中保存命令的help字段会占用一定的内存，通过配置U-Boot可以选择是否保存help字段。若在include/configs/mini2440.h中定义了CONFIG_SYS_LONGHELP宏，则在U-Boot中使用help命令查看某个命令的帮助信息时将显示usage和help字段的内容，否则就只显示usage字段的内容。
U_BOOT_CMD宏在include/command.h中定义：
#define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) \
cmd_tbl_t __u_boot_cmd_##name Struct_Section = {#name, maxargs, rep, cmd, usage, help}
“##”与“#”都是预编译操作符，“##”有字符串连接的功能，“#”表示后面紧接着的是一个字符串。
其中的cmd_tbl_t在include/command.h中定义如下：
struct cmd_tbl_s {
char *name; /* 命令名 */
int maxargs; /* 最大参数个数 */
int repeatable; /* 是否自动重复 */
int (*cmd)(struct cmd_tbl_s *, int, int, char *[]); /* 响应函数 */
char *usage; /* 简短的帮助信息 */
#ifdef CONFIG_SYS_LONGHELP
char *help; /* 较详细的帮助信息 */
#endif
#ifdef CONFIG_AUTO_COMPLETE
/*自动补全参数 */
int (*complete)(int argc, char *argv[], char last_char, int maxv, char *cmdv[]);
#endif
};
typedef struct cmd_tbl_s cmd_tbl_t;
一个cmd_tbl_t结构体变量包含了调用一条命令的所需要的信息。
其中Struct_Section在include/command.h中定义如下：
#define Struct_Section __attribute__ ((unused,section (".u_boot_cmd")))
凡是带有__attribute__ ((unused,section (".u_boot_cmd"))属性声明的变量都将被存放在".u_boot_cmd"段中，并且即使该变量没有在代码中显式的使用编译器也不产生警告信息。
在U-Boot连接脚本u-boot.lds中定义了".u_boot_cmd"段：
. = .;
__u_boot_cmd_start = .; /*将 __u_boot_cmd_start指定为当前地址 */
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .; /* 将__u_boot_cmd_end指定为当前地址 */
这表明带有“.u_boot_cmd”声明的函数或变量将存储在“u_boot_cmd”段。这样只要将U-Boot所有命令对应的cmd_tbl_t变量加上“.u_boot_cmd”声明，编译器就会自动将其放在“u_boot_cmd”段，查找cmd_tbl_t变量时只要在__u_boot_cmd_start与__u_boot_cmd_end之间查找就可以了。
因此“menu”命令的定义经过宏展开后如下：
cmd_tbl_t __u_boot_cmd_menu __attribute__ ((unused,section (".u_boot_cmd"))) = {menu, 3, 0, do_menu, "menu- display a menu, to select the items to do something\n", " - display a menu, to select the items to do something"}
实质上就是用U_BOOT_CMD宏定义的信息构造了一个cmd_tbl_t类型的结构体。编译器将该结构体放在“u_boot_cmd”段，执行命令时就可以在“u_boot_cmd”段查找到对应的cmd_tbl_t类型结构体。
（3） 实现命令的函数
在cmd_menu.c中添加“menu”命令的响应函数的实现。具体的实现代码略：
int do_menu (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
/*实现代码略 */
}
（4） 将common/cmd_menu.c编译进u-boot.bin
在common/Makefile中加入如下代码：
COBJS-$(CONFIG_BOOT_MENU) += cmd_menu.o
在include/configs/mini2440.h加入如代码：
#define CONFIG_BOOT_MENU 1
重新编译下载U-Boot就可以使用menu命令了
（5）menu命令执行的过程
在U-Boot中输入“menu”命令执行时，U-Boot接收输入的字符串“menu”，传递给run_command函数。run_command函数调用common/command.c中实现的find_cmd函数在__u_boot_cmd_start与__u_boot_cmd_end间查找命令，并返回menu命令的cmd_tbl_t结构。然后run_command函数使用返回的cmd_tbl_t结构中的函数指针调用menu命令的响应函数do_menu，从而完成了命令的执行。
作者：heaad
http://www.cnblogs.com/heaad/
2.1.1 U-Boot编译命令
对于mini2440开发板，编译U-Boot需要执行如下的命令：
$ make mini2440_config
$ make all
使用上面的命令编译U-Boot，编译生成的所有文件都保存在源代码目录中。为了保持源代码目录的干净，可以使用如下命令将编译生成的文件输出到一个外部目录，而不是在源代码目录中，下面的2种方法都将编译生成的文件输出到 /tmp/build目录：
$ export BUILD_DIR=/tmp/build
$ make mini2440_config
$ make all
或
$ make O=/tmp/build mini2440_config （注意是字母O，而不是数字0）
$ make all
为了简化分析过程，方便读者理解，这里主要针对第一种编译方式（目标输出到源代码所在目录）进行分析。
2.1.2 U-Boot配置、编译、连接过程
U-Boot开头有一些跟主机软硬件环境相关的代码，在每次执行make命令时这些代码都被执行一次。
1. U-Boot配置过程
（1）定义主机系统架构
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/)
“sed –e”表示后面跟的是一串命令脚本，而表达式“s/abc/def/”表示要从标准输入中，查找到内容为“abc”的，然后替换成“def”。其中“abc”表达式用可以使用“.”作为通配符。
命令“uname –m”将输出主机CPU的体系架构类型。作者的电脑使用Intel Core2系列的CPU，因此“uname–m”输出“i686”。“i686”可以匹配命令“sed -e s/i.86/i386/”中的“i.86”，因此在作者的机器上执行Makefile，HOSTARCH将被设置成“i386” 。
（2）定义主机操作系统类型
HOSTOS := $(shell uname -s | tr '[:upper:]' '[:lower:]' | \
sed -e 's/\(cygwin\).*/cygwin/')
“uname –s”输出主机内核名字，作者使用Linux发行版Ubuntu9.10，因此“uname –s”结果是“Linux”。“tr '[:upper:]' '[:lower:]'”作用是将标准输入中的所有大写字母转换为响应的小写字母。因此执行结果是将HOSTOS设置为“linux”。
（3）定义执行shell脚本的shell
# Set shell to bash if possible, otherwise fall back to sh
SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
else if [ -x /bin/bash ]; then echo /bin/bash; \
else echo sh; fi; fi)
"$$BASH"的作用实质上是生成了字符串“$BASH”（前一个$号的作用是指明第二个$是普通的字符）。若执行当前Makefile的shell中定义了“$BASH”环境变量，且文件“$BASH”是可执行文件，则SHELL的值为“$BASH”。否则，若“/bin/bash”是可执行文件，则SHELL值为“/bin/bash”。若以上两条都不成立，则将“sh”赋值给SHELL变量。
由于作者的机器安装了bash shell，且shell默认环境变量中定义了“$BASH”，因此SHELL 被设置为$BASH 。
（4）设定编译输出目录
ifdef O
ifeq ("$(origin O)", "command line")
BUILD_DIR := $(O)
endif
endif
函数$( origin, variable) 输出的结果是一个字符串，输出结果由变量variable定义的方式决定，若variable在命令行中定义过，则origin函数返回值为"command line"。假若在命令行中执行了“export BUILD_DIR=/tmp/build”的命令，则“$(origin O)”值为“command line”，而BUILD_DIR被设置为“/tmp/build”。
ifneq ($(BUILD_DIR),)
saved-output := $(BUILD_DIR)
# Attempt to create a output directory.
$(shell [ -d ${BUILD_DIR} ] || mkdir -p ${BUILD_DIR})
若${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),)
若$(BUILD_DIR)为空，则将其赋值为当前目录路径（源代码目录）。并检查$(BUILD_DIR)目录是否存在。
OBJTREE := $(if $(BUILD_DIR),$(BUILD_DIR),$(CURDIR))
SRCTREE := $(CURDIR)
TOPDIR := $(SRCTREE)
LNDIR := $(OBJTREE)
… …
MKCONFIG := $(SRCTREE)/mkconfig
… …
ifneq ($(OBJTREE),$(SRCTREE))
obj := $(OBJTREE)/
src := $(SRCTREE)/
else
obj :=
src :=
endif
CURDIR变量指示Make当前的工作目录，由于当前Make在U-Boot顶层目录执行Makefile，因此CURDIR此时就是U-Boot顶层目录。
执行完上面的代码后， SRCTREE，src变量就是U-Boot代码顶层目录，而OBJTREE，obj变量就是输出目录，若没有定义BUILD_DIR环境变量，则SRCTREE，src变量与OBJTREE，obj变量都是U-Boot源代码目录。而MKCONFIG则表示U-Boot根目录下的mkconfig脚本。
2. make mini2440_config命令执行过程
下面分析命令“make mini2440_config”执行过程，为了简化分析过程这里主要分析将编译目标输出到源代码目录的情况。
mini2440_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t mini2440 samsung s3c24x0
其中的依赖“unconfig”定义如下：
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
其中“@”的作用是执行该命令时不在shell显示。“obj”变量就是编译输出的目录，因此“unconfig”的作用就是清除上次执行make *_config命令生成的配置文件（如include/config.h，include/config.mk等）。
$(MKCONFIG)在上面指定为“$(SRCTREE)/mkconfig”。$(@:_config=)为将传进来的所有参数中的_config替换为空（其中“@”指规则的目标文件名，在这里就是“mini2440_config ”。$(text:patternA=patternB)，这样的语法表示把text变量每一个元素中结尾的patternA的文本替换为patternB，然后输出） 。因此$(@:_config=)的作用就是将mini2440_config中的_config去掉，得到mini2440。
因此“@$(MKCONFIG) $(@:_config=) arm arm920t mini2440 samsung s3c24x0”实际上就是执行了如下命令：
./mkconfig mini2440 arm arm920t mini2440 samsung s3c24x0
即将“mini2440 arm arm920t mini2440 samsung s3c24x0”作为参数传递给当前目录下的mkconfig脚本执行。
在mkconfig脚本中给出了mkconfig的用法：
# Parameters: Target Architecture CPU Board [VENDOR] [SOC]
因此传递给mkconfig的参数的意义分别是：
mini2440：Target（目标板型号）
arm：Architecture （目标板的CPU架构）
arm920t：CPU （具体使用的CPU型号）
mini2440：Board
samsung：VENDOR（生产厂家名）
s3c24x0：SOC
下面再来看看mkconfig脚本到底做了什么。
（1）确定开发板名称BOARD_NAME
在mkconfig脚本中有如下代码：
APPEND=no # no表示创建新的配置文件，yes表示追加到配置文件中
BOARD_NAME="" # Name to print in make output
TARGETS=""
while [ $# -gt 0 ] ; do
case "$1" in
--) shift ; break ;;
-a) shift ; APPEND=yes ;;
-n) shift ; BOARD_NAME="${1%%_config}" ; shift ;;
-t) shift ; TARGETS="`echo $1 | sed 's:_: :g'` ${TARGETS}" ; shift ;;
*) break ;;
esac
done
[ "${BOARD_NAME}" ] || BOARD_NAME="$1"
环境变量$#表示传递给脚本的参数个数，这里的命令有6个参数，因此$#是6 。shift的作用是使$1=$2，$2=$3，$3=$4….，而原来的$1将丢失。因此while循环的作用是，依次处理传递给mkconfig脚本的选项。由于我们并没有传递给mkconfig任何的选项，因此while循环中的代码不起作用。
最后将BOARD_NAME的值设置为$1的值，在这里就是“mini2440”。
（2）检查参数合法性
[ $# -lt 4 ] && exit 1
[ $# -gt 6 ] && exit 1
if [ "${ARCH}" -a "${ARCH}" != "$2" ]; then
echo "Failed: \$ARCH=${ARCH}, should be '$2' for ${BOARD_NAME}" 1>&2
exit 1
fi
上面代码的作用是检查参数个数和参数是否正确，参数个数少于4个或多于6个都被认为是错误的。
（3）创建到目标板相关的目录的链接
#
# 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="http://www.cnblogs.com/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
若将目标文件设定为输出到源文件所在目录，则以上代码在include目录下建立了到asm-arm目录的符号链接asm。其中的ln -s asm-$2 asm即ln -s asm-arm asm 。
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
建立符号链接include/asm-arm/arch ，若$6（SOC）为空，则使其链接到include/asm-arm/arch-arm920t目录，否则就使其链接到include/asm-arm/arch-s3c24x0目录。（事实上include/asm-arm/arch-arm920t并不存在，因此$6是不能为空的，否则会编译失败）
if [ "$2" = "arm" ] ; then
rm-f asm-$2/proc
ln-s ${LNPREFIX}proc-armv asm-$2/proc
fi
若目标板是arm架构，则上面的代码将建立符号连接include/asm-arm/proc，使其链接到目录proc-armv目录。
建立以上的链接的好处：编译U-Boot时直接进入链接文件指向的目录进行编译，而不必根据不同开发板来选择不同目录。
（4）构建include/config.mk文件
#
# 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
上面代码将会把如下内容写入文件inlcude/config.mk文件：
ARCH = arm
CPU = arm920t
BOARD = mini2440
VENDOR = samsung
SOC = s3c24x0
（5）指定开发板代码所在目录
# Assign board directory to BOARDIR variable
if [ -z "$5" -o "$5" = "NULL" ] ; then
BOARDDIR=$4
else
BOARDDIR=$5/$4
fi
以上代码指定board目录下的一个目录为当前开发板专有代码的目录。若$5（VENDOR）为空则BOARDDIR设置为$4（BOARD），否则设置为$5/$4（VENDOR/BOARD）。在这里由于$5不为空，因此BOARDDIR被设置为samsung/mini2440 。
（6）构建include/config.h文件
#
# 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
for i in ${TARGETS} ; do
echo "#define CONFIG_MK_${i} 1" >>config.h ;
done
cat << EOF >> config.h
#define CONFIG_BOARDDIR board/$BOARDDIR
#include <config_defaults.h>
#include <configs/$1.h>
#include <asm/config.h>
EOF
exit 0
这里的“cat << EOF >> config.h”表示将输入的内容追加到config.h中，直到出现“EOF”这样的标识为止。
若APPEND为no，则创建新的include/config.h文件。若APPEND为yes，则将新的配置内容追加到include/config.h文件后面。由于APPEND的值保持“no”，因此config.h被创建了，并添加了如下的内容：
/* Automatically generated - do not edit */
#define CONFIG_BOARDDIR board/samsung/mini2440
#include< config_defaults.h>
#include< configs/mini2440.h>
#include< asm/config.h>
下面总结命令make mini2440_config执行的结果（仅针对编译目标输出到源代码目录的情况）：
（1） 创建到目标板相关的文件的链接
ln-s asm-arm asm
ln-s arch-s3c24x0 asm-arm/arch
ln-s proc-armv asm-arm/proc
（2） 创建include/config.mk文件，内容如下所示：
ARCH = arm
CPU = arm920t
BOARD = mini2440
VENDOR = samsung
SOC = s3c24x0
（3） 创建与目标板相关的文件include/config.h，如下所示：
/*Automatically generated - do not edit */
#define CONFIG_BOARDDIR board/samsung/mini2440
#include< config_defaults.h>
#include< configs/mini2440.h>
#include< asm/config.h>
3. make all命令执行过程
若没有执行过“make< board_name>_config”命令就直接执行“make all”命令则会出现如下的才错误信息，然后停止编译：
System not configured - see README
U-Boot是如何知道用户没有执行过“make< board_name>_config”命令的呢？阅读U-Boot源代码就可以发现了，Makefile中有如下代码：
ifeq ($(obj)include/config.mk,$(wildcard $(obj)include/config.mk)) # config.mk存在
all:
sinclude $(obj)include/autoconf.mk.dep
sinclude $(obj)include/autoconf.mk
… …
else # config.mk不存在
… …
@echo "System not configured - see README" >&2
@ exit 1
… …
endif # config.mk
若include/config.mk 文件存在，则$(wildcard $(obj)include/config.mk) 命令执行的结果是“$(obj)include/config.mk”展开的字符串，否则结果为空。由于include/config.mk是“make <board_name>_config”命令执行过程生成的，若从没有执行过“make <board_name>_config”命令则include/config.mk必然不存在。因此Make就执行else分支的代码，在输出“System not configured -see README”的信息后就返回了。
下面再来分析“make all”命令正常执行的过程，在Makefile中有如下代码：
（1）include/autoconf.mk生成过程
all:
sinclude $(obj)include/autoconf.mk.dep
sinclude $(obj)include/autoconf.mk
include/autoconf.mk文件中是与开发板相关的一些宏定义，在Makefile执行过程中需要根据某些宏来确定执行哪些操作。下面简要分析include/autoconf.mk生成的过程，include/autoconf.mk生成的规则如下：
$(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 $@
include/autoconf.mk依赖于make <board_name>_config 命令生成的include/config.h。因此执行make <board_name>_config命令后再执行make all将更新include/autoconf.mk。
编译选项“-dM”的作用是输出include/common.h中定义的所有宏。根据上面的规则，编译器提取include/common.h中定义的宏，然后输出给tools/scripts/define2mk.sed脚本处理，处理的结果就是include/autoconf.mk文件。其中tools/scripts/define2mk.sed脚本的主要完成了在include/common.h中查找和处理以“CONFIG_”开头的宏定义的功能。
include/common.h文件包含了include/config.h文件，而include/config.h文件又包含了config_defaults.h，configs/mini2440.h，asm/config.h文件。因此include/autoconf.mk实质上就是config_defaults.h，configs/mini2440.h，asm/config.h三个文件中“CONFIG_”开头的有效的宏定义的集合。
下面接着分析Makefile的执行。
# load ARCH, BOARD, and CPU configuration
include $(obj)include/config.mk
export ARCH CPU BOARD VENDOR SOC
将make mini2440_config命令生成的include/config.mk包含进来。
# 若主机架构与开发板结构相同，就使用主机的编译器，而不是交叉编译器
ifeq ($(HOSTARCH),$(ARCH))
CROSS_COMPILE ?=
endif
若主机与目标机器体系架构相同，则使用gcc编译器而不是交叉编译器。
# load other configuration
include $(TOPDIR)/config.mk
最后将U-Boot顶层目录下的config.mk文件包含进来，该文件包含了对编译的一些设置。下面对U-Boot顶层目录下的config.mk文件进行分析：
（2）config.mk文件执行过程
1设置obj与src
在U-Boot顶层目录下的config.mk文件中有如下代码：
ifneq ($(OBJTREE),$(SRCTREE))
ifeq ($(CURDIR),$(SRCTREE))
dir :=
else
dir := $(subst $(SRCTREE)/,,$(CURDIR))
endif
obj := $(if $(dir),$(OBJTREE)/$(dir)/,$(OBJTREE)/)
src := $(if $(dir),$(SRCTREE)/$(dir)/,$(SRCTREE)/)
$(shell mkdir -p $(obj))
else
obj :=
src :=
endif
由于目标输出到源代码目录下，因此执行完上面的代码后，src和obj都是空。
2设置编译选项
PLATFORM_RELFLAGS =
PLATFORM_CPPFLAGS = #编译选项
PLATFORM_LDFLAGS = #连接选项
用这3个变量表示交叉编译器的编译选项，在后面Make会检查交叉编译器支持的编译选项，然后将适当的选项添加到这3个变量中。
#
# Option checker (courtesy linux kernel) to ensure
# only supported compiler options are used
#
cc-option = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \
> /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;)
变量CC和CFLAGS在后面的代码定义为延时变量，其中的CC即arm-linux-gcc。函数cc-option用于检查编译器CC是否支持某选项。将2个选项作为参数传递给cc-option函数，该函数调用CC编译器检查参数1是否支持，若支持则函数返回参数1，否则返回参数2 （因此CC编译器必须支持参数1或参数2，若两个都不支持则会编译出错）。可以像下面这样调用cc-option函数，并将支持的选项添加到FLAGS中：
FLAGS +=$(call cc-option,option1,option2)
3指定交叉编译工具
#
# 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
对于arm开发板，其中的CROSS_COMPILE在lib_arm/config.mk文件中定义：
CROSS_COMPILE ?= arm-linux-
因此以上代码指定了使用前缀为“arm-linux-”的编译工具，即arm-linux-gcc，arm-linux-ld等等。
4包含与开发板相关的配置文件
# Load generated board configuration
sinclude $(OBJTREE)/include/autoconf.mk
ifdef ARCH
sinclude $(TOPDIR)/lib_$(ARCH)/config.mk # include architecture dependend rules
endif
$(ARCH)的值是“arm”，因此将“lib_arm/config.mk”包含进来。lib_arm/config.mk脚本指定了交叉编译器，添加了一些跟CPU架构相关的编译选项，最后还指定了cpu/arm920t/u-boot.lds为U-Boot的连接脚本。
ifdef CPU
sinclude $(TOPDIR)/cpu/$(CPU)/config.mk # include CPU specific rules
endif
$(CPU)的值是“arm920t”，因此将“cpu/arm920t/config.mk”包含进来。这个脚本主要设定了跟arm920t处理器相关的编译选项。
ifdef SOC
sinclude $(TOPDIR)/cpu/$(CPU)/$(SOC)/config.mk # include SoC specific rules
endif
$(SOC)的值是s3c24x0，因此Make程序尝试将cpu/arm920t/s3c24x0/config.mk包含进来，而这个文件并不存在，但是由于用的是“sinclude”命令，所以并不会报错。
ifdef VENDOR
BOARDDIR = $(VENDOR)/$(BOARD)
else
BOARDDIR = $(BOARD)
endif
$(BOARD)的值是mini2440，VENDOR的值是samsung，因此BOARDDIR的值是samsung/mini2440。BOARDDIR变量表示开发板特有的代码所在的目录。
ifdef BOARD
sinclude $(TOPDIR)/board/$(BOARDDIR)/config.mk # include board specific rules
endif
Make将“board/samsung/mini2440/config.mk”包含进来。该脚本只有如下的一行代码：
TEXT_BASE = 0x33F80000
U-Boot编译时将使用TEXT_BASE作为代码段连接的起始地址。
LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
ifneq ($(TEXT_BASE),)
LDFLAGS += -Ttext $(TEXT_BASE)
endif
执行完以上代码后，LDFLAGS中包含了“-Bstatic -T u-boot.lds ”和“-Ttext 0x33F80000”的字样。
5指定隐含的编译规则
# Allow boards to use custom optimize flags on a per dir/file basis
BCURDIR := $(notdir $(CURDIR))
$(obj)%.s: %.S
$(CPP) $(AFLAGS) $(AFLAGS_$(@F)) $(AFLAGS_$(BCURDIR)) -o $@ $<
$(obj)%.o: %.S
$(CC) $(AFLAGS) $(AFLAGS_$(@F)) $(AFLAGS_$(BCURDIR)) -o $@ $< -c
$(obj)%.o: %.c
$(CC) $(CFLAGS) $(CFLAGS_$(@F)) $(CFLAGS_$(BCURDIR)) -o $@ $< -c
$(obj)%.i: %.c
$(CPP) $(CFLAGS) $(CFLAGS_$(@F)) $(CFLAGS_$(BCURDIR)) -o $@ $< -c
$(obj)%.s: %.c
$(CC) $(CFLAGS) $(CFLAGS_$(@F)) $(CFLAGS_$(BCURDIR)) -o $@ $< -c -S
例如：根据以上的定义，以“.s”结尾的目标文件将根据第一条规则由同名但后缀为“.S”的源文件来生成，若不存在“.S”结尾的同名文件则根据最后一条规则由同名的“.c”文件生成。
下面回来接着分析Makefile的内容：
# U-Boot objects....order is important (i.e. start must be first)
OBJS = cpu/$(CPU)/start.o
LIBS += cpu/$(CPU)/lib$(CPU).a
ifdef SOC
LIBS += cpu/$(CPU)/$(SOC)/lib$(SOC).a
endif
ifeq ($(CPU),ixp)
LIBS += cpu/ixp/npe/libnpe.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 fs/yaffs2/libyaffs2.a \
fs/ubifs/libubifs.a
… …
LIBS += common/libcommon.a
LIBS += libfdt/libfdt.a
LIBS += api/libapi.a
LIBS += post/libpost.a
LIBS := $(addprefix $(obj),$(LIBS))
LIBS变量指明了U-Boot需要的库文件，包括平台/开发板相关的目录、通用目录下相应的库，都通过相应的子目录编译得到的。
对于mini2440开发板，以上跟平台相关的有以下几个：
cpu/$(CPU)/start.o
board/$(VENDOR)/common/lib$(VENDOR).a
cpu/$(CPU)/lib$(CPU).a
cpu/$(CPU)/$(SOC)/lib$(SOC).a
lib_$(ARCH)/lib$(ARCH).a
其余都是与平台无关的。
ifeq ($(CONFIG_NAND_U_BOOT),y)
NAND_SPL = nand_spl
U_BOOT_NAND = $(obj)u-boot-nand.bin
endif
ifeq ($(CONFIG_ONENAND_U_BOOT),y)
ONENAND_IPL = onenand_ipl
U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
endif
对于有的开发板，U-Boot支持在NAND Flash启动，这些开发板的配置文件定义了CONFIG_NAND_U_BOOT，CONFIG_ONENAND_U_BOOT。对于s3c2440，U-Boot原始代码并不支持NAND Flash启动，因此也没有定义这两个宏。
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_NAND) $(U_BOOT_ONENAND)
all: $(ALL)
其中U_BOOT_NAND与U_BOOT_ONENAND 为空，而u-boot.srec，u-boot.bin，System.map都依赖与u-boot。因此执行“make all”命令将生成u-boot，u-boot.srec，u-boot.bin，System.map 。其中u-boot是ELF文件，u-boot.srec是Motorola S-Record format文件，System.map 是U-Boot的符号表，u-boot.bin是最终烧写到开发板的二进制可执行的文件。
下面再来分析u-boot.bin文件生成的过程。ELF格式“u-boot”文件生成规则如下：
$(obj)u-boot: depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT) $(obj)u-boot.lds
$(GEN_UBOOT)
ifeq ($(CONFIG_KALLSYMS),y)
smap=`$(call SYSTEM_MAP,u-boot) | \
awk '$$2 ~ /[tTwW]/ {printf $$1 $$3 "\\\\000"}'` ; \
$(CC) $(CFLAGS) -DSYSTEM_MAP="\"$${smap}\"" \
-c common/system_map.c -o $(obj)common/system_map.o
$(GEN_UBOOT) $(obj)common/system_map.o
endif
这里生成的$(obj)u-boot目标就是ELF格式的U-Boot文件了。由于CONFIG_KALLSYMS未定义，因此ifeq ($(CONFIG_KALLSYMS),y)与endif间的代码不起作用。
其中depend，$(SUBDIRS)，$(OBJS)，$(LIBBOARD)，$(LIBS)，$(LDSCRIPT)， $(obj)u-boot.lds是$(obj)u-boot的依赖，而$(GEN_UBOOT)编译命令。
下面分析$(obj)u-boot的各个依赖：
1依赖目标depend
# Explicitly make _depend in subdirs containing multiple targets to prevent
# parallel sub-makes creating .depend files simultaneously.
depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
for dir in $(SUBDIRS) cpu/$(CPU) $(dir $(LDSCRIPT)) ; do \
$(MAKE)-C $$dir _depend ; done
对于$(SUBDIRS)，cpu/$(CPU)，$(dir $(LDSCRIPT))中的每个元素都进入该目录执行“make _depend”，生成各个子目录的.depend文件，.depend列出每个目标文件的依赖文件。
2依赖SUBDIRS
SUBDIRS = tools \
examples/standalone \
examples/api
$(SUBDIRS): depend
$(MAKE)-C $@ all
执行tools ，examples/standalone ，examples/api目录下的Makefile。
3OBJS
OBJS的值是“cpu/arm920t/start.o”。它使用如下代码编译得到：
$(OBJS): depend
$(MAKE)-C cpu/$(CPU) $(if $(REMOTE_BUILD),$@,$(notdir $@))
以上规则表明，对于OBJS包含的每个成员，都进入cpu/$(CPU)目录（即cpu/arm920t）编译它们。
4LIBBOARD
LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
… …
$(LIBBOARD): depend $(LIBS)
$(MAKE)-C $(dir $(subst $(obj),,$@))
这里LIBBOARD的值是$(obj)board/samsung/mini2440/libmini2440.a。make执行board/samsung/mini2440/目录下的Makefile，生成libmini2440.a 。
5LIBS
LIBS变量中的每个元素使用如下的规则编译得到：
$(LIBS): depend $(SUBDIRS)
$(MAKE)-C $(dir $(subst $(obj),,$@))
上面的规则表明，对于LIBS中的每个成员，都进入相应的子目录执行“make”命令编译它们。例如对于LIBS中的“common/libcommon.a”成员，程序将进入common目录执行Makefile，生成libcommon.a 。
6LDSCRIPT
LDSCRIPT := $(SRCTREE)/cpu/$(CPU)/u-boot.lds
… …
$(LDSCRIPT): depend
$(MAKE)-C $(dir $@) $(notdir $@)
“$(MAKE) -C $(dir $@) $(notdir $@)”命令经过变量替换后就是“make-C cpu/arm920t/ u-boot.lds”。也就是转到cpu/arm920t/目录下，执行“make u-boot.lds”命令。
7$(obj)u-boot.lds
$(obj)u-boot.lds: $(LDSCRIPT)
$(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@
以上执行结果实质上是将cpu/arm920t/u-boot.lds经编译器简单预处理后输出到U-Boot顶层目录下的u-boot.lds文件。其中的cpu/arm920t/u-boot.lds文件内容如下：
/* 输出为ELF文件，小端方式， */
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
. = 0x00000000;
. = ALIGN(4);
.text :
{
/* cpu/arm920t/start.o放在最前面，保证最先执行的是start.o */
cpu/arm920t/start.o (.text)
/*以下2个文件必须放在前4K，因此也放在前面，其中board/samsung/mini2440/lowlevel_init.o包含内存初始化所需代码，而board/samsung/mini2440/nand_read.o 包含U-Boot从NAND Flash搬运自身的代码 */
board/samsung/mini2440/lowlevel_init.o (.text)
board/samsung/mini2440/nand_read.o (.text)
/* 其他文件的代码段 */
*(.text)
}
/* 只读数据段 */
. = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
/* 代码段 */
. = ALIGN(4);
.data : { *(.data) }
/* u-boot自定义的got段 */
. = ALIGN(4);
.got : { *(.got) }
. = .;
__u_boot_cmd_start = .; /*将 __u_boot_cmd_start指定为当前地址 */
.u_boot_cmd : { *(.u_boot_cmd) } /* 存放所有U-Boot命令对应的cmd_tbl_t结构体 */
__u_boot_cmd_end = .; /* 将__u_boot_cmd_end指定为当前地址 */
/* bss段 */
. = ALIGN(4);
__bss_start = .;
.bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
_end = .; /* 将_end指定为当前地址 */
}
u-boot.lds实质上是U-Boot连接脚本。对于生成的U-Boot编译生成的“u-boot”文件，可以使用objdump命令可以查看它的分段信息：
$ objdump -x u-boot | more
部分输出信息如下：
u-boot: file format elf32-little
u-boot
architecture: UNKNOWN!, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x33f80000
Program Header:
LOAD off 0x00008000 vaddr 0x33f80000 paddr 0x33f80000 align 2**15
filesz 0x0002f99c memsz 0x00072c94 flags rwx
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rwx
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00024f50 33f80000 33f80000 00008000 2**5
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rodata 00008b78 33fa4f50 33fa4f50 0002cf50 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 00001964 33fadac8 33fadac8 00035ac8 2**2
CONTENTS, ALLOC, LOAD, DATA
3 .u_boot_cmd 00000570 33faf42c 33faf42c 0003742c 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .bss 00043294 33fafa00 33fafa00 0003799c 2**8
ALLOC
… …
u-boot.lds还跟U-Boot启动阶段复制代码到RAM空间的过程以及U-Boot命令执行过程密切相关，具体请结合U-Boot源代码理解。
编译命令GEN_UBOOT
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) $$UNDEF_SYM $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
以上命令使用$(LDFLAGS)作为连接脚本，最终生成“u-boot”文件。
u-boot.bin文件生成过程
生成u-boot.bin文件的规则如下：
$(obj)u-boot.bin: $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
从U-Boot编译输出信息中可以知道上面的命令实质上展开为：
arm-linux-objcopy--gap-fill=0xff -O binary u-boot u-boot.bin
编译命令中的“-O binary”选项指定了输出的文件为二进制文件。而“--gap-fill=0xff”选项指定使用“0xff”填充段与段间的空闲区域。这条编译命令实现了ELF格式的U-Boot文件到BIN格式的转换。
System.map文件的生成
System.map是U-Boot的符号表，它包含了U-Boot的全局变量和函数的地址信息。将System.map生成的规则如下：
SYSTEM_MAP = \
$(NM) $1 | \
grep-v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | \
LC_ALL=C sort
$(obj)System.map: $(obj)u-boot
@$(call SYSTEM_MAP,$<) > $(obj)System.map
arm-linux-nm u-boot | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | LC_ALL=C sort > System.map
也就是将arm-linux-nm命令查看u-boot的输出信息经过过滤和排序后输出到System.map。为了了解System.map文件的作用，打开System.map：
33f80000 T _start
33f80020 t _undefined_instruction
33f80024 t _software_interrupt
33f80028 t _prefetch_abort
33f8002c t _data_abort
33f80030 t _not_used
33f80034 t _irq
33f80038 t _fiq
33f80040 t _TEXT_BASE
33f80044 T _armboot_start
33f80048 T _bss_start
33f8004c T _bss_end
… …
System.map表示的是地址标号到该标号表示的地址的一个映射关系。System.map每一行的格式都是“addr type name”，addr是标号对应的地址值，name是标号名，type表示标号的类型。
U-Boot的编译和运行并不一定要生成System.map，这个文件主要是提供给用户或外部程序调试时使用的。
作者：heaad
582
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
