文字来源：http://wenku.baidu.com/view/59d98bd149649b6648d74758.html
我的后期整理：
在工作时使用的blackfin-533系列的DSP，修改Analog移植好的uboot是，编译老出错。加之我是从中途接手的这个项目。搞的我实在头晕。于是想下决心好好理解一下uboot，毕竟以后工作还很需要。看这相广超的视频教程慢慢啃吧。
先附上blackfin中的u-boot.lds
1 /* 2 * U-boot - u-boot.lds.S 3 * 4 * Copyright (c) 2005-2010 Analog Device Inc. 5 * 6 * (C) Copyright 2000-2004 7 * Wolfgang Denk, DENX Software Engineering, wd@denx.de. 8 * 9 * See file CREDITS for list of people who contributed to this 10 * project. 11 * 12 * This program is free software; you can redistribute it and/or 13 * modify it under the terms of the GNU General Public License as 14 * published by the Free Software Foundation; either version 2 of 15 * the License, or (at your option) any later version. 16 * 17 * This program is distributed in the hope that it will be useful, 18 * but WITHOUT ANY WARRANTY; without even the implied warranty of 19 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 20 * GNU General Public License for more details. 21 * 22 * You should have received a copy of the GNU General Public License 23 * along with this program; if not, write to the Free Software 24 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, 25 * MA 02111-1307 USA 26 */ 27 28 #include <config.h> 29 #include <asm/blackfin.h> 30 #undef ALIGN 31 #undef ENTRY 32 33 #ifndef LDS_BOARD_TEXT 34 # define LDS_BOARD_TEXT 35 #endif 36 37 /* If we don't actually load anything into L1 data, this will avoid 38 * a syntax error. If we do actually load something into L1 data, 39 * we'll get a linker memory load error (which is what we'd want). 40 * This is here in the first place so we can quickly test building 41 * for different CPU's which may lack non-cache L1 data. 42 */ 43 #ifndef L1_DATA_B_SRAM 44 # define L1_DATA_B_SRAM CONFIG_SYS_MONITOR_BASE 45 # define L1_DATA_B_SRAM_SIZE 0 46 #endif 47 48 /* The 0xC offset is so we don't clobber the tiny LDR jump block. */ 49 #ifdef CONFIG_BFIN_BOOTROM_USES_EVT1 50 # define L1_CODE_ORIGIN L1_INST_SRAM 51 #else 52 # define L1_CODE_ORIGIN L1_INST_SRAM + 0xC 53 #endif 54 55 OUTPUT_ARCH(bfin) 56 57 MEMORY 58 { 59 #if CONFIG_MEM_SIZE 60 ram : ORIGIN = CONFIG_SYS_MONITOR_BASE, LENGTH = CONFIG_SYS_MONITOR_LEN 61 # define ram_code ram 62 # define ram_data ram 63 #else 64 # define ram_code l1_code 65 # define ram_data l1_data 66 #endif 67 l1_code : ORIGIN = L1_CODE_ORIGIN, LENGTH = L1_INST_SRAM_SIZE 68 l1_data : ORIGIN = L1_DATA_B_SRAM, LENGTH = L1_DATA_B_SRAM_SIZE 69 } 70 71 ENTRY(_start) 72 SECTIONS 73 { 74 .text.pre : 75 { 76 arch/blackfin/cpu/start.o (.text .text.*) 77 78 LDS_BOARD_TEXT 79 } >ram_code 80 81 .text.init : 82 { 83 arch/blackfin/cpu/initcode.o (.text .text.*) 84 } >ram_code 85 __initcode_lma = LOADADDR(.text.init); 86 __initcode_len = SIZEOF(.text.init); 87 88 .text : 89 { 90 *(.text .text.*) 91 } >ram_code 92 93 .rodata : 94 { 95 . = ALIGN(4); 96 *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) 97 . = ALIGN(4); 98 } >ram_data 99 100 .data : 101 { 102 . = ALIGN(4); 103 *(.data .data.*) 104 *(.data1) 105 *(.sdata) 106 *(.sdata2) 107 *(.dynamic) 108 CONSTRUCTORS 109 } >ram_data 110 111 .u_boot_cmd : 112 { 113 ___u_boot_cmd_start = .; 114 *(.u_boot_cmd) 115 ___u_boot_cmd_end = .; 116 } >ram_data 117 118 .text_l1 : 119 { 120 . = ALIGN(4); 121 __stext_l1 = .; 122 *(.l1.text) 123 . = ALIGN(4); 124 __etext_l1 = .; 125 } >l1_code AT>ram_code 126 __text_l1_lma = LOADADDR(.text_l1); 127 __text_l1_len = SIZEOF(.text_l1); 128 ASSERT (__text_l1_len <= L1_INST_SRAM_SIZE, "L1 text overflow!") 129 130 .data_l1 : 131 { 132 . = ALIGN(4); 133 __sdata_l1 = .; 134 *(.l1.data) 135 *(.l1.bss) 136 . = ALIGN(4); 137 __edata_l1 = .; 138 } >l1_data AT>ram_data 139 __data_l1_lma = LOADADDR(.data_l1); 140 __data_l1_len = SIZEOF(.data_l1); 141 ASSERT (__data_l1_len <= L1_DATA_B_SRAM_SIZE, "L1 data B overflow!") 142 143 .bss : 144 { 145 . = ALIGN(4); 146 *(.sbss) *(.scommon) 147 *(.dynbss) 148 *(.bss .bss.*) 149 *(COMMON) 150 } >ram_data 151 __bss_vma = ADDR(.bss); 152 __bss_len = SIZEOF(.bss); 153 }
u-boot.lds决定了u-boot可执行映像的连接方式，以及各个段的装载地址（装载域）和执行地址（运行域）。
GNU官方网站上对.lds文件形式的完整描述：
SECTIONS {
...
secname start BLOCK(align) (NOLOAD) : AT ( ldadr )
{ contents } >region :phdr =fill
...
}
我的分析
/*
secname段名、start运行地址、AT所指为存储地址、大括号中的是段的内容。
运行地址和储存地址是有差别的，若没有AT指定存储地址则运行地址就是存储地址。
在连接目标代码时,会提到运行地址和加载地址。这两者有什么区别呢?
加载时地址就是程序放置的地址，运行地址就是程序定位的绝对地址，也即在编译连接时定位的地址。如果程序是在flash里运行,则运行地址和加载地址是相同的。如果程序是在ram里运行,但程序是存储在flash里,则运行地址指向ram,而加载地址是指向flash。代码一般是烧写在NAND里面，比如S3C2440 如果开机从NAND启动 其开始的4K代码会被COPY到2440内部的4KRAM 用于对关键硬件的初始化 这时候内部RAM被映射为0x0地址。如果从NOR启动，因为NOR支持片上运行，代码可以直接在NOR上运行 此时NOR便被映射成0x0，S3C2440 内部的4KRAM便被映射到了0x40000000处。
*/
secname和contents是必须的，前者用来命名这个段，后者用来确定代码中的什么部分放在这个段，以下是对这个描述中的一些关键字的解释。小超的视频中有涉及。
secname：段名
contents：决定哪些内容放在本段，可以是整个目标文件，也可以是目标文件中的某段（代码段、数据段等）
start：是段的重定位地址，本段连接（运行）的地址，如果代码中有位置无关指令，程序运行时这个段必须放在这个地址上。start可以用任意一种描述地址的符号来描述。
AT（ldadr）：定义本段存储（加载）的地址，如果不使用这个选项，则加载地址等于运行地址，通过这个选项可以控制各段分别保存于输出文件中不同的位置。
例：
/* nand.lds */
SECTIONS {
firtst 0x00000000 : { head.o init.o }
second 0x30000000 : AT(4096) { main.o }
}
分析：head.o放在0x00000000地址（运行地址）开始处，init.o放在head.o后面，他们的存储地址也是0x00000000，即连接和存储地址相同（因为没有AT指定）；
main.o放在4096（0x1000，是AT指定的，存储地址）开始处，但它的运行地址在0x30000000，运行之前需要从0x1000（加载地址处）复制到0x30000000（运行地址处），此过程也就需要读取 flash，把程序拷贝到相应位置才能运行。这就是存储地址和运行地址的不同，称为加载时域和运行时域，可以在.lds连接脚本文件中分别指定。
编写好的.lds文件，在用arm-linux-ld连接命令时带-Tfilename来调用执行，如
arm-linux-ld -Tnand.lds x.o y.o -o xy.o。也用-Ttext参数直接指定连接地址，如
arm-linux-ld -Ttext 0x30000000 x.o y.o -o xy.o。
既然程序有了两种地址，就涉及到一些跳转指令的区别。
ARM汇编中，常有两种跳转方法：b跳转指令、ldr指令向PC赋值。
要特别注意这两条指令的意思：
（1） b step：b跳转指令是相对跳转，依赖当前PC的值，偏移量是通过该指令本身的 bit[23:0]算出来的，这使得使用b指令的程序不依赖于要跳到的代码的位置，只看指令本身。
（2） ldr pc, =step ：该指令是一个伪指令编译后会生成以下代码：
ldr pc, 0x30008000
<0x30008000>
step是从内存中的某个位置（step）读出数据并赋给PC，同样依赖当前PC的值，但是偏移量是step的连接地址（运行时的地址），所以可以用它实现从Flash到RAM的程序跳转。
（3） 此外，有必要回味一下adr伪指令，U-boot中那段relocate代码就是通过adr实现当前程序是在RAM中还是flash中：
relocate: /* 把U-Boot重新定位到RAM */
adr r0, _start /* r0是代码的当前位置 */
/* adr伪指令，汇编器自动通过当前PC的值算出这条指令中"_start"的值，执行到_start时PC的值放到r0中：当此段在flash中执行时r0 = _start = 0；当此段在RAM中执行时_start = _TEXT_BASE(在board/smdk2410/config.mk中指定的值为0x33F80000，即u-boot在把代码拷贝到RAM中去执行的代码段的开始) */
ldr r1, _TEXT_BASE /* 测试判断是从Flash启动，还是RAM */
/* 此句执行的结果r1始终是0x33FF80000，因为此值是链接指定的 */
cmp r0, r1 /* 比较r0和r1，调试的时候不要执行重定位 */
下面是u-boot-1.3.4的u-boot.lds（/cpu/arm920t/），简单分析如下：
OUTPUT_FORMAT("elf32-littlearm" , "elf32-littlearm", "elf32-littlearm")
/* 指定输出可执行文件是elf格式,32位ARM指令,小端 */
/*OUTPUT_FORMAT("elf32-arm", "elf32-arm", "elf32-arm")*/
OUTPUT_ARCH(arm) /* 指定输出文件的平台体系是 ARM */
ENTRY(_start) /* 指定可执行映像文件的起始段的段名是_start */
SECTIONS
{
/* 指定可执行image文件的全局入口点，通常这个地址都放在ROM(flash)0x0位置。必须使编译器知道这个地址，通常都是修改此处来完成 */
. = 0x00000000; /* 起始地址为0x00000000 */
. = ALIGN(4); /* 字对齐，即就是4字节对齐 */
.text : /* 代码段 */
{
cpu/arm920t/start.o (.text) /* 代码段第一部分代码*/
board/fs2410/lowlevel_init.o (.text) /* 代码段第二部分，这段由自己添加，由于在编译连接时发现，lowlevel_init.o代码段总是被连接在4kB之后，导致start.s执行到该段代码时，总是无法找到这段代码（注明：从nandflash启动才会存在这个问题）。*/
*(.text) /*其余代码段*/
}
. = ALIGN(4);
.rodata : { *(.rodata) } /* 只读数据段 ，所有的只读数据段都放在这个位置*/
. = ALIGN(4);
.data : { *(.data) } /* 可读写数据段，所有的可读写数据段都放在这里 */
. = ALIGN(4);
.got : { *(.got) } /*指定got段, got段式是uboot自定义的一个段, 非标准段*/
. = .;
__u_boot_cmd_start = .; /*把__u_boot_cmd_start赋值为当前位置, 即起始位置*/
.u_boot_cmd : { *(.u_boot_cmd) } /* u_boot_cmd段，所有的u-boot命令相关的定义都放在这个位置，因为每个命令定义等长，所以只要以__u_boot_cmd_start为起始地址 进行查找就可以很快查找到某一个命令的定义，并依据定义的命令指针调用相应的函数进行处理用户的任务*/
__u_boot_cmd_end = .; /* u_boot_cmd段结束位置，由此可以看出，这段空间的长度并没有严格限制，用户可以添加一些u-boot的命令，最终都会在连接是存放在这个位置。*/
. = ALIGN(4);
__bss_start = .; /*把__bss_start赋值为当前位置,即bss段的开始位置*/
.bss (NOLOAD) : { *(.bss) } /*指定bss段，这里NOLOAD的意思是这段不需装载，仅在执行域中才会有这段*/
_end = .; /*把_end赋值为当前位置,即bss段的结束位置*/
} 上面start.o中的代码装载地址和运行地址都为0x00000000,但是在start.o中会有一个u-boot自拷贝及重定位过程，start.o执行到最后时，整个u-boot已经被复制到了内存的TEXT_BASE(0x33f80000)位置，开始执行下面的跳转语句：
ldr pc, _start_armboot /* 将标号_start_armboot的值传给pc，实际上是将start_armboot函数的首地址传给pc 但是此时的start_armboot应该是在内存中，因为 start_armboot一定是在4kB之后，而nand flash 4kB之后的代码是无法直接访问的，必须先读入内存。而这时候u-boot的代码已经被拷贝并重定位到内存中，所以此处加在到pc的地址应当是内存中的地址，即33f800之后的某一地址 */
_start_armboot: .word start_armboot
看这你可能还是一头雾水，你回头分析一下head.s应该就能更明白一些。
