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

Scott Wood scottwood at freescale.com
Wed Oct 2 18:48:15 CEST 2013


On Wed, 2013-10-02 at 09:52 +0800, FengHua wrote:
> 
> 
> > -----原始邮件-----
> > 发件人: "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:
> > > 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.

It requires building another program image (even if it's a relatively
simple one), as opposed to just invoking objcopy and ld, and it makes
invoking the simulator more complicated.

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

Then why does it even try to start without an ELF being supplied (but
won't try to start if I don't supply ELF *or* raw data)?  Why is there
no other way to supply an entry point (even just defaulting to the
beginning of the raw image if no ELF is provided)?  Why does it fail
when I supply *both* the ELF and the raw image, in either order?

-Scott





More information about the U-Boot mailing list