-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年10月1日 星期二 收件人: FengHua fenghua@phytium.com.cn 抄送: "Simon Glass" sjg@chromium.org, trini trini@ti.com, u-boot u-boot@lists.denx.de 主题: Re: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-10-01 at 19:05 +0800, FengHua wrote:
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年10月1日 星期二 收件人: "Simon Glass" sjg@chromium.org 抄送: trini trini@ti.com, u-boot u-boot@lists.denx.de, FengHua fenghua@phytium.com.cn 主题: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote:
It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed.
Unless there's some way to change this linker behavior, the options I can think of are:
- Write a utility to apply the relocations (for the pre-relocation
address) at build time, or
- Use SPL. The SPL itself would not use -pie and would not relocate.
The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward.
Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow.
#1 is easier to do on the u-boot.bin rather than on the ELF file[1], but apparently that doesn't do us any good with the model because it wants an ELF file. Shouldn't the model be applying the relocations if it's an ELF loader? Is there any way to get the foundation model to load a raw binary? I tried --data and --nsdata at 0x80000000 (alone or in combination with --image) and wasn't able to do a write to the LEDs immediately after reset (which works when I load it as ELF).
It works when I convert the binary back into an ELF using objcopy and ld, but it would be nice to avoid that...
How about place u-boot.bin at 0x90000000 and write a piece of code (elf format) jumping from 0x80000000 to 0x90000000.
That seems even worse than converting the .bin back into an ELF...
Why? I could load u-boot.bin at 0x90000000 as data, I think it should works. Or maybe secure state make the program jumping to secure memory. so try switching to el2 before jumping.
Do you know why loading the raw image at 0x80000000 isn't working?
The foundation model require a elf(axf) image being loaded, it use it to determine the entry point.
David