On Thu, Sep 22, 2011 at 1:52 AM, Marek Vasut marek.vasut@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.