[U-Boot] [PATCH] PPC: Record uboot's relocated address in RAM and show in bdinfo.

[Detlev Zundel <dzu@denx.de>]

Hi Richard,

> Detlev Zundel wrote:
> <snip>
>>
>> Please excuse my ignorance, but why not simply remove the #ifdef
>> CONFIG_AMIGAONEG3SE in board_init_f?  Actually I was hoping to remove
>> the Amigaone special case.
>>
>> Cheers
>>   Detlev
>>
> I prefer getting the data from board_init_r because we really are
> running from RAM at that point; dest_addr is a passed in function
> param.

I see, thanks for the explanation.

> In board_init_f, the addr variable is just what the calculated address
> is. If we must do the copy there I'd like to move the gd->relocaddr =
> addr to just before the call to relocate_code, that way if the
> calculation code got reworked/refactored, we always copy the correct
> addr variable.

Yes, I also agree - if we want to have it in _f, we should move the
assignment.

> Plus the line: debug ("Now running in RAM - U-Boot at: %08lx\n", dest_addr); in board_init_r
>
> Is the de-facto place where documentations that I've seen refer to for
> figuring out where u-boot is relocated, so making the assignment there
> makes it clearer.
>
> All these leads to my preference of getting it from board_init_r.

Actually I do not have a strong preference myself.  The only thing I
could think of is that an earlier assignment discloses the information
also when debugging problems in relocation.  On the other hand if you
_do_ debug the relocation it is unlikely that you need the variable, so
this argument does not tip the scale in any direction.

> I'll be happy to submit a V2 that takes out the CONFIG_AMIGAONEG3SE
> copy operation in board_init_f as well, but I can't confirm if that
> does not break the AMIGAONE board.

Yes, please send such a follow-on patch.  Not being able to test a
change is rather the norm in U-Boot, so it is acceptable to simply CC
the relevant maintainer ("Thomas Frieden
<ThomasF@hyperion-entertainment.com>") and if no NACK is seen include
the changes anyway at some point.

Thanks
  Detlev

-- 
It's like manually inflatable airbags -- people will never
think to use it in time to actually get any help from it.
             -- Miles Bader in <20030607122005.GA1086@gnu.org>
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de