Message ID | 1315800204-19705-3-git-send-email-marek.vasut@gmail.com |
---|---|
State | Accepted |
Headers | show |
On 09/11/2011 11:03 PM, Marek Vasut wrote: > Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU support > library. This can be useful on some setups. > > Signed-off-by: Marek Vasut <marek.vasut@gmail.com> > Cc: Stefano Babic <sbabic@denx.de> > Cc: Wolfgang Denk <wd@denx.de> > Cc: Detlev Zundel <dzu@denx.de> > Cc: Chander Kashyap <chander.kashyap@linaro.org> But you didn't CC these... > --- > spl/Makefile | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/spl/Makefile b/spl/Makefile > index 56d8ea1..63d1a8a 100644 > --- a/spl/Makefile > +++ b/spl/Makefile > @@ -20,6 +20,11 @@ export CONFIG_SPL_BUILD > > include $(TOPDIR)/config.mk > > +# In case we want to avoid the CPU support code, we need to define this: > +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE > +SPL_CPU_SUPPORT_CODE := y > +endif SPL should ideally contain nothing by default. Have options that say what you do want to pull in, not what you don't want. -Scott
On Friday, September 16, 2011 12:57:44 AM Scott Wood wrote: > On 09/11/2011 11:03 PM, Marek Vasut wrote: > > Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU > > support library. This can be useful on some setups. > > > > Signed-off-by: Marek Vasut <marek.vasut@gmail.com> > > Cc: Stefano Babic <sbabic@denx.de> > > Cc: Wolfgang Denk <wd@denx.de> > > Cc: Detlev Zundel <dzu@denx.de> > > Cc: Chander Kashyap <chander.kashyap@linaro.org> > > But you didn't CC these... git send-email should handle those ? > > > --- > > > > spl/Makefile | 7 ++++++- > > 1 files changed, 6 insertions(+), 1 deletions(-) > > > > diff --git a/spl/Makefile b/spl/Makefile > > index 56d8ea1..63d1a8a 100644 > > --- a/spl/Makefile > > +++ b/spl/Makefile > > @@ -20,6 +20,11 @@ export CONFIG_SPL_BUILD > > > > include $(TOPDIR)/config.mk > > > > +# In case we want to avoid the CPU support code, we need to define this: > > +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE > > +SPL_CPU_SUPPORT_CODE := y > > +endif > > SPL should ideally contain nothing by default. Have options that say > what you do want to pull in, not what you don't want. You usually DO want to pull this in (because it contains vectoring code, really basic lowlevel init etc), there are only border cases where you do not want to do that and use your own. Cheers > > -Scott
On 09/15/2011 06:17 PM, Marek Vasut wrote: > On Friday, September 16, 2011 12:57:44 AM Scott Wood wrote: >> On 09/11/2011 11:03 PM, Marek Vasut wrote: >>> Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU >>> support library. This can be useful on some setups. >>> >>> Signed-off-by: Marek Vasut <marek.vasut@gmail.com> >>> Cc: Stefano Babic <sbabic@denx.de> >>> Cc: Wolfgang Denk <wd@denx.de> >>> Cc: Detlev Zundel <dzu@denx.de> >>> Cc: Chander Kashyap <chander.kashyap@linaro.org> >> >> But you didn't CC these... > > git send-email should handle those ? I'm not too familiar with git send-email, but they're not in the CC list of the actual e-mail. >>> +# In case we want to avoid the CPU support code, we need to define this: >>> +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE >>> +SPL_CPU_SUPPORT_CODE := y >>> +endif >> >> SPL should ideally contain nothing by default. Have options that say >> what you do want to pull in, not what you don't want. > > You usually DO want to pull this in (because it contains vectoring code, really > basic lowlevel init etc), there are only border cases where you do not want to > do that and use your own. Sorry, I was a bit confused by seeing lib$(CPU), thought at first you were trying to pull in stuff like arch/$(ARCH)/lib. Still, this seems hackish. Shouldn't the control be on specific files that you include, not directories? -Scott
On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: > On 09/15/2011 06:17 PM, Marek Vasut wrote: > > On Friday, September 16, 2011 12:57:44 AM Scott Wood wrote: > >> On 09/11/2011 11:03 PM, Marek Vasut wrote: > >>> Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU > >>> support library. This can be useful on some setups. > >>> > >>> Signed-off-by: Marek Vasut <marek.vasut@gmail.com> > >>> Cc: Stefano Babic <sbabic@denx.de> > >>> Cc: Wolfgang Denk <wd@denx.de> > >>> Cc: Detlev Zundel <dzu@denx.de> > >>> Cc: Chander Kashyap <chander.kashyap@linaro.org> > >> > >> But you didn't CC these... > > > > git send-email should handle those ? > > I'm not too familiar with git send-email, but they're not in the CC list > of the actual e-mail. > > >>> +# In case we want to avoid the CPU support code, we need to define > >>> this: +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE > >>> +SPL_CPU_SUPPORT_CODE := y > >>> +endif > >> > >> SPL should ideally contain nothing by default. Have options that say > >> what you do want to pull in, not what you don't want. > > > > You usually DO want to pull this in (because it contains vectoring code, > > really basic lowlevel init etc), there are only border cases where you > > do not want to do that and use your own. > > Sorry, I was a bit confused by seeing lib$(CPU), thought at first you > were trying to pull in stuff like arch/$(ARCH)/lib. > > Still, this seems hackish. Shouldn't the control be on specific files > that you include, not directories? I don't think so ... why ? > > -Scott
On 09/16/2011 04:38 PM, Marek Vasut wrote: > On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: >> Still, this seems hackish. Shouldn't the control be on specific files >> that you include, not directories? > > I don't think so ... why ? That's how the main U-Boot build does it... More specifically, the config.h controls should be on features, and the makefiles should decide which (if any) files are required for that feature. If there are no files from arch/$(ARCH)/cpu/$(CPU) needed, then we get an empty lib$(CPU).o -- nothing special needed to avoid it. -Scott
On Friday, September 16, 2011 11:42:50 PM Scott Wood wrote: > On 09/16/2011 04:38 PM, Marek Vasut wrote: > > On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: > >> Still, this seems hackish. Shouldn't the control be on specific files > >> that you include, not directories? > > > > I don't think so ... why ? > > That's how the main U-Boot build does it... More specifically, the > config.h controls should be on features, and the makefiles should decide > which (if any) files are required for that feature. If there are no > files from arch/$(ARCH)/cpu/$(CPU) needed, then we get an empty > lib$(CPU).o -- nothing special needed to avoid it. Yes, but you basically _always_ want that CPU support code in ... and I have no idea why you'd like to avoid particular files. > > -Scott
On 09/16/2011 04:47 PM, Marek Vasut wrote: > On Friday, September 16, 2011 11:42:50 PM Scott Wood wrote: >> On 09/16/2011 04:38 PM, Marek Vasut wrote: >>> On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: >>>> Still, this seems hackish. Shouldn't the control be on specific files >>>> that you include, not directories? >>> >>> I don't think so ... why ? >> >> That's how the main U-Boot build does it... More specifically, the >> config.h controls should be on features, and the makefiles should decide >> which (if any) files are required for that feature. If there are no >> files from arch/$(ARCH)/cpu/$(CPU) needed, then we get an empty >> lib$(CPU).o -- nothing special needed to avoid it. > > Yes, but you basically _always_ want that CPU support code in ... and I have no > idea why you'd like to avoid particular files. You have no idea why I'd like to be extremely selective with what I include in a 4K binary? It's not about avoiding particular files. It's about including *nothing* but what is explicitly asked for through some SPL-specific CONFIG symbol. Maybe that includes everything in arch/$(ARCH)/cpu. Maybe it includes nothing in there. More likely, it includes just a fraction of it. If your answer is gc-sections, why do you need to drop the whole directory? And why waste time building entire files that we know we don't want? Why waste time debugging where the sudden bloat came from instead of getting a simple and clear undefined-symbol error? -Scott
On Saturday, September 17, 2011 12:07:52 AM Scott Wood wrote: > On 09/16/2011 04:47 PM, Marek Vasut wrote: > > On Friday, September 16, 2011 11:42:50 PM Scott Wood wrote: > >> On 09/16/2011 04:38 PM, Marek Vasut wrote: > >>> On Friday, September 16, 2011 09:49:28 PM Scott Wood wrote: > >>>> Still, this seems hackish. Shouldn't the control be on specific files > >>>> that you include, not directories? > >>> > >>> I don't think so ... why ? > >> > >> That's how the main U-Boot build does it... More specifically, the > >> config.h controls should be on features, and the makefiles should decide > >> which (if any) files are required for that feature. If there are no > >> files from arch/$(ARCH)/cpu/$(CPU) needed, then we get an empty > >> lib$(CPU).o -- nothing special needed to avoid it. > > > > Yes, but you basically _always_ want that CPU support code in ... and I > > have no idea why you'd like to avoid particular files. > > You have no idea why I'd like to be extremely selective with what I > include in a 4K binary? That I do understand -- but that kind of selection is there. > > It's not about avoiding particular files. It's about including > *nothing* but what is explicitly asked for through some SPL-specific > CONFIG symbol. Maybe that includes everything in arch/$(ARCH)/cpu. > Maybe it includes nothing in there. More likely, it includes just a > fraction of it. The stuff in arch/arm/cpu should be exactly what you need, nothing more ! > > If your answer is gc-sections, why do you need to drop the whole > directory? And why waste time building entire files that we know we > don't want? Why waste time debugging where the sudden bloat came from > instead of getting a simple and clear undefined-symbol error? > > -Scott
On 09/16/2011 05:48 PM, Marek Vasut wrote: > On Saturday, September 17, 2011 12:07:52 AM Scott Wood wrote: >> You have no idea why I'd like to be extremely selective with what I >> include in a 4K binary? > > That I do understand -- but that kind of selection is there. >> >> It's not about avoiding particular files. It's about including >> *nothing* but what is explicitly asked for through some SPL-specific >> CONFIG symbol. Maybe that includes everything in arch/$(ARCH)/cpu. >> Maybe it includes nothing in there. More likely, it includes just a >> fraction of it. > > The stuff in arch/arm/cpu should be exactly what you need, nothing more ! This is "spl/", not "arch/arm/spl/", so let's not reason from one architecture, much less the subset of that architecture that has already been made to work with spl/ -- there are 14 different instances of arch/arm/cpu/$(CPU). We will not want everything we normally pull from arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example. But we will want some small portion of it. My understanding of how spl/ is meant to work is that each directory's makefiles will use special SPL config symbols to decide what individual objects (if any) to include. It's not clear to me why we need a directory-level control. Maybe it would be the most convenient way to implement it for something that is well-encapsulated and arch-neutral (thus only one instance to worry about), where the odds of a subset being useful are slim, but it doesn't seem appropriate here. 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. -Scott
On Monday, September 19, 2011 08:13:45 PM Scott Wood wrote: > On 09/16/2011 05:48 PM, Marek Vasut wrote: > > On Saturday, September 17, 2011 12:07:52 AM Scott Wood wrote: > >> You have no idea why I'd like to be extremely selective with what I > >> include in a 4K binary? > > > > That I do understand -- but that kind of selection is there. > > > >> It's not about avoiding particular files. It's about including > >> *nothing* but what is explicitly asked for through some SPL-specific > >> CONFIG symbol. Maybe that includes everything in arch/$(ARCH)/cpu. > >> Maybe it includes nothing in there. More likely, it includes just a > >> fraction of it. > > > > The stuff in arch/arm/cpu should be exactly what you need, nothing more ! > > This is "spl/", not "arch/arm/spl/", so let's not reason from one > architecture, much less the subset of that architecture that has already > been made to work with spl/ -- there are 14 different instances of > arch/arm/cpu/$(CPU). I don't think I follow you on this one really -- are we still discussing the inclusion/non-inclusion of the cpu-specific library in the SPL, right ? > > We will not want everything we normally pull from > arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example. But > we will want some small portion of it. Then you adjust the makefile there by ifdef CONFIG_SPL_BUILD > > My understanding of how spl/ is meant to work is that each directory's > makefiles will use special SPL config symbols to decide what individual > objects (if any) to include. It's not clear to me why we need a > directory-level control. Maybe it would be the most convenient way to > implement it for something that is well-encapsulated and arch-neutral > (thus only one instance to worry about), where the odds of a subset > being useful are slim, but it doesn't seem appropriate here. See above, you use CONFIG_SPL_BUILD to select that in the makefile. > > 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. > > -Scott Cheers
On 09/19/2011 05:31 PM, Marek Vasut wrote: > On Monday, September 19, 2011 08:13:45 PM Scott Wood wrote: >> On 09/16/2011 05:48 PM, Marek Vasut wrote: >>> The stuff in arch/arm/cpu should be exactly what you need, nothing more ! >> >> This is "spl/", not "arch/arm/spl/", so let's not reason from one >> architecture, much less the subset of that architecture that has already >> been made to work with spl/ -- there are 14 different instances of >> arch/arm/cpu/$(CPU). > > I don't think I follow you on this one really -- are we still discussing the > inclusion/non-inclusion of the cpu-specific library in the SPL, right ? We're discussing CONFIG_SPL_NO_CPU_SUPPORT_CODE and its use in spl/Makefile. >> We will not want everything we normally pull from >> arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example. But >> we will want some small portion of it. > > 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. Board config headers should set appropriate symbols indicating what parts of arch/$(ARCH)/cpu/$(CPU) they want during an SPL build (at whatever granularity is appropriate). If that's an empty set, then so be it, no need to avoid the directory altogether. >> 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. -Scott
On Tuesday, September 20, 2011 09:12:08 PM Scott Wood wrote: > On 09/19/2011 05:31 PM, Marek Vasut wrote: > > On Monday, September 19, 2011 08:13:45 PM Scott Wood wrote: > >> On 09/16/2011 05:48 PM, Marek Vasut wrote: > >>> The stuff in arch/arm/cpu should be exactly what you need, nothing more > >>> ! > >> > >> This is "spl/", not "arch/arm/spl/", so let's not reason from one > >> architecture, much less the subset of that architecture that has already > >> been made to work with spl/ -- there are 14 different instances of > >> arch/arm/cpu/$(CPU). > > > > I don't think I follow you on this one really -- are we still discussing > > the inclusion/non-inclusion of the cpu-specific library in the SPL, > > right ? > > We're discussing CONFIG_SPL_NO_CPU_SUPPORT_CODE and its use in > spl/Makefile. > > >> We will not want everything we normally pull from > >> arch/powerpc/cpu/mpc85xx to go into an 85xx NAND SPL, for example. But > >> we will want some small portion of it. > > > > 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. > > Board config headers should set appropriate symbols indicating what > parts of arch/$(ARCH)/cpu/$(CPU) they want during an SPL build (at > whatever granularity is appropriate). If that's an empty set, then so > be it, no need to avoid the directory altogether. > > >> 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. > > -Scott
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
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
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? 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
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
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.
On 10/05/2011 04:44 PM, Tom Rini wrote: > 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: >>> 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. A header with common opt-ins would be good -- possibly have a small number of common "profiles" for typical types of SPL, and/or high-level feature #ifdefs that #define the components required to enable them. Also, an opt-out might be more palatable if it is local to this particular CPU makefile, and indicates what specifically is being opted out of -- what constitutes a "CPU support library" is vague from a target-independent view. I guess what you're really trying to replace is the initial entry code, with something provided under board/? Only the cpu makefile knows which files are initial entry versus other CPU-specific things. -Scott
On Thursday, October 06, 2011 12:02:17 AM Scott Wood wrote: > On 10/05/2011 04:44 PM, Tom Rini wrote: > > 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: > >>> 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. > > A header with common opt-ins would be good -- possibly have a small > number of common "profiles" for typical types of SPL, and/or high-level > feature #ifdefs that #define the components required to enable them. > > Also, an opt-out might be more palatable if it is local to this > particular CPU makefile, and indicates what specifically is being opted > out of -- what constitutes a "CPU support library" is vague from a > target-independent view. > > I guess what you're really trying to replace is the initial entry code, > with something provided under board/? Only the cpu makefile knows which > files are initial entry versus other CPU-specific things. > > -Scott Very well then, who's preparing the profiles? Also, the CPU-library will then be composed of no files, will the makefiles handle empty COBJS ? Cheers
diff --git a/spl/Makefile b/spl/Makefile index 56d8ea1..63d1a8a 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -20,6 +20,11 @@ export CONFIG_SPL_BUILD include $(TOPDIR)/config.mk +# In case we want to avoid the CPU support code, we need to define this: +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE +SPL_CPU_SUPPORT_CODE := y +endif + # We want the final binaries in this directory obj := $(OBJTREE)/spl/ @@ -35,7 +40,7 @@ endif START := $(START_PATH)/start.o LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o -LIBS-y += $(CPUDIR)/lib$(CPU).o +LIBS-$(SPL_CPU_SUPPORT_CODE) += $(CPUDIR)/lib$(CPU).o ifdef SOC LIBS-y += $(CPUDIR)/$(SOC)/lib$(SOC).o endif
Introduce CONFIG_SPL_NO_CPU_SUPPORT_CODE to avoid compiling the CPU support library. This can be useful on some setups. Signed-off-by: Marek Vasut <marek.vasut@gmail.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: Detlev Zundel <dzu@denx.de> Cc: Chander Kashyap <chander.kashyap@linaro.org> --- spl/Makefile | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)