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 <[email protected]> > >>>>>>>> --- > >>>>>>>> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
