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

[Scott Wood]

On Fri, 2013-08-23 at 19:17 -0500, Scott Wood wrote:
> On Fri, 2013-08-23 at 18:12 -0600, Simon Glass wrote:
> > Hi,
> > 
> > On Thu, Aug 22, 2013 at 8:55 AM, FengHua <fenghua at phytium.com.cn> wrote:
> > >
> > > On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote:
> > >>
> > >>
> > >>
> > >> > -----????????????-----
> > >> > ?????????: "Scott Wood" <scottwood at freescale.com>
> > >> > ????????????: 2013???8???22??? ?????????
> > >> > ?????????: "Simon Glass" <sjg at chromium.org>
> > >> > ??????: FengHua <fenghua at phytium.com.cn>, "trini at ti.com" <trini at ti.com>,
> > >> > "U-Boot
> > >> >  Mailing List" <u-boot at lists.denx.de>
> > >> > ??????: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc
> > >> > and zero gd_t
> > >> >
> > >> > On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote:
> > >> > > Hi David,
> > >> > >
> > >> > > On Tue, Aug 20, 2013 at 4:48 AM,  <fenghua at phytium.com.cn> wrote:
> > >> > > > diff --git a/common/board_r.c b/common/board_r.c
> > >> > > > index 86ca1cb..1b4bdd2 100644
> > >> > > > --- a/common/board_r.c
> > >> > > > +++ b/common/board_r.c
> > >> > > > @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void)
> > >> > > >          */
> > >> > > >         gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE;
> > >> > > >  #endif
> > >> > > > +#ifdef CONFIG_NEEDS_MANUAL_RELOC
> > >> > > > +       /*
> > >> > > > +        * We have to relocate the command table manually
> > >> > > > +        */
> > >> > > > +       fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),
> > >> > > > +                       ll_entry_count(cmd_tbl_t, cmd));
> > >> > > > +#endif /* CONFIG_NEEDS_MANUAL_RELOC */
> > >> > >
> > >> > > Should this be done here or in main_loop()? How is this currently done
> > >> > > when not using generic board?
> > >> >
> > >> > It shouldn't be done at all -- let's not revive manual relocations.
> > >> > I'll try to get proper relocation working.
> > >>
> > >> Even the rela relocation of aarch64 works we should keep this here.
> > >> The generic board could be used by any other platform that need manual
> > >> relocation.
> > >
> > >>No, the point is that manual relocation is legacy and new platforms
> > >> should be using proper relocation.
> > >
> > >
> > >
> > >    Of course, manual relocation is not good. But I noticed that there are
> > > serveral architecture use manual relocation now, maybe we should keep this
> > > for compatibility. Another way, I am not sure whether we can get rid of
> > > manual relocation on all architecture. I used manual relocation on aarch64
> > > because I found the initial addresses of data in rela mode are all zero
> > > whatever the text base is, and I don't know how to solve this problem.
> > 
> > Possible there is a new relocation type that you need to support?
> 
> Yes, it's rela instead of rel.  FengHua claimed to have run into
> problems supporting it; I'll try to debug it hopefully somewhat soon
> (though I'll be on vacation most of next week, so probably not until at
> least the week after).

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.

-Scott