[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

On Tuesday, September 20, 2011 09:12:08 PM Scott Wood wrote:
> On 09/19/2011 05:31 PM, Marek Vasut wrote:
> > On Monday, September 19, 2011 08:13:45 PM Scott Wood wrote:
> >> On 09/16/2011 05:48 PM, Marek Vasut wrote:
> >>> The stuff in arch/arm/cpu should be exactly what you need, nothing more
> >>> !
> >> 
> >> This is "spl/", not "arch/arm/spl/", so let's not reason from one
> >> architecture, much less the subset of that architecture that has already
> >> been made to work with spl/ -- there are 14 different instances of
> >> arch/arm/cpu/$(CPU).
> > 
> > I don't think I follow you on this one really -- are we still discussing
> > the inclusion/non-inclusion of the cpu-specific library in the SPL,
> > right ?
> 
> We're discussing CONFIG_SPL_NO_CPU_SUPPORT_CODE and its use in
> spl/Makefile.
> 
> >> We will not want everything we normally pull from
> >> arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example.  But
> >> we will want some small portion of it.
> > 
> > Then you adjust the makefile there by ifdef CONFIG_SPL_BUILD
> 
> It's not quite that simple, since different SPLs will have different
> requirements.  Board config headers will need to define symbols like
> CONFIG_SPL_FEATURE and the makefiles will use both CONFIG_SPL_BUILD and
> CONFIG_SPL_FEATURE to determine which object files to include.

That kind of granularity is there already too -- though on driver level. But so 
far it seem sufficient.

> 
> Board config headers should set appropriate symbols indicating what
> parts of arch/$(ARCH)/cpu/$(CPU) they want during an SPL build (at
> whatever granularity is appropriate).  If that's an empty set, then so
> be it, no need to avoid the directory altogether.
> 
> >> Whether it's file or directory based, everything should be off by
> >> default.  Boards should ask for what they want, not what they want to
> >> exclude.
> > 
> > Actually, this being a rare case where you want it excluded, it's better
> > the way it is.
> 
> I disagree, especially in the early stages where we're setting an
> example for how other components will be handled.

No, it's really rare if you want to replace your lowlevel init code because your 
ROM seems strange.

> 
> -Scott