uboot的relocation原理详细分析

本文详细探讨了U-Boot的relocation功能,解释了为何relocation在某些情况下是必要的,尤其是对于从静态存储器启动的情况。文章通过分析代码,解答了关于函数寻址、全局变量寻址以及全局指针变量操作在relocation后的处理方式,揭示了U-Boot如何利用位置无关代码(PIC)和rel.dyn段实现完美重定位。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近在一直在做uboot的移植工作,uboot中有很多值得学习的东西,之前总结过uboot的启动流程,但uboot一个非常核心的功能没有仔细研究,就是uboot的relocation功能。

这几天研究下uboot的relocation功能,记录在此,跟大家共享。

自己辛苦编辑,转载请注明出处,谢谢!


所谓的relocation,就是重定位,uboot运行后会将自身代码拷贝到sdram的另一个位置继续运行,这个在uboot启动流程分析中说过。

但基于以前的理解,一个完整可运行的bin文件,link时指定的链接地址,load时的加载地址,运行时的运行地址,这3个地址应该是一致的

relocation后运行地址不同于加载地址 特别是链接地址,ARM的寻址会不会出现问题?


新版uboot跟老版uboot不太一样的地方在于新版uboot不管uboot的load addr(entry pointer)在哪里,启动后会计算出一个靠近sdram顶端的地址,将自身代码拷贝到该地址,继续运行。

个人感觉uboot这样改进用意有二,一是为kernel腾出低端空间,防止kernel解压覆盖uboot,二是对于由静态存储器(spiflash nandflash)启动,这个relocation是必须的。


但是这样会有一个问题,relocation后uboot的运行地址跟其链接地址不一致,compiler会在link时确定了其中变量以及函数的绝对地址,链接地址 加载地址 运行地址应该一致,

这样看来,arm在寻址这些变量 函数时找到的应该是relocation之前的地址,这样relocation就没有意义了!


当然uboot不会这样,我们来分析一下uboot下relocation之后是如何寻址的,开始学习之前我是有3个疑问,如下

(1)如何对函数进行寻址调用

(2)如何对全局变量进行寻址操作(读写)

(3)对于全局指针变量中存储的其他变量或函数地址在relocation之后如何操作

搞清楚这3个问题,对于我来说relocation的原理就算是搞明白了。


为了搞清楚这些,在uboot的某一个文件中加入如下代码

void test_func(void)
{
    printf("test func\n");
}

static void * test_func_val = test_func;
static int test_val = 10; 

void rel_dyn_test()
{
    test_val = 20; 
    printf("test = 0x%x\n", test_func);
    printf("test_func = 0x%x\n", test_func_val);
    test_func();
}
rel_dyn_test函数中就包含了函数指针 变量赋值 函数调用这3种情况,寻址肯定要汇编级的追踪才可以,编译完成后反汇编,得到u-boot.dump(objdump用-D选项,将所有section都disassemble出来)

找到rel_dyn_test函数,如下:

80e9d3cc <test_func>:
80e9d3cc:   e59f0000    ldr r0, [pc, #0]    ; 80e9d3d4 <test_func+0x8>
80e9d3d0:   eaffc2fb    b   80e8dfc4 <printf>
80e9d3d4:   80eb1c39    .word   0x80eb1c39

80e9d3d8 <rel_dyn_test>:
80e9d3d8:   e59f202c    ldr r2, [pc, #44]   ; 80e9d40c <rel_dyn_test+0x34>
80e9d3dc:   e3a03014    mov r3, #20 ; 0x14 
80e9d3e0:   e92d4010    push    {r4, lr}
80e9d3e4:   e59f1024    ldr r1, [pc, #36]   ; 80e9d410 <rel_dyn_test+0x38>
80e9d3e8:   e5823000    str r3, [r2]
80e9d3ec:   e59f0020    ldr r0, [pc, #32]   ; 80e9d414 <rel_dyn_test+0x3c>
80e9d3f0:   ebffc2f3    bl  80e8dfc4 <prin
### U-Boot 中 DM-SPL 的实现原理 在 U-Boot 中,`dm-spl` 配置用于指定设备模型 (Device Model, DM) 在 Secondary Program Loader (SPL) 和 U-Boot pre-relocation 阶段的应用[^1]。此配置项确保了 SPL 能够访问并初始化必要的硬件资源,在早期启动过程中提供支持。 #### 设备树节点定义 为了使能 `dm-spl` 功能,需要在设备树源文件 (.dts) 中适当位置添加如下属性: ```dts chosen { bootargs = "console=ttyS0,115200"; u-boot,dm-spl; }; ``` 上述代码片段展示了如何通过设置 `u-boot,dm-spl` 属性来启用该功能。这使得平台能够在 SPL 阶段利用完整的设备管理框架进行驱动加载和资源配置。 #### 实现机制解析 当设置了 `u-boot,dm-spl` 之后,U-Boot 将会在 SPL 初始化期间调用特定函数以构建初始环境,并完成对关键外设的支持。具体来说: - **初始化阶段**:读取存储介质中的镜像数据至内存; - **设备枚举**:依据设备树描述自动探测连接在外围总线上的组件; - **驱动绑定**:为已识别的硬件分配相应的驱动程序实例; 这些操作共同构成了一个稳健可靠的低级运行时环境,从而保障后续更高层次软件模块可以顺利接管控制权。 #### 关键代码示例 以下是部分涉及 `dm-spl` 处理逻辑的关键 C 语言代码摘录: ```c // 文件路径: drivers/core/init.c int dm_init(void) { #ifdef CONFIG_SPL_BUILD /* 如果是在编译 SPL,则仅处理标记有 'spl' 或者 'tpl' 的节点 */ if (!IS_ENABLED(CONFIG_DM_TPL)) return dm_scan_fdt_spl(gd->fdt_blob); #endif } ``` 这段代码表明,在 SPL 构建环境下 (`CONFIG_SPL_BUILD`) 并且未开启 TPL 支持的情况下,会专门扫描带有 `spl` 或 `tpl` 标记的 FDT (Flattened Device Tree) 节点来进行有限度的初始化工作。
评论 27
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值