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