uboot目录详解（可执行程序内部到底什么样）

对于一个程序而言，他们内部的结构、组成通常是不可见的，但是不可见并不意味着其内部是杂乱无章的排布，仅仅是众多的二进制数据拼凑而成。一份源代码生成最终的可执行文件来驱动我们的机器正常工作，中间必经的两个环节是编译和链接。编译的过程好比是厨师将菜炒好，而链接的过程好比是将菜进行摆盘，而端上桌的饭菜就是我们最终的可执行程序。

链接的具体工作由链接器完成，链接器根据链接脚本的内容，按照要求将中间件组装成最终的可执行文件。链接脚本完成的工作主要包括：

1. 输出是什么

2. 输入是什么

3. 需要哪些库以及库所在的位置

4. 内存分布地址

5. 启动代码相关内容

基于ARM的SoC U-Boot链接lds文件，主要包括：

1. 指定第一条执行的指令

2. 描述中间件的链接规则

源码经编译之后的状态是各种的.o文件，如下图所示：

各种.o文件

而每个中间.o文件都会包含TEXT、DATA、BSS部分内容：

链接的过程大致如下图所示，将每个.o文件按照下面的规则，生成一个最终的u-boot文件。

图中的TEXT、DATA、BSS段的含义分别是：

1. TEXT，存放程序代码，也就是包含编程语言逻辑部分的内容

2. DATA，存放程序中所使用到的数据

3. BSS，存放程序中所使用到的未初始化的数据

对于ARM架构的SoC而言，他们的链接脚本通常在cpu代码文件夹下，这个也很容易理解，因为链接器毕竟是和架构强相关的，每种架构第一条执行的指令、可以支持哪种启动设备等等，这些都是事先定义好的。

打开上图所示路径中的链接文件，可以发现链接文件内的代码量并不是很多，仅仅200多行，所以了解U-Boot的可执行程序的内部构成并不是什么难事。

u-boot.lds文件仅由一个SECTIONS构成，定义了.o文件各个段的最终组织方式、可执行程序的入口点、可执行程序的格式等。

上面13-1行分别定义了输出文件数据为小端、支持ARM、elf格式；

支持ARM架构；

入口符号为__start，也就是第一条执行的指令是__start，该符号执行完紧接着跳转到reset入口。

通过修改起始text段的基址，来查看lds文件如何决定执行程序内部各段的排布情况。text的基地址在顶层Makefile文件的808行使用，定义在include/configs/xxx.h中。

首先直接修改Makefile中的链接地址，如下所示：

修改完成后，查看u-boot.sym中各个段以及各符号的排布情况之后，我们发现修改成功了。

修改include/configs/xxx.h中的CONFIG_SYS_TEXT_ADDR

修改后再次编译，查看u-boot.sym

若希望U-Boot从不同的启动介质加载系统，可以采用第二种方式实现。