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.
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.
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 ?
-Scott