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

Scott Wood scottwood at freescale.com
Tue Oct 1 17:07:11 CEST 2013


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...

Do you know why loading the raw image at 0x80000000 isn't working?

-Scott





More information about the U-Boot mailing list