[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日 星期二
> 收件人: FengHua <fenghua at phytium.com.cn>
> 抄送: "Simon Glass" <sjg at chromium.org>, trini <trini at ti.com>, u-boot <u-boot at 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 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.
> 
> 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