From mboxrd@z Thu Jan  1 00:00:00 1970
From: York Sun <yorksun@freescale.com>
Date: Wed, 30 Apr 2014 17:17:50 -0700
Subject: [U-Boot] [Patch v2 1/2] common/board_f: Preserve global data
 for mpc85xx and mpc86xx
In-Reply-To: <1398903102.24575.240.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>		
	<53618EBF.5020304@freescale.com>	
	<1398902577.24575.239.camel@snotra.buserror.net>	
	<53618FDB.3090704@freescale.com>
	<1398903102.24575.240.camel@snotra.buserror.net>
Message-ID: <536192AE.80300@freescale.com>
List-Id: <u-boot.lists.denx.de>
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 05:11 PM, Scott Wood wrote:
> On Wed, 2014-04-30 at 17:05 -0700, York Sun wrote:
>> On 04/30/2014 05:02 PM, Scott Wood wrote:
>>> On Wed, 2014-04-30 at 17:01 -0700, York Sun wrote:
>>>>>>> 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.
>>>
>>> No, it's in the particular board files (or better, arch/subarch files
>>> included by board files) that need this.  The point is to not have a big
>>> ifdef list, rather than to just move the big ifdef list.
>>>
>>
>> I got your idea. You are suggesting to define this macro in each arch which it
>> needs to preserve gd. So we won't have a list. It is neat but may be easy to miss.
> 
> It's how other such things are handled.  We'd have a giant mess if we
> had lists of targets strewn throughout the codebase.
> 

This will be a negative logic,

#ifndef CONFIG_SYS_EARLY_GD
	gd_t data;

	gd =  &data;
	zero_global_data();
#endif

York