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