uboot代码重定位

(mips)

进入函数board_init_f后,首先做一系列初始化:
                timer_init    时钟初始化
                env_init    环境变量初始化(取得环境变量存放的地址)
                init_baudrate    串口速率
                serial_init        串口初始化
                console_init_f    配置控制台
                display_banner    显示u-boot启动信息,版本号等
                checkboard        执行board相关的操作。
                init_func_ram    初始化内存,配置ddr controller
这一系列工作完成后,串口和内存都已经可以用了。然后,就要把内存进行划分,
在内存的最后一部分,留出u-boot代码大小的空间,准备把u-boot代码从flash搬移到这里
然后,是堆的空间,malloc的内存就来自于这里。紧接着放两个全局数据结构bd_info global_data和环境变量boot_params。最后,是栈的空间。
准备进行relocate code。
relocate code的意思是这样的。通常u-boot的执行代码肯定是在flash上(当调试的时候也可以放在ram上)。当启动起来以后,要把它从flash上搬移到ram里运行。这个工作就叫做relocate code。
但是,问题在于,flash上的地址和ram上的地址是不同的。当我们把代码从flash上搬移到ram上以后,当执行函数跳转时,代码里的函数地址还是flash上的地址,所以一跳就跳回去了。
这怎么办呢?
在u-boot里面用的是PIC(position-independent code)的方式解决这个问题。
简单介绍一下其原理。当你用PIC方式时,在用gcc编译时需加上 -fpic的选项。编译器会为你的可执行代码建立一个GOT(global offset table)的段。一个地址在GOT表中有一项,里面存放地址的信息,而在使用这个地址时,只要根据这个地址的编号(也可以叫做偏移量offset)找到表中相应的项目,就可以取得那个地址了。
而如果位置发生变化,只要对GOT表中的地址进行修改就可以了。
我们可以通过反汇编,看一个简单的函数调用例子:
lw    t9,1088(gp)
jalr    t9
这里,gp存放的就是GOT表的起始地址,而1088就是要调用函数的offset,也就是说GOT表的那个位置存放着它的地址。lw    t9,1088(gp) 把函数地址放入t9, 然后调用就可以了。
知道了PIC的原理,解释u-boot relocate code的方法就简单了。
简单的说就把u-boot的执行代码直接从flash里copy到ram的相应区域。
然后,把GOT表中的地址都加上一个偏移量,这个偏移量就是flash里的地址与ram里的地址的差。
还有其他一些工作比如:设置新的栈指针,从flash代码里跳转到ram代码里 等等。
之后,就进入board.c的board_init_r函数,在这个函数里初始化 malloc,flash,pci 以及外设(比如,网口),最后进入命令行或者直接启动Linux kernel。
这样,u-boot的启动工作就完成了。

 

 

 

(mpc83xx)

.globl      relocate_code

relocate_code:             

       r4<= CFG_MONITOR_BASE=0xFE000000,源代码地址,text_base     

       r5<=GOT(__init_end) –r4 , GOT获得_init_end,源代码结束地址,定义在u-boot.lds,故差是u-boot代码长度

       r6<=CFG_CACHELINE_SIZE             /* Cache Line Size,每次搬运32bit*/

       //更新GOT pointer: New GOT-PTR = (old GOT-PTR - CFG_MONITOR_BASE)+Destination Address

       r14<= r14+r10-r4

r0<=(r5+3)/4,每次搬运32bit,4个字节,r0为将代码copyram的次数

mtctr      r0  //将搬运次数,存放至计数器

r0=0,则不需搬运代码,否则需要进行代码搬运

       la     r8,-4(r4)  //r8<=r4-4

       la     r7,-4(r3)

1:     lwzu       r0,4(r8)

       stwu       r0,4(r7)//代码搬运

       bdnz       1b

  然后在进行第二次搬运,并比较,如果发现不同,则表示搬运出错,退出

      (注:当目的地址>源地址,则逆序搬运代码,而且不需要进行二次搬运和比较。不知道为什么这么做)

 //Flush the cache

       mr   r4,r3

5:     dcbst      0,r4 //有效地址EA=r4+0,EA所在的cache行与内存同步

       add  r4,r4,r6

       cmplw    r4,r5

       blt    5b

       sync                     /* Wait for all dcbst to complete on bus */

       mr   r4,r3

6:     icbi  0,r4   //有效地址EA=r4+0,EA所在的指令cache行无效

       add  r4,r4,r6

       cmplw    r4,r5

       blt    6b

7:     sync                     /* Wait for all icbi to complete on bus   */

       isync

 

/*此时并不返回,而是跳转到board的第二部分的初始化,即in_ramstart.S,此后代码在RAM中运行*/

       addi r0, r10, in_ram - _start + EXC_OFF_SYS_RESET //r10为目的地址

       mtlr r0

       blr

<think>好的,用户现在想了解U-Boot中进行代码重定位的原因,也就是代码重定位的作用和原因。我需要根据用户提供的引用资料和我之前的知识来回答这个问题。首先,我需要回忆一下U-Boot的启动流程,以及代码重定位的具体过程。 根据用户提供的引用[2]和[3],U-Boot在启动时会执行重定位操作,将自身代码从初始位置(比如Flash)复制到RAM中运行。引用[3]中的代码显示,在start.S文件中,通过比较当前代码地址和链接地址,判断是否需要重定位。如果运行地址和链接地址不同,就需要执行CopyCode2Ram函数,将代码复制到RAM中。 那用户的问题核心是:为什么要进行代码重定位?可能的原因包括: 1. **运行速度优化**:Flash的访问速度通常比RAM慢,将代码复制到RAM中可以加快执行速度。 2. **地址空间限制**:有些处理器在启动时可能运行在受限的地址空间,重定位到RAM可以解除这种限制。 3. **动态内存管理**:重定位后,U-Boot可以使用动态内存分配,为后续操作(如加载内核)做准备。 4. **多阶段启动需求**:U-Boot分为SPL和主U-Boot,SPL负责初始化硬件并将主U-Boot加载到RAM中运行。 接下来需要结合用户提供的引用资料来验证这些原因是否正确。引用[2]提到,U-Boot的代码段默认从reset函数开始,执行到_main后调用relocate_code进行重定位。这说明重定位是启动流程中的一个必要步骤,确保代码在正确的地址运行。 引用[3]中的代码展示了如何通过比较运行地址和链接地址来决定是否需要重定位。如果两者不同,就需要将代码从Flash复制到RAM中的链接地址。这说明重定位的原因之一是确保代码在编译时指定的地址运行,避免地址错误导致的运行问题。 此外,用户之前的回答中提到init_sequence_f负责第一阶段初始化,包括内存布局计算和重定位准备,这为代码重定位提供了必要的环境,比如内存初始化和地址计算。 现在需要将这些点整理成一个结构化的回答,解释重定位的原因和作用,可能分为几个部分:运行环境适配、性能优化、动态内存管理、多阶段启动支持等。同时,需要引用用户提供的资料来支持每个论点,例如引用[2]和[3]中关于重定位流程的具体代码和步骤。 需要确保回答清晰,技术细节准确,并且使用用户提供的信息来增强可信度。同时,用户可能对重定位的具体机制感兴趣,比如如何计算目标地址、复制代码的过程等,但当前问题主要关注原因和作用,因此需要集中在这些方面,避免过多深入实现细节。 最后,生成相关问题,帮助用户进一步理解相关内容,比如重定位的具体步骤、如何调试重定位问题、与地址无关代码的关系等。这些问题应该基于用户之前的提问和当前内容,确保连贯性和相关性。</think>### U-Boot 代码重定位的作用与原因详解 --- #### 一、代码重定位的核心目标 U-Boot 的代码重定位(Relocation)是启动过程中将自身代码从**初始运行地址**(如 Flash、ROM 等非易失性存储)**复制到目标地址**(通常是 RAM 的高端内存区域)的关键操作。其根本目的是解决 **「运行地址与链接地址不一致」** 的问题,确保后续流程(如内核加载、动态内存管理)能够正确执行[^2][^3]。 --- #### 二、重定位的具体原因 ##### 1. **硬件启动地址限制** - **问题背景**: 许多 ARM 处理器在复位时**强制从固定地址(如 0x0 或 0xFFFF0000)加载代码**,而这一地址可能位于低速 Flash 或 BootROM 中,无法满足 U-Boot 运行需求。 - **解决方法**: 通过重定位代码迁移到 RAM 的高性能区域,例如 SDRAM 的 `_TEXT_BASE`(如 0x87800000)[^3]。 ##### 2. **地址无关代码的局限性** - **链接地址依赖**: U-Boot 编译时通过链接脚本(如 `u-boot.lds`)指定了代码的**逻辑地址**(`_TEXT_BASE`)。若实际运行地址(如 Flash 中的物理地址)与逻辑地址不同,**绝对地址跳转和全局变量访问将失效**。 - **重定位作用**: 将代码复制到与链接地址一致的 RAM 区域,消除地址差异[^3]。 ##### 3. **动态内存管理的需求** - **内存布局重构**: 重定位后,U-Boot 可重新计算内存布局(如堆、栈、设备树的位置),并初始化动态内存分配器(如 `gd->malloc_base`),为后续操作(加载内核、传递设备树)提供灵活的内存管理能力[^2]。 ##### 4. **多阶段启动的衔接** - **SPL 与主 U-Boot 的协作**: 在包含 SPL(Secondary Program Loader)的系统中,SPL 需将主 U-Boot 镜像从存储介质加载到 RAM 的指定地址,重定位是这一过程的实现手段[^2]。 --- #### 三、重定位的技术实现(以 ARMv7 为例) ##### 1. **地址判断与重定位触发** ```c // arch/arm/cpu/armv7/start.S adr r0, _start // 获取当前运行地址(物理地址) ldr r1, _TEXT_BASE // 获取链接地址(逻辑地址) cmp r0, r1 // 比较两者是否相同 bne relocate_code // 若不同则触发重定位[^3] ``` ##### 2. **代码拷贝与地址修正** - **数据复制**: 通过 `CopyCode2Ram` 函数将代码段(`.text`)、数据段(`.data`)从源地址(如 Flash)复制到目标地址(RAM)。 - **符号地址修正**: 重定位后需调整全局变量和函数指针的地址偏移,确保后续代码正确访问符号(通过 `relocate_code` 中的地址修正逻辑实现)[^3]。 ##### 3. **重定位后的内存布局** ```plaintext High Address +------------------+ | Stack | +------------------+ | Heap | +------------------+ | Relocated U-Boot| +------------------+ <-- _TEXT_BASE (0x87800000) | ... | Low Address ``` --- #### 四、重定位失败的影响与调试 ##### 1. **典型故障** - **症状**:U-Boot 启动后卡死或输出 `relocation failed` 错误。 - **原因**: - 目标地址未预留足够内存(如 `CONFIG_SYS_TEXT_BASE` 配置错误)。 - 代码复制过程中数据损坏(Flash 时序配置不当)。 - 地址修正逻辑错误(链接脚本与硬件地址不匹配)[^3]。 ##### 2. **调试方法** - **查看符号表**: 通过 `objdump -t u-boot` 确认 `_start` 和 `_TEXT_BASE` 的地址。 - **打印调试信息**: 在重定位代码中插入 `printf("Current addr: 0x%lx\n", r0)`,观察实际运行地址。 - **内存对比**: 使用 `md` 命令比较 Flash 和 RAM 中的代码内容,验证复制是否完整。 --- ### 相关问题 1. **U-Boot 重定位时如何处理全局数据(`gd` 结构体)?** 重定位前 `gd` 使用静态分配,重定位后通过 `setup_reloc` 更新其地址偏移[^2]。 2. **如何确定 `CONFIG_SYS_TEXT_BASE` 的值是否合理?** 需参考硬件内存映射,避开内核加载区、设备树区域,并确保 RAM 容量足够[^3]。 3. **是否所有架构的 U-Boot 都需要代码重定位?** 依赖启动介质特性:若 CPU 可直接在 Flash/XIP 中运行完整 U-Boot,可禁用重定位(通过 `CONFIG_SKIP_RELOCATE_UBOOT`)[^3]。 4. **重定位后的 U-Boot 如何跳转到新地址继续执行?** 通过 `ldr pc, =_main` 等指令强制跳转到修正后的地址,此后所有代码基于新地址运行[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值