On Thu, Sep 22, 2011 at 1:52 AM, Marek Vasut <marek.va...@gmail.com> wrote: > 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.
Looking at a pile of partially ported TI boards, I wonder if we don't need a few common SPL include files, setting this-and-that and then letting boards opt-out of these defaults (or just going it alone?) as needed. -- Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
