On Wednesday, September 21, 2011 01:31:28 AM Scott Wood wrote: > On 09/20/2011 04:30 PM, Marek Vasut wrote: > > On Tuesday, September 20, 2011 11:23:01 PM Scott Wood wrote: > >> On 09/20/2011 04:16 PM, Marek Vasut wrote: > >>> On Tuesday, September 20, 2011 09:12:08 PM Scott Wood wrote: > >>>> On 09/19/2011 05:31 PM, Marek Vasut wrote: > >>>>> 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. > >> > >> What's wrong with using that model for arch code as well? > >> > >> Note that "so far" most of the existing SPL targets have not been > >> converted to the new spl/. > > > > Right, so when you hit the problem, you fix it. No need to overengineer > > it right away. > > It seems you hit the problem already, and you're trying to add an ad hoc > workaround rather than apply the same concept to arch code that is to be > used with drivers. > > Wanting to staying consistent and simple is not overengineering. > > >> It's not about rarity (which is often misjudged, BTW). It's about > >> whether the model for selecting code for the SPL is additive or > >> subtractive, and whether we have a consistent mechanism or ad hockery > >> from the start. > >> > >> In nand_spl/ it was fully additive. I'd like to keep it that way. > > > > I see your point and I disagree. I'd use the majority vote here -- most > > of the boards need it and rare ones don't -- so why put additional > > burden on majority in favor of minority ? > > Is it really such a burden to put something like > > #define CONFIG_SPL_ARCH_CPU > > in your board config header?
Yes it's a burden. It's a burden to add this to all boards but one. It makes no sense. > If you end up with several things that 95% > of targets are including, factor them out into a common header, like > include/config_cmd_default.h. Or have a single define that selects a > set of defaults. Or integrate kconfig. :-) > > I don't want to get into a situation where someone has to dig around to > find out which bits of code are included by default, and what the > special magic is to turn them off. > > -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
