[U-Boot] [Patch v2 1/2] common/board_f: Preserve global data for mpc85xx and mpc86xx

[Scott Wood]

On Wed, 2014-04-30 at 16:48 -0700, York Sun wrote:
> On 04/30/2014 04:44 PM, Scott Wood wrote:
> > On Wed, 2014-04-30 at 16:40 -0700, York Sun wrote:
> >> On 04/30/2014 03:57 PM, Scott Wood wrote:
> >>> On Wed, 2014-04-30 at 15:56 -0700, York Sun wrote:
> >>>> On 04/30/2014 03:51 PM, Scott Wood wrote:
> >>>>> On Wed, 2014-04-30 at 15:48 -0700, York Sun wrote:
> >>>>>> On 04/30/2014 03:45 PM, Scott Wood wrote:
> >>>>>>> On Wed, 2014-04-30 at 14:31 -0700, York Sun wrote:
> >>>>>>>> For powerpc SoCs (including mpc85xx, mpc86xx), global data is used for
> >>>>>>>> initializing LAWs, before calling function baord_inti_f(). This data
> >>>>>>>> should not be cleared later.
> >>>>>>>>
> >>>>>>>> Signed-off-by: York Sun <yorksun at freescale.com>
> >>>>>>>> ---
> >>>>>>>> Change log
> >>>>>>>>  v2: Instead of adding back gd init for all PPC, preserve gd for mpc85xx and mpc86xx.
> >>>>>>>>
> >>>>>>>>  Note, need other maintainers to fix 83xx, 5xxx, 512x as I don't have boards to verify.
> >>>>>>>>
> >>>>>>>>  common/board_f.c |    6 +++++-
> >>>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git a/common/board_f.c b/common/board_f.c
> >>>>>>>> index cbdf06f..eebb377 100644
> >>>>>>>> --- a/common/board_f.c
> >>>>>>>> +++ b/common/board_f.c
> >>>>>>>> @@ -970,7 +970,11 @@ static init_fnc_t init_sequence_f[] = {
> >>>>>>>>  
> >>>>>>>>  void board_init_f(ulong boot_flags)
> >>>>>>>>  {
> >>>>>>>> -#ifndef CONFIG_X86
> >>>>>>>> +	/*
> >>>>>>>> +	 * For MPC85xx, global data is initialized in cpu_init_early_f() and
> >>>>>>>> +	 * used for init_law(). gd should not be cleared in this function.
> >>>>>>>> +	 */
> >>>>>>>> +#if !defined(CONFIG_X86) && !defined(CONFIG_MPC85xx) && !defined(CONFIG_MPC86xx)
> >>>>>>>>  	gd_t data;
> >>>>>>>>
> >>>>>>>>  	gd = &data;
> >>>>>>>
> >>>>>>> It would be better to introduce a CONFIG_SYS_EARLY_GD (or similar)
> >>>>>>> rather than growing a list here.
> >>>>>>
> >>>>>> That's do-able.
> >>>>>>
> >>>>>>>
> >>>>>>> Is there any reason why the set of targets for which zero_global_data()
> >>>>>>> is skipped is different from the set of targets where the gd
> >>>>>>> instantiation and assignment is skipped?
> >>>>>>
> >>>>>> I would think the list should be identical. But without proper testing, I am
> >>>>>> reluctant to copy the list. As you have suggested, start from 85xx first.
> >>>>>> Non-mpc85xx can be dealt with when they get converted.
> >>>>>
> >>>>> None of those other PPC targets currently use the generic board.  They
> >>>>> will be tested when they are converted.
> >>>>>
> >>>>
> >>>> Are you suggesting to copy the list, instead of only putting those tested?
> >>>
> >>> I'm saying to use CONFIG_SYS_EARLY_GD for both things.
> >>>
> >>>>  It may save other maintainer some effort of debugging. But I can't be
> >>>> sure they will all work.
> >>>
> >>> What good reason could there be for wanting to skip clearing of a gd
> >>> that was just allocated on the stack?
> >>>
> >>
> >> Relocating is OK. But clearing is not. At least the used LAWs variable is
> >> needed. There may be other variables as well. All data in gd is copied to new
> >> location.
> > 
> > Where do you get relocating from (at this stage of boot -- of course it
> > will get relocated when U-Boot gets relocated)?  Either gd was
> > initialized early, in which case we want to keep using it and not clear
> > it, or it wasn't, in which case we want to allocate gd on the stack and
> > clear it.
> 
> Exactly. gd is used before board_init_f() for many cases.

Yes, that's the whole point of CONFIG_SYS_EARLY_GD.  What I'm saying is
to forget about the current ifdef list around zero_global_data(), and
replace it with CONFIG_SYS_EARLY_GD, which for now would only contain
mpc85xx, mpc86xx, and x86.  Other targets can skip the zeroing if and
when they also skip the stack allocation and assignment.

> > BTW, I see x86 also skips "gd = new_gd" in board_init_r(), so I wonder
> > what is going on with gd on x86, and whether it makes sense to lump it
> > in with CONFIG_SYS_EARLY_GD.
> > 
> 
> Maybe x86 maintainers can chime in? If we define such macro, it should probably
> sit right above board_init_f() so it can be seen easily. There is no other place
> it is needed, yet.

I was thinking it would be set the same way other CONFIG symbols are
set.

-Scott