From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Fri, 8 Mar 2013 14:34:13 -0600
Subject: [U-Boot] [U-Boot,
	v2] env: don't generate callback list entries for SPL
In-Reply-To: <20130308202748.GD27930@bill-the-cat> (from trini@ti.com on Fri
	Mar  8 14:27:48 2013)
References: <20121220215105.GA16627@buserror.net>
	<20130308202748.GD27930@bill-the-cat>
Message-ID: <1362774853.29198.2@snotra>
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 03/08/2013 02:27:48 PM, Tom Rini wrote:
> On Thu, Dec 20, 2012 at 11:51:05AM -0000, Scott Wood wrote:
> 
> > SPL doesn't write to the environment.  These list entries prevent  
> the
> > functions from being garbage-collected, even though nothing will  
> look at
> > the list.  This caused several SPL builds (e.g.  P2020RDB-PC_NAND)  
> to
> > break due to size limitations and/or unresolved symbols.
> >
> > A static inline function is used to provide a context in which we
> > can consume the callback, and thus avoid unused function warnings.
> >
> > Signed-off-by: Scott Wood <scottwood@freescale.com>
> > Acked-by: Joe Hershberger <joe.hershberger@gmail.com>
> > Acked-by: Kim Phillips <kim.phillips@freescale.com>
> 
> OK, this isn't quite right.
> On am335x_evm where SPL does use the "full" version of the  
> environment,
> rather than the restricted version that say a3m071 we need these these
> callbacks to be generated.  We usually build successfully since in  
> these
> cases our #include of <u-boot.lst> picks up the one in include that  
> the
> main SPL generates.   But with enough cores we build SPL before we  
> build
> this list for non-SPL, and the build fails.  I shall submit a patch
> shortly for this.

What does am335x_evm do in the SPL that requires modifying the  
environment, and how does omitting the callbacks cause a build break?

The u-boot.lst issue sounds unrelated to this patch.

-Scott