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