From mboxrd@z Thu Jan 1 00:00:00 1970 From: York Sun Date: Wed, 30 Apr 2014 17:01:03 -0700 Subject: [U-Boot] [Patch v2 1/2] common/board_f: Preserve global data for mpc85xx and mpc86xx In-Reply-To: <1398901968.24575.237.camel@snotra.buserror.net> References: <1398893511-22085-1-git-send-email-yorksun@freescale.com> <1398897910.24575.221.camel@snotra.buserror.net> <53617DCC.8050403@freescale.com> <1398898280.24575.224.camel@snotra.buserror.net> <53617FA1.3070809@freescale.com> <1398898678.24575.226.camel@snotra.buserror.net> <536189D1.1060701@freescale.com> <1398901443.24575.233.camel@snotra.buserror.net> <53618BD0.4000200@freescale.com> <1398901968.24575.237.camel@snotra.buserror.net> Message-ID: <53618EBF.5020304@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/30/2014 04:52 PM, Scott Wood wrote: > 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 >>>>>>>>>> --- >>>>>>>>>> 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. I can agree on this. > >>> 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. > That will be in include/common.h for cross-platform macros. York