轉載自http://blog.csdn.net/qiaoliang328/article/details/5891913
u-boot.lds文件詮釋
網上大部分u-boot.lds文件的分析大部分都是千遍一律，例如下面就是本人在網上找到的關於u-boot.lds的資料。
OUTPUT_FORMAT("elf32-littlearm","elf32-littlearm","elf32-littlearm")
/*指定輸出可執行文件是elf格式,32位ARM指令,小端*/
OUTPUT_ARCH(arm)
/*指定輸出可執行文件的平臺爲ARM*/
ENTRY(_start)
/*指定輸出可執行文件的起始代碼段爲_start*/
SECTIONS
{
/*指定可執行image文件的全局入口點，通常這個地址都放在ROM(flash)0x0位置。必須使編譯器知道這個地址，通常都是修改此處來完成*/
.= 0x00000000;/*;從0x0位置開始*/
.= ALIGN(4);/*代碼以4字節對齊*/
.text
:
{
cpu/arm920t/start.o
(.text)
/*代碼的第一個代碼部分*/
*(.text)
/*下面依次爲各個text段函數*/
}
.= ALIGN(4);
/*代碼以4字節對齊*/
.rodata
:{*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))}
/*指定只讀數據段*/
.= ALIGN(4);
/*代碼以4字節對齊*/
.data
:{*(.data)}
.= ALIGN(4);
/*代碼以4字節對齊*/
.got
:{*(.got)}
/*指定got段, got段是uboot自定義的一個段,
非標準段*/
.=.;
__u_boot_cmd_start =.;
/*把__u_boot_cmd_start賦值爲當前位置,
即起始位置*/
.u_boot_cmd
:{*(.u_boot_cmd)}
/*指定u_boot_cmd段, uboot把所有的uboot命令放在該段.*/
__u_boot_cmd_end =.;
/*把__u_boot_cmd_end賦值爲當前位置,即結束位置*/
.= ALIGN(4);
/*代碼以4字節對齊*/
__bss_start =.;
/*把__bss_start賦值爲當前位置,即bss段的開始位置*/
.bss
(NOLOAD):{*(.bss).=
ALIGN(4);}
/*指定bss段,告訴加載器不要加載這個段*/
__bss_end =.;
/*把_end賦值爲當前位置,即bss段的結束位置*/
}
看完上面的解析思路本來應該是很清晰的，於是乎編譯u-boot，查看一下System.map,
30100000 T _start
30100020 t _undefined_instruction
30100024 t _software_interrupt
30100028 t _prefetch_abort
3010002c t _data_abort
30100030 t _not_used
30100034 t _irq
30100038 t _fiq
發現 _start 的鏈接地址不是u-boot.lds中.text 的當前地址0x00000000，而是0x30100000，這就產生很多疑問了：
(1) 爲什麼u-boot.lds指定的 .text 的首地址不起作用？
(2) 0x30100000是什麼地址，由誰指定.text的首地址是0x30100000的呢？
(3) 假如有其他動作改變了 .text 的首地址，那麼該動作跟u-boot.lds的優先級又是怎麼決定的呢？
其實這三個問題都在Makefile的LDFLAGS 變量和u-boot.lds 中找到答案。我們不妨試着修改一下u-boot.lds，把u-boot.lds修改成如下(紅色字體部分爲修改過部分)：
OUTPUT_FORMAT("elf32-littlearm","elf32-littlearm","elf32-littlearm")
/*指定輸出可執行文件是elf格式,32位ARM指令,小端*/
OUTPUT_ARCH(arm)
/*指定輸出可執行文件的平臺爲ARM*/
ENTRY(_start)
/*指定輸出可執行文件的起始代碼段爲_start*/
SECTIONS
{
/*指定可執行image文件的全局入口點，通常這個地址都放在ROM(flash)0x0位置。必須使編譯器知道這個地址，通常都是修改此處來完成*/
.= 0x30000000;/*;從0x0位置開始*/
.= ALIGN(4);/*代碼以4字節對齊*/
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
.= ALIGN(4);
/*代碼以4字節對齊*/
.text :
{
cpu/arm920t/start.o (.text)
/*代碼的第一個代碼部分*/
*(.text)
/*下面依次爲各個text段函數*/
}
/*指定只讀數據段*/
.= ALIGN(4);
/*代碼以4字節對齊*/
.data
:{*(.data)}
.= ALIGN(4);
/*代碼以4字節對齊*/
.got
:{*(.got)}
/*指定got段, got段是uboot自定義的一個段,
非標準段*/
.=.;
__u_boot_cmd_start =.;
/*把__u_boot_cmd_start賦值爲當前位置,
即起始位置*/
.u_boot_cmd
:{*(.u_boot_cmd)}
/*指定u_boot_cmd段, uboot把所有的uboot命令放在該段.*/
__u_boot_cmd_end =.;
/*把__u_boot_cmd_end賦值爲當前位置,即結束位置*/
.= ALIGN(4);
/*代碼以4字節對齊*/
__bss_start =.;
/*把__bss_start賦值爲當前位置,即bss段的開始位置*/
.bss
(NOLOAD):{*(.bss).=
ALIGN(4);}
/*指定bss段,告訴加載器不要加載這個段*/
__bss_end =.;
/*把_end賦值爲當前位置,即bss段的結束位置*/
}
上面對u-boot.lds主要做了兩點修改
(1) 把0x00000000 改成 0x30000000。
(2) 把 .text 和 .rodata 存放的地址調換了位置。
重新編譯 u-boot, 查看System.map
30000000 R version_string
30000028 r C.27.2365
.
.
.
30100000 T _start
30100020 t _undefined_instruction
.
.
.
從上面的System.map部分內容可以看出:
(1) u-boot.lds設定的地址(0x00000000或0x30000000)是有效的。
(2) .text的地址仍然是30100000
跟着我們查看Makefile中的LDFLAGS變量，發現一條指令
LDFLAGS += -Ttext $(TEXT_BASE) 其中TEXT_BASE 是在u-boot根目錄的board文件夾的對應的開發板名字的子目錄下的config.mk文件中定義的
TEXT_BASE = 0x30100000
看到這裏我們應該明白爲什麼_start，也就是.text的首地址總是等於0x30100000了，在連接的時候ld命令會把參數-Ttext指定的地址賦給.text,所以.text在u-boot.lds中的默認地址(當前地址)不起作用了。
