[U-Boot] [PATCH v1] arm: remove unneeded symbol offsets and _TEXT_BASE

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Beno?t,

On Tue, 15 Oct 2013 13:07:53 +0200 (CEST), Beno?t Th?baudeau
<benoit.thebaudeau@advansee.com> wrote:

> Hi Albert,
> 
> On Sunday, October 13, 2013 7:16:33 PM, Albert ARIBAUD wrote:
> > Hi Beno?t,
> > 
> > On Sun, 13 Oct 2013 17:00:25 +0200 (CEST), Beno?t Th?baudeau
> > <benoit.thebaudeau@advansee.com> wrote:
> > 
> > > Hi Albert,
> > > 
> > > On Sunday, October 13, 2013 9:10:28 AM, Albert ARIBAUD wrote:
> > > [...]
> > > 
> > > > diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> > > > index 34f50b0..f8ac573 100644
> > > > --- a/arch/arm/lib/board.c
> > > > +++ b/arch/arm/lib/board.c
> > > > @@ -105,8 +105,8 @@ static int display_banner(void)
> > > >  {
> > > >  	printf("\n\n%s\n\n", version_string);
> > > >  	debug("U-Boot code: %08lX -> %08lX  BSS: -> %08lX\n",
> > > > -	       _TEXT_BASE,
> > > > -	       _bss_start_ofs + _TEXT_BASE, _bss_end_ofs + _TEXT_BASE);
> > > > +	       (ulong)&_start,
> > > > +	       (ulong)&__bss_start, (ulong)&__bss_end);
> > > >  #ifdef CONFIG_MODEM_SUPPORT
> > > >  	debug("Modem Support enabled\n");
> > > >  #endif
> > > 
> > > This hunk and all the other hunks using _TEXT_BASE in the same way will
> > > introduce different resulting values than the original code for targets
> > > having
> > > different build-time and run-time addresses.
> > > 
> > > This is not too much of an issue for the debug() call here, but this may be
> > > more
> > > damaging for things like gd->reloc_off below.
> > 
> > Indeed build-time and run-time values might be different. Normally,
> > U-Boot starts by being loaded at its build-time address and run from
> > there (or directly run there if from NOR). At that point, its build- and
> > run-time addresses coincide. then we reach relocation. Then U-Boot
> > runs from top of RAM, with a run-time address different from its
> > build-time one, bu with all base-address-dependent locations fixed by
> > relocation, so again, run-time and (relocated) build-time values are
> > equal.
> 
> That's not true for all values following relocation. E.g., in start.S,
> _TEXT_BASE is initialized to either CONFIG_SPL_TEXT_BASE or
> CONFIG_SYS_TEXT_BASE. Those are #defined, so _TEXT_BASE has the same value
> before and after relocation, and this value differs from &_start after
> relocation.

Indeed; however, I believe that in all cases where _TEXT_BASE contained
CONFIG_{SYS,SPL}_TEXT_BASE, I replaced references to _TEXT_BASE with
references to CONFIG_{SYS,SPL}_TEXT_BASE, which is a constant and thus
will not be relocated. Unless I missed one, of course.

Similarly, in places where relocation-sensitive symbols are actually
used to compute size, which is relocation-insensitive, we should not
have any problems either.

> > IOW, this debug() line would use true build-time values if invoked
> > before relocation, and actual run-time values after relocation, because
> > the &symbol constructs would have relocation entries and thus be fixed
> > during relocation.
> > 
> > This does not preclude corner-case situations where some in-relocation
> > code requires knowing both the pre- and post-relocation addresses of
> > a symbol; usually it's a matter of looking at the "in-RAM" U-Boot image
> > vs the "in-FLASH" U-Boot image, e.g. when relocating, we copy
> > U-Bootfrom "source" to "destination" and then fix relocation using
> > the "source" relocation table, because there is no "destination"
> > relocation table. Normally these corner-case situations only arise near
> > the relocation code itself.
> > 
> > However, if e.g. some fields of this debug() call should be the
> > "initial" addresses while the debug() is executed at "final" location,
> > just point them to me.
> 
> board_init_f() is called before relocation, so as long as there is no target
> having different build- and run-time addresses at this point (which AFAIK is the
> case), the changes made to this function are safe.
> 
> And display_banner() is called from board_init_f(), so everything should be fine
> here.
> 
> Hence, we basically just have to make sure that there is no exception board
> here.

Agreed, although the only possible 'exception' would be some board code
expecting relocation-sensitive symbols to keep their pre-relocation
values after relocation, and I don't see why that would happen.

Thanks for your input.

> Best regards,
> Beno?t

Amicalement,
-- 
Albert.