[U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t

[FengHua]

> -----原始邮件-----
> 发件人: "Scott Wood" <scottwood at freescale.com>
> 发送时间: 2013年10月1日 星期二
> 收件人: "Simon Glass" <sjg at chromium.org>
> 抄送: trini <trini at ti.com>, u-boot <u-boot at lists.denx.de>, FengHua <fenghua at 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:
> > 
> > 1. Write a utility to apply the relocations (for the pre-relocation
> > address) at build time, or
> > 
> > 2. 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.

David,