This series introduces a few modifications to the new SPL framework to make it a bit more flexible.
RESEND: Missing Cc-ed people in the patches.
Marek Vasut (2): SPL: Make path to start.S configurable SPL: Allow user to disable CPU support library
spl/Makefile | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-)
Introduce CONFIG_SPL_START_S_PATH to configure path to start.S file. It's not always fitting to use CPU's start.S .
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 | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/spl/Makefile b/spl/Makefile index 95ecce1..56d8ea1 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -26,7 +26,13 @@ obj := $(OBJTREE)/spl/ HAVE_VENDOR_COMMON_LIB := $(shell [ -f $(SRCTREE)/board/$(VENDOR)/common/Makefile ] \ && echo y || echo n)
-START := $(CPUDIR)/start.o +ifdef CONFIG_SPL_START_S_PATH +START_PATH := $(subst ",,$(CONFIG_SPL_START_S_PATH)) +else +START_PATH := $(CPUDIR) +endif + +START := $(START_PATH)/start.o
LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o LIBS-y += $(CPUDIR)/lib$(CPU).o @@ -119,7 +125,7 @@ $(obj)u-boot-spl: depend $(START) $(LIBS) $(obj)u-boot-spl.lds $(GEN_UBOOT)
$(START): depend - $(MAKE) -C $(SRCTREE)/$(CPUDIR) $@ + $(MAKE) -C $(SRCTREE)/$(START_PATH) $@
$(LIBS): depend $(MAKE) -C $(SRCTREE)$(dir $(subst $(SPLTREE),,$@))
Dear Marek Vasut,
In message 1315800204-19705-2-git-send-email-marek.vasut@gmail.com you wrote:
Introduce CONFIG_SPL_START_S_PATH to configure path to start.S file. It's not always fitting to use CPU's start.S .
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 | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
In message 20111005190852.9AD2B18E5B48@gemini.denx.de you wrote:
Dear Marek Vasut,
In message 1315800204-19705-2-git-send-email-marek.vasut@gmail.com you wrote:
Introduce CONFIG_SPL_START_S_PATH to configure path to start.S file. It's not always fitting to use CPU's start.S .
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 | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-)
Applied, thanks.
No sorry, I backjed out this commit again. It causes compile warnings, for example:
running MAKEALL TQM860L Configuring for TQM860L board... aisimage.c: In function 'ais_insert_cmd_header': aisimage.c:183:11: warning: variable 'len_cmd' set but not used [-Wunused-but-set-variable]
5bf222bcf7889c73771b291dbfda6be2567a915d is the first bad commit commit 5bf222bcf7889c73771b291dbfda6be2567a915d Author: Marek Vasut marek.vasut@gmail.com Date: Sun Sep 11 17:56:19 2011 +0000
SPL: Make path to start.S configurable
Best regards,
Wolfgang Denk
Dear Marek,
In message 20111005200736.8FCE418E5B48@gemini.denx.de you wrote:
No sorry, I backjed out this commit again. It causes compile warnings, for example:
running MAKEALL TQM860L Configuring for TQM860L board... aisimage.c: In function 'ais_insert_cmd_header': aisimage.c:183:11: warning: variable 'len_cmd' set but not used [-Wunused-but-set-variable]
oops. Sorry, false alarm. We cannot use "git bisect run MAKEALL" when only wanrings are issued :-(
Looking manually for the real culprit.
Best regards,
Wolfgang Denk
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(-)
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
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
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: Scott Wood scottwood@freescale.com --- spl/Makefile | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/spl/Makefile b/spl/Makefile index 91dd11a..fc9360f 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -18,6 +18,11 @@ CONFIG_SPL_BUILD := y export CONFIG_SPL_BUILD
+# In case we want to avoid the CPU support code, we need to define this: +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +export CONFIG_SPL_NO_CPU_SUPPORT_CODE +endif + include $(TOPDIR)/config.mk
# We want the final binaries in this directory
This allows the SPL to avoid compiling in the CPU support code.
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: Scott Wood scottwood@freescale.com --- arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif + SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Marek,
Le 06/10/2011 02:13, Marek Vasut a écrit :
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasutmarek.vasut@gmail.com Cc: Stefano Babicsbabic@denx.de Cc: Wolfgang Denkwd@denx.de Cc: Detlev Zundeldzu@denx.de Cc: Scott Woodscottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif
- SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
cpu.c basically contains one cache management function and one linux-boot-related function probably better suited in bootm... Rather than adding a config option to avoid compiling cpu.c, should we not simply move the functions where they belong?
Amicalement,
On Tuesday, October 18, 2011 11:33:59 PM Albert ARIBAUD wrote:
Hi Marek,
Le 06/10/2011 02:13, Marek Vasut a écrit :
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasutmarek.vasut@gmail.com Cc: Stefano Babicsbabic@denx.de Cc: Wolfgang Denkwd@denx.de Cc: Detlev Zundeldzu@denx.de Cc: Scott Woodscottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
cpu.c basically contains one cache management function and one linux-boot-related function probably better suited in bootm... Rather than adding a config option to avoid compiling cpu.c, should we not simply move the functions where they belong?
I expect the cache management functions to be moved with the ARM926 cache stuff by Hong ... though there is not much activity recently :-(
Amicalement,
On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
This allows the SPL to avoid compiling in the CPU support code.
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: Scott Wood scottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Albert,
can we get this applied please?
Cheers
Hi Marek,
Le 21/10/2011 22:44, Marek Vasut a écrit :
On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasutmarek.vasut@gmail.com Cc: Stefano Babicsbabic@denx.de Cc: Wolfgang Denkwd@denx.de Cc: Detlev Zundeldzu@denx.de Cc: Scott Woodscottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif
- SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Albert,
can we get this applied please?
I still don't understand what this is supposed to do -- why not linking this code is required.
Amicalement,
On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
Hi Marek,
Le 21/10/2011 22:44, Marek Vasut a écrit :
On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasutmarek.vasut@gmail.com Cc: Stefano Babicsbabic@denx.de Cc: Wolfgang Denkwd@denx.de Cc: Detlev Zundeldzu@denx.de Cc: Scott Woodscottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Albert,
can we get this applied please?
I still don't understand what this is supposed to do -- why not linking this code is required.
Amicalement,
Hi Albert,
I use very different start.S in SPL. And I don't need cpu.o at all.
Cheers
Le 22/10/2011 00:00, Marek Vasut a écrit :
On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
Hi Marek,
Le 21/10/2011 22:44, Marek Vasut a écrit :
On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasutmarek.vasut@gmail.com Cc: Stefano Babicsbabic@denx.de Cc: Wolfgang Denkwd@denx.de Cc: Detlev Zundeldzu@denx.de Cc: Scott Woodscottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Albert,
can we get this applied please?
I still don't understand what this is supposed to do -- why not linking this code is required.
Amicalement,
Hi Albert,
I use very different start.S in SPL. And I don't need cpu.o at all.
That I understand; but is there a /problem/ in linking cpu.o in?
Cheers
Amicalement,
On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:00, Marek Vasut a écrit :
On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
Hi Marek,
Le 21/10/2011 22:44, Marek Vasut a écrit :
On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasutmarek.vasut@gmail.com Cc: Stefano Babicsbabic@denx.de Cc: Wolfgang Denkwd@denx.de Cc: Detlev Zundeldzu@denx.de Cc: Scott Woodscottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Albert,
can we get this applied please?
I still don't understand what this is supposed to do -- why not linking this code is required.
Amicalement,
Hi Albert,
I use very different start.S in SPL. And I don't need cpu.o at all.
That I understand; but is there a /problem/ in linking cpu.o in?
I suppose it'll be optimized out at link time ?
Cheers
Le 22/10/2011 00:46, Marek Vasut a écrit :
On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:00, Marek Vasut a écrit :
On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
Hi Marek,
Le 21/10/2011 22:44, Marek Vasut a écrit :
On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote:
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasutmarek.vasut@gmail.com Cc: Stefano Babicsbabic@denx.de Cc: Wolfgang Denkwd@denx.de Cc: Detlev Zundeldzu@denx.de Cc: Scott Woodscottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
START = start.o COBJS = cpu.o+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +COBJS := +endif +endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Albert,
can we get this applied please?
I still don't understand what this is supposed to do -- why not linking this code is required.
Amicalement,
Hi Albert,
I use very different start.S in SPL. And I don't need cpu.o at all.
That I understand; but is there a /problem/ in linking cpu.o in?
I suppose it'll be optimized out at link time ?
That indirectly answers my question: what you want to achieve is removing dead code.
Now, about your question, you can check this if you build the board you intend to apply this to, and do an objdump of the generated SPL: you'll see if the cpu.o functions are present or not.
(my point being that if cpu.o is to disappear because its functions are either useless or should move elsewhere, then the interest of a patch making cpu.o optional is short-lived.)
Cheers
Amicalement,
On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:46, Marek Vasut a écrit :
On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:00, Marek Vasut a écrit :
On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
Hi Marek,
Le 21/10/2011 22:44, Marek Vasut a écrit :
On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote: > This allows the SPL to avoid compiling in the CPU support code. > > Signed-off-by: Marek Vasutmarek.vasut@gmail.com > Cc: Stefano Babicsbabic@denx.de > Cc: Wolfgang Denkwd@denx.de > Cc: Detlev Zundeldzu@denx.de > Cc: Scott Woodscottwood@freescale.com > --- > > arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/cpu/arm926ejs/Makefile > b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 > --- a/arch/arm/cpu/arm926ejs/Makefile > +++ b/arch/arm/cpu/arm926ejs/Makefile > @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o > > START = start.o > COBJS = cpu.o > > +ifdef CONFIG_SPL_BUILD > +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE > +START := > +COBJS := > +endif > +endif > + > > SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) > OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) > START := $(addprefix $(obj),$(START))
Hi Albert,
can we get this applied please?
I still don't understand what this is supposed to do -- why not linking this code is required.
Amicalement,
Hi Albert,
I use very different start.S in SPL. And I don't need cpu.o at all.
That I understand; but is there a /problem/ in linking cpu.o in?
I suppose it'll be optimized out at link time ?
That indirectly answers my question: what you want to achieve is removing dead code.
The code IS USED in U-Boot, but IS NOT USED in SPL !
Now, about your question, you can check this if you build the board you intend to apply this to, and do an objdump of the generated SPL: you'll see if the cpu.o functions are present or not.
(my point being that if cpu.o is to disappear because its functions are either useless or should move elsewhere, then the interest of a patch making cpu.o optional is short-lived.)
I just prodded Hong about his cache patches.
Cheers
Amicalement,
On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasut marek.vasut@gmail.com wrote:
On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:46, Marek Vasut a écrit :
On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:00, Marek Vasut a écrit :
On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote:
Hi Marek,
Le 21/10/2011 22:44, Marek Vasut a écrit : > On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote: >> This allows the SPL to avoid compiling in the CPU support code. >> >> Signed-off-by: Marek Vasutmarek.vasut@gmail.com >> Cc: Stefano Babicsbabic@denx.de >> Cc: Wolfgang Denkwd@denx.de >> Cc: Detlev Zundeldzu@denx.de >> Cc: Scott Woodscottwood@freescale.com >> --- >> >> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ >> 1 files changed, 7 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/cpu/arm926ejs/Makefile >> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 >> --- a/arch/arm/cpu/arm926ejs/Makefile >> +++ b/arch/arm/cpu/arm926ejs/Makefile >> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o >> >> START = start.o >> COBJS = cpu.o >> >> +ifdef CONFIG_SPL_BUILD >> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE >> +START := >> +COBJS := >> +endif >> +endif >> + >> >> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) >> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) >> START := $(addprefix $(obj),$(START)) > > Hi Albert, > > can we get this applied please?
I still don't understand what this is supposed to do -- why not linking this code is required.
Amicalement,
Hi Albert,
I use very different start.S in SPL. And I don't need cpu.o at all.
That I understand; but is there a /problem/ in linking cpu.o in?
I suppose it'll be optimized out at link time ?
That indirectly answers my question: what you want to achieve is removing dead code.
The code IS USED in U-Boot, but IS NOT USED in SPL !
Right, but linked and unused code in SPL is (or should be!) thrown away, is what's trying to be driven home right now. If the file is going to go away, and it's compiled thrown away at final link of SPL, lets just ignore that it exists for a little longer, and then it won't.
On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote:
On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasut marek.vasut@gmail.com wrote:
On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:46, Marek Vasut a écrit :
On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:00, Marek Vasut a écrit :
On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote: > Hi Marek, > > Le 21/10/2011 22:44, Marek Vasut a écrit : >> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote: >>> This allows the SPL to avoid compiling in the CPU support code. >>> >>> Signed-off-by: Marek Vasutmarek.vasut@gmail.com >>> Cc: Stefano Babicsbabic@denx.de >>> Cc: Wolfgang Denkwd@denx.de >>> Cc: Detlev Zundeldzu@denx.de >>> Cc: Scott Woodscottwood@freescale.com >>> --- >>> >>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ >>> 1 files changed, 7 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/cpu/arm926ejs/Makefile >>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 >>> --- a/arch/arm/cpu/arm926ejs/Makefile >>> +++ b/arch/arm/cpu/arm926ejs/Makefile >>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o >>> >>> START = start.o >>> COBJS = cpu.o >>> >>> +ifdef CONFIG_SPL_BUILD >>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE >>> +START := >>> +COBJS := >>> +endif >>> +endif >>> + >>> >>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) >>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) >>> START := $(addprefix $(obj),$(START)) >> >> Hi Albert, >> >> can we get this applied please? > > I still don't understand what this is supposed to do -- why not > linking this code is required. > > Amicalement,
Hi Albert,
I use very different start.S in SPL. And I don't need cpu.o at all.
That I understand; but is there a /problem/ in linking cpu.o in?
I suppose it'll be optimized out at link time ?
That indirectly answers my question: what you want to achieve is removing dead code.
The code IS USED in U-Boot, but IS NOT USED in SPL !
Right, but linked and unused code in SPL is (or should be!) thrown away, is what's trying to be driven home right now. If the file is going to go away, and it's compiled thrown away at final link of SPL, lets just ignore that it exists for a little longer, and then it won't.
My distrust towards compiler abilities to optimize such stuff out tells me it's better to avoid it even to be compiled in at all.
Le 22/10/2011 02:19, Marek Vasut a écrit :
On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote:
On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasutmarek.vasut@gmail.com wrote:
On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:46, Marek Vasut a écrit :
On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:00, Marek Vasut a écrit : > On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote: >> Hi Marek, >> >> Le 21/10/2011 22:44, Marek Vasut a écrit : >>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote: >>>> This allows the SPL to avoid compiling in the CPU support code. >>>> >>>> Signed-off-by: Marek Vasutmarek.vasut@gmail.com >>>> Cc: Stefano Babicsbabic@denx.de >>>> Cc: Wolfgang Denkwd@denx.de >>>> Cc: Detlev Zundeldzu@denx.de >>>> Cc: Scott Woodscottwood@freescale.com >>>> --- >>>> >>>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ >>>> 1 files changed, 7 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile >>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 >>>> --- a/arch/arm/cpu/arm926ejs/Makefile >>>> +++ b/arch/arm/cpu/arm926ejs/Makefile >>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o >>>> >>>> START = start.o >>>> COBJS = cpu.o >>>> >>>> +ifdef CONFIG_SPL_BUILD >>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE >>>> +START := >>>> +COBJS := >>>> +endif >>>> +endif >>>> + >>>> >>>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) >>>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) >>>> START := $(addprefix $(obj),$(START)) >>> >>> Hi Albert, >>> >>> can we get this applied please? >> >> I still don't understand what this is supposed to do -- why not >> linking this code is required. >> >> Amicalement, > > Hi Albert, > > I use very different start.S in SPL. And I don't need cpu.o at all.
That I understand; but is there a /problem/ in linking cpu.o in?
I suppose it'll be optimized out at link time ?
That indirectly answers my question: what you want to achieve is removing dead code.
The code IS USED in U-Boot, but IS NOT USED in SPL !
Right, but linked and unused code in SPL is (or should be!) thrown away, is what's trying to be driven home right now. If the file is going to go away, and it's compiled thrown away at final link of SPL, lets just ignore that it exists for a little longer, and then it won't.
My distrust towards compiler abilities to optimize such stuff out tells me it's better to avoid it even to be compiled in at all.
Optimizing unused functions is a rather simple and reliable ability in tolchains. The issue is not really whether the toolchain is able to do the removal (it is); rather, the issue is whether the linker command line will cause the removal (it will IMO as long as -gc-sections is specified).
Amicalement,
On Saturday, October 22, 2011 02:41:54 AM Albert ARIBAUD wrote:
Le 22/10/2011 02:19, Marek Vasut a écrit :
On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote:
On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasutmarek.vasut@gmail.com wrote:
On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:46, Marek Vasut a écrit :
On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote: > Le 22/10/2011 00:00, Marek Vasut a écrit : >> On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote: >>> Hi Marek, >>> >>> Le 21/10/2011 22:44, Marek Vasut a écrit : >>>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote: >>>>> This allows the SPL to avoid compiling in the CPU support code. >>>>> >>>>> Signed-off-by: Marek Vasutmarek.vasut@gmail.com >>>>> Cc: Stefano Babicsbabic@denx.de >>>>> Cc: Wolfgang Denkwd@denx.de >>>>> Cc: Detlev Zundeldzu@denx.de >>>>> Cc: Scott Woodscottwood@freescale.com >>>>> --- >>>>> >>>>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ >>>>> 1 files changed, 7 insertions(+), 0 deletions(-) >>>>> >>>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile >>>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 >>>>> --- a/arch/arm/cpu/arm926ejs/Makefile >>>>> +++ b/arch/arm/cpu/arm926ejs/Makefile >>>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o >>>>> >>>>> START = start.o >>>>> COBJS = cpu.o >>>>> >>>>> +ifdef CONFIG_SPL_BUILD >>>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE >>>>> +START := >>>>> +COBJS := >>>>> +endif >>>>> +endif >>>>> + >>>>> >>>>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) >>>>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) >>>>> START := $(addprefix $(obj),$(START)) >>>> >>>> Hi Albert, >>>> >>>> can we get this applied please? >>> >>> I still don't understand what this is supposed to do -- why not >>> linking this code is required. >>> >>> Amicalement, >> >> Hi Albert, >> >> I use very different start.S in SPL. And I don't need cpu.o at all. > > That I understand; but is there a /problem/ in linking cpu.o in?
I suppose it'll be optimized out at link time ?
That indirectly answers my question: what you want to achieve is removing dead code.
The code IS USED in U-Boot, but IS NOT USED in SPL !
Right, but linked and unused code in SPL is (or should be!) thrown away, is what's trying to be driven home right now. If the file is going to go away, and it's compiled thrown away at final link of SPL, lets just ignore that it exists for a little longer, and then it won't.
My distrust towards compiler abilities to optimize such stuff out tells me it's better to avoid it even to be compiled in at all.
Optimizing unused functions is a rather simple and reliable ability in tolchains. The issue is not really whether the toolchain is able to do the removal (it is); rather, the issue is whether the linker command line will cause the removal (it will IMO as long as -gc-sections is specified).
Amicalement,
So what you suggest is to leave cpu.o compiling and drop only start.S ?
Cheers
Le 22/10/2011 03:20, Marek Vasut a écrit :
On Saturday, October 22, 2011 02:41:54 AM Albert ARIBAUD wrote:
Le 22/10/2011 02:19, Marek Vasut a écrit :
On Saturday, October 22, 2011 02:04:52 AM Tom Rini wrote:
On Fri, Oct 21, 2011 at 4:45 PM, Marek Vasutmarek.vasut@gmail.com wrote:
On Saturday, October 22, 2011 01:08:43 AM Albert ARIBAUD wrote:
Le 22/10/2011 00:46, Marek Vasut a écrit : > On Saturday, October 22, 2011 12:44:06 AM Albert ARIBAUD wrote: >> Le 22/10/2011 00:00, Marek Vasut a écrit : >>> On Friday, October 21, 2011 11:52:23 PM Albert ARIBAUD wrote: >>>> Hi Marek, >>>> >>>> Le 21/10/2011 22:44, Marek Vasut a écrit : >>>>> On Thursday, October 06, 2011 02:13:26 AM Marek Vasut wrote: >>>>>> This allows the SPL to avoid compiling in the CPU support code. >>>>>> >>>>>> Signed-off-by: Marek Vasutmarek.vasut@gmail.com >>>>>> Cc: Stefano Babicsbabic@denx.de >>>>>> Cc: Wolfgang Denkwd@denx.de >>>>>> Cc: Detlev Zundeldzu@denx.de >>>>>> Cc: Scott Woodscottwood@freescale.com >>>>>> --- >>>>>> >>>>>> arch/arm/cpu/arm926ejs/Makefile | 7 +++++++ >>>>>> 1 files changed, 7 insertions(+), 0 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm/cpu/arm926ejs/Makefile >>>>>> b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644 >>>>>> --- a/arch/arm/cpu/arm926ejs/Makefile >>>>>> +++ b/arch/arm/cpu/arm926ejs/Makefile >>>>>> @@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o >>>>>> >>>>>> START = start.o >>>>>> COBJS = cpu.o >>>>>> >>>>>> +ifdef CONFIG_SPL_BUILD >>>>>> +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE >>>>>> +START := >>>>>> +COBJS := >>>>>> +endif >>>>>> +endif >>>>>> + >>>>>> >>>>>> SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) >>>>>> OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) >>>>>> START := $(addprefix $(obj),$(START)) >>>>> >>>>> Hi Albert, >>>>> >>>>> can we get this applied please? >>>> >>>> I still don't understand what this is supposed to do -- why not >>>> linking this code is required. >>>> >>>> Amicalement, >>> >>> Hi Albert, >>> >>> I use very different start.S in SPL. And I don't need cpu.o at all. >> >> That I understand; but is there a /problem/ in linking cpu.o in? > > I suppose it'll be optimized out at link time ?
That indirectly answers my question: what you want to achieve is removing dead code.
The code IS USED in U-Boot, but IS NOT USED in SPL !
Right, but linked and unused code in SPL is (or should be!) thrown away, is what's trying to be driven home right now. If the file is going to go away, and it's compiled thrown away at final link of SPL, lets just ignore that it exists for a little longer, and then it won't.
My distrust towards compiler abilities to optimize such stuff out tells me it's better to avoid it even to be compiled in at all.
Optimizing unused functions is a rather simple and reliable ability in tolchains. The issue is not really whether the toolchain is able to do the removal (it is); rather, the issue is whether the linker command line will cause the removal (it will IMO as long as -gc-sections is specified).
Amicalement,
So what you suggest is to leave cpu.o compiling and drop only start.S ?
Yes -- once you're sure that -gc-sections is there.
Cheers
Amicalement,
This allows the SPL to avoid compiling in the CPU support code.
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: Scott Wood scottwood@freescale.com --- arch/arm/cpu/arm926ejs/Makefile | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
V2: Don't frob with cpu.o as it's going to be removed anyway.
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..a56ff08 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,12 @@ LIB = $(obj)lib$(CPU).o START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +endif +endif + SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
This allows the SPL to avoid compiling in the CPU support code.
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: Scott Wood scottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
V2: Don't frob with cpu.o as it's going to be removed anyway.
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..a56ff08 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,12 @@ LIB = $(obj)lib$(CPU).o START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +endif +endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Albert,
can you apply please?
Thanks
This allows the SPL to avoid compiling in the CPU support code.
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: Scott Wood scottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
V2: Don't frob with cpu.o as it's going to be removed anyway.
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..a56ff08 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,12 @@ LIB = $(obj)lib$(CPU).o
START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +endif +endif
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Hi Albert,
can you apply please?
Thanks
Ping ?
Hi Marek,
Le 24/10/2011 12:14, Marek Vasut a écrit :
This allows the SPL to avoid compiling in the CPU support code.
Signed-off-by: Marek Vasutmarek.vasut@gmail.com Cc: Stefano Babicsbabic@denx.de Cc: Wolfgang Denkwd@denx.de Cc: Detlev Zundeldzu@denx.de Cc: Scott Woodscottwood@freescale.com
arch/arm/cpu/arm926ejs/Makefile | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)
V2: Don't frob with cpu.o as it's going to be removed anyway.
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..a56ff08 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -28,6 +28,12 @@ LIB = $(obj)lib$(CPU).o START = start.o COBJS = cpu.o
+ifdef CONFIG_SPL_BUILD +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +START := +endif +endif
- SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START))
Applied to u-boot-arm/master, thanks!
Amicalement,
On 10/05/2011 07:13 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: Scott Wood scottwood@freescale.com
spl/Makefile | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/spl/Makefile b/spl/Makefile index 91dd11a..fc9360f 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -18,6 +18,11 @@ CONFIG_SPL_BUILD := y export CONFIG_SPL_BUILD
+# In case we want to avoid the CPU support code, we need to define this: +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +export CONFIG_SPL_NO_CPU_SUPPORT_CODE +endif
Why do we need this here, but not for other config symbols that subordinate makefiles use (e.g. in the normal, non-SPL case)?
Shouldn't the cpu makefile include config.mk, which includes autoconf.mk, which defines this symbol?
-Scott
On Thursday, October 06, 2011 05:54:17 PM Scott Wood wrote:
On 10/05/2011 07:13 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: Scott Wood scottwood@freescale.com
spl/Makefile | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/spl/Makefile b/spl/Makefile index 91dd11a..fc9360f 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -18,6 +18,11 @@
CONFIG_SPL_BUILD := y export CONFIG_SPL_BUILD
+# In case we want to avoid the CPU support code, we need to define this: +ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE +export CONFIG_SPL_NO_CPU_SUPPORT_CODE +endif
Why do we need this here, but not for other config symbols that subordinate makefiles use (e.g. in the normal, non-SPL case)?
Shouldn't the cpu makefile include config.mk, which includes autoconf.mk, which defines this symbol?
-Scott
Right, you can ignore this patch and apply only 2/2.
Cheers
On Monday, September 12, 2011 06:03:22 AM Marek Vasut wrote:
This series introduces a few modifications to the new SPL framework to make it a bit more flexible.
RESEND: Missing Cc-ed people in the patches.
Marek Vasut (2): SPL: Make path to start.S configurable SPL: Allow user to disable CPU support library
spl/Makefile | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-)
This is the resent series. Sorry, forgot to mention it in the cover letter.
On Monday, September 12, 2011 06:03:22 AM Marek Vasut wrote:
This series introduces a few modifications to the new SPL framework to make it a bit more flexible.
RESEND: Missing Cc-ed people in the patches.
Marek Vasut (2): SPL: Make path to start.S configurable SPL: Allow user to disable CPU support library
spl/Makefile | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-)
Hi,
Wolfgang, can you please apply the series?
Thanks
Dear Marek Vasut,
In message 201110051304.16386.marek.vasut@gmail.com you wrote:
On Monday, September 12, 2011 06:03:22 AM Marek Vasut wrote:
This series introduces a few modifications to the new SPL framework to make it a bit more flexible.
RESEND: Missing Cc-ed people in the patches.
Marek Vasut (2): SPL: Make path to start.S configurable SPL: Allow user to disable CPU support library
spl/Makefile | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-)
Wolfgang, can you please apply the series?
I hesitate to apply
[PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library http://article.gmane.org/gmane.comp.boot-loaders.u-boot/108058
I think no agreement has been reached between you and Scott?
Best regards,
Wolfgang Denk
participants (5)
-
Albert ARIBAUD -
Marek Vasut -
Scott Wood -
Tom Rini -
Wolfgang Denk