* [U-Boot] [PATCH 0/2] SPL improvements
@ 2011-09-12 4:03 Marek Vasut
2011-09-12 4:03 ` [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable Marek Vasut
` (3 more replies)
0 siblings, 4 replies; 50+ messages in thread
From: Marek Vasut @ 2011-09-12 4:03 UTC (permalink / raw)
To: u-boot
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(-)
--
1.7.5.4
^ permalink raw reply [flat|nested] 50+ messages in thread* [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable 2011-09-12 4:03 [U-Boot] [PATCH 0/2] SPL improvements Marek Vasut @ 2011-09-12 4:03 ` Marek Vasut 2011-10-05 19:08 ` Wolfgang Denk 2011-09-12 4:03 ` [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library Marek Vasut ` (2 subsequent siblings) 3 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-12 4:03 UTC (permalink / raw) To: u-boot 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),,$@)) -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable 2011-09-12 4:03 ` [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable Marek Vasut @ 2011-10-05 19:08 ` Wolfgang Denk 2011-10-05 20:07 ` Wolfgang Denk 0 siblings, 1 reply; 50+ messages in thread From: Wolfgang Denk @ 2011-10-05 19:08 UTC (permalink / raw) To: u-boot 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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de C++ is the best example of second-system effect since OS/360. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable 2011-10-05 19:08 ` Wolfgang Denk @ 2011-10-05 20:07 ` Wolfgang Denk 2011-10-05 20:15 ` Wolfgang Denk 0 siblings, 1 reply; 50+ messages in thread From: Wolfgang Denk @ 2011-10-05 20:07 UTC (permalink / raw) To: u-boot 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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "If God had wanted us to use the metric system, Jesus would have had 10 apostles." ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable 2011-10-05 20:07 ` Wolfgang Denk @ 2011-10-05 20:15 ` Wolfgang Denk 0 siblings, 0 replies; 50+ messages in thread From: Wolfgang Denk @ 2011-10-05 20:15 UTC (permalink / raw) To: u-boot 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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Make it right before you make it faster. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-12 4:03 [U-Boot] [PATCH 0/2] SPL improvements Marek Vasut 2011-09-12 4:03 ` [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable Marek Vasut @ 2011-09-12 4:03 ` Marek Vasut 2011-09-15 22:57 ` Scott Wood 2011-10-06 0:13 ` [U-Boot] [PATCH 1/2] " Marek Vasut 2011-09-12 4:12 ` [U-Boot] [PATCH 0/2] SPL improvements Marek Vasut 2011-10-05 11:04 ` Marek Vasut 3 siblings, 2 replies; 50+ messages in thread From: Marek Vasut @ 2011-09-12 4:03 UTC (permalink / raw) To: u-boot 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 -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-12 4:03 ` [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library Marek Vasut @ 2011-09-15 22:57 ` Scott Wood 2011-09-15 23:17 ` Marek Vasut 2011-10-06 0:13 ` [U-Boot] [PATCH 1/2] " Marek Vasut 1 sibling, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-09-15 22:57 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-15 22:57 ` Scott Wood @ 2011-09-15 23:17 ` Marek Vasut 2011-09-16 19:49 ` Scott Wood 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-15 23:17 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-15 23:17 ` Marek Vasut @ 2011-09-16 19:49 ` Scott Wood 2011-09-16 21:38 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-09-16 19:49 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-16 19:49 ` Scott Wood @ 2011-09-16 21:38 ` Marek Vasut 2011-09-16 21:42 ` Scott Wood 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-16 21:38 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-16 21:38 ` Marek Vasut @ 2011-09-16 21:42 ` Scott Wood 2011-09-16 21:47 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-09-16 21:42 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-16 21:42 ` Scott Wood @ 2011-09-16 21:47 ` Marek Vasut 2011-09-16 22:07 ` Scott Wood 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-16 21:47 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-16 21:47 ` Marek Vasut @ 2011-09-16 22:07 ` Scott Wood 2011-09-16 22:48 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-09-16 22:07 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-16 22:07 ` Scott Wood @ 2011-09-16 22:48 ` Marek Vasut 2011-09-19 18:13 ` Scott Wood 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-16 22:48 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-16 22:48 ` Marek Vasut @ 2011-09-19 18:13 ` Scott Wood 2011-09-19 22:31 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-09-19 18:13 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-19 18:13 ` Scott Wood @ 2011-09-19 22:31 ` Marek Vasut 2011-09-20 19:12 ` Scott Wood 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-19 22:31 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-19 22:31 ` Marek Vasut @ 2011-09-20 19:12 ` Scott Wood 2011-09-20 21:16 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-09-20 19:12 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-20 19:12 ` Scott Wood @ 2011-09-20 21:16 ` Marek Vasut 2011-09-20 21:23 ` Scott Wood 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-20 21:16 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-20 21:16 ` Marek Vasut @ 2011-09-20 21:23 ` Scott Wood 2011-09-20 21:30 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-09-20 21:23 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-20 21:23 ` Scott Wood @ 2011-09-20 21:30 ` Marek Vasut 2011-09-20 23:31 ` Scott Wood 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-20 21:30 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-20 21:30 ` Marek Vasut @ 2011-09-20 23:31 ` Scott Wood 2011-09-22 8:52 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-09-20 23:31 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-20 23:31 ` Scott Wood @ 2011-09-22 8:52 ` Marek Vasut 2011-10-05 21:44 ` Tom Rini 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-09-22 8:52 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-09-22 8:52 ` Marek Vasut @ 2011-10-05 21:44 ` Tom Rini 2011-10-05 22:02 ` Scott Wood 0 siblings, 1 reply; 50+ messages in thread From: Tom Rini @ 2011-10-05 21:44 UTC (permalink / raw) To: u-boot 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. -- Tom ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-10-05 21:44 ` Tom Rini @ 2011-10-05 22:02 ` Scott Wood 2011-10-05 22:20 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-10-05 22:02 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library 2011-10-05 22:02 ` Scott Wood @ 2011-10-05 22:20 ` Marek Vasut 0 siblings, 0 replies; 50+ messages in thread From: Marek Vasut @ 2011-10-05 22:20 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library 2011-09-12 4:03 ` [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library Marek Vasut 2011-09-15 22:57 ` Scott Wood @ 2011-10-06 0:13 ` Marek Vasut 2011-10-06 0:13 ` [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code Marek Vasut 2011-10-06 15:54 ` [U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library Scott Wood 1 sibling, 2 replies; 50+ messages in thread From: Marek Vasut @ 2011-10-06 0:13 UTC (permalink / raw) To: u-boot 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 -- 1.7.6.3 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-06 0:13 ` [U-Boot] [PATCH 1/2] " Marek Vasut @ 2011-10-06 0:13 ` Marek Vasut 2011-10-18 21:33 ` Albert ARIBAUD ` (2 more replies) 2011-10-06 15:54 ` [U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library Scott Wood 1 sibling, 3 replies; 50+ messages in thread From: Marek Vasut @ 2011-10-06 0:13 UTC (permalink / raw) To: u-boot 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)) -- 1.7.6.3 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-06 0:13 ` [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code Marek Vasut @ 2011-10-18 21:33 ` Albert ARIBAUD 2011-10-18 22:30 ` Marek Vasut 2011-10-21 20:44 ` Marek Vasut 2011-10-24 10:14 ` [U-Boot] [PATCH 2/2 V2] " Marek Vasut 2 siblings, 1 reply; 50+ messages in thread From: Albert ARIBAUD @ 2011-10-18 21:33 UTC (permalink / raw) To: u-boot 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 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)) 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, -- Albert. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-18 21:33 ` Albert ARIBAUD @ 2011-10-18 22:30 ` Marek Vasut 0 siblings, 0 replies; 50+ messages in thread From: Marek Vasut @ 2011-10-18 22:30 UTC (permalink / raw) To: u-boot 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 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)) > > 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, ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-06 0:13 ` [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code Marek Vasut 2011-10-18 21:33 ` Albert ARIBAUD @ 2011-10-21 20:44 ` Marek Vasut 2011-10-21 21:52 ` Albert ARIBAUD 2011-10-24 10:14 ` [U-Boot] [PATCH 2/2 V2] " Marek Vasut 2 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-10-21 20:44 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-21 20:44 ` Marek Vasut @ 2011-10-21 21:52 ` Albert ARIBAUD 2011-10-21 22:00 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Albert ARIBAUD @ 2011-10-21 21:52 UTC (permalink / raw) To: u-boot 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 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? I still don't understand what this is supposed to do -- why not linking this code is required. Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-21 21:52 ` Albert ARIBAUD @ 2011-10-21 22:00 ` Marek Vasut 2011-10-21 22:44 ` Albert ARIBAUD 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-10-21 22:00 UTC (permalink / raw) To: u-boot 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 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? > > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-21 22:00 ` Marek Vasut @ 2011-10-21 22:44 ` Albert ARIBAUD 2011-10-21 22:46 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Albert ARIBAUD @ 2011-10-21 22:44 UTC (permalink / raw) To: u-boot 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 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? >> >> 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, -- Albert. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-21 22:44 ` Albert ARIBAUD @ 2011-10-21 22:46 ` Marek Vasut 2011-10-21 23:08 ` Albert ARIBAUD 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-10-21 22:46 UTC (permalink / raw) To: u-boot 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 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? > >> > >> 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-21 22:46 ` Marek Vasut @ 2011-10-21 23:08 ` Albert ARIBAUD 2011-10-21 23:45 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Albert ARIBAUD @ 2011-10-21 23:08 UTC (permalink / raw) To: u-boot 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 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? >>>> >>>> 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, -- Albert. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-21 23:08 ` Albert ARIBAUD @ 2011-10-21 23:45 ` Marek Vasut 2011-10-22 0:04 ` Tom Rini 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-10-21 23:45 UTC (permalink / raw) To: u-boot 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 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? > >>>> > >>>> 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, ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-21 23:45 ` Marek Vasut @ 2011-10-22 0:04 ` Tom Rini 2011-10-22 0:19 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Tom Rini @ 2011-10-22 0:04 UTC (permalink / raw) To: u-boot 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 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? >> >>>> >> >>>> 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. -- Tom ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-22 0:04 ` Tom Rini @ 2011-10-22 0:19 ` Marek Vasut 2011-10-22 0:41 ` Albert ARIBAUD 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-10-22 0:19 UTC (permalink / raw) To: u-boot 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 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? > >> >>>> > >> >>>> 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-22 0:19 ` Marek Vasut @ 2011-10-22 0:41 ` Albert ARIBAUD 2011-10-22 1:20 ` Marek Vasut 0 siblings, 1 reply; 50+ messages in thread From: Albert ARIBAUD @ 2011-10-22 0:41 UTC (permalink / raw) To: u-boot 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 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 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? >>>>>>>> >>>>>>>> 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, -- Albert. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-22 0:41 ` Albert ARIBAUD @ 2011-10-22 1:20 ` Marek Vasut 2011-10-22 7:05 ` Albert ARIBAUD 0 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-10-22 1:20 UTC (permalink / raw) To: u-boot 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 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 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? > >>>>>>>> > >>>>>>>> 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-22 1:20 ` Marek Vasut @ 2011-10-22 7:05 ` Albert ARIBAUD 0 siblings, 0 replies; 50+ messages in thread From: Albert ARIBAUD @ 2011-10-22 7:05 UTC (permalink / raw) To: u-boot 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 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 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? >>>>>>>>>> >>>>>>>>>> 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, -- Albert. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-06 0:13 ` [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code Marek Vasut 2011-10-18 21:33 ` Albert ARIBAUD 2011-10-21 20:44 ` Marek Vasut @ 2011-10-24 10:14 ` Marek Vasut 2011-11-03 0:05 ` Marek Vasut 2011-11-08 21:15 ` Albert ARIBAUD 2 siblings, 2 replies; 50+ messages in thread From: Marek Vasut @ 2011-10-24 10:14 UTC (permalink / raw) To: u-boot 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)) -- 1.7.6.3 ^ permalink raw reply related [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-24 10:14 ` [U-Boot] [PATCH 2/2 V2] " Marek Vasut @ 2011-11-03 0:05 ` Marek Vasut 2011-11-04 13:59 ` Marek Vasut 2011-11-08 21:15 ` Albert ARIBAUD 1 sibling, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-11-03 0:05 UTC (permalink / raw) To: u-boot > 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-11-03 0:05 ` Marek Vasut @ 2011-11-04 13:59 ` Marek Vasut 0 siblings, 0 replies; 50+ messages in thread From: Marek Vasut @ 2011-11-04 13:59 UTC (permalink / raw) To: u-boot > > 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 ? ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code 2011-10-24 10:14 ` [U-Boot] [PATCH 2/2 V2] " Marek Vasut 2011-11-03 0:05 ` Marek Vasut @ 2011-11-08 21:15 ` Albert ARIBAUD 1 sibling, 0 replies; 50+ messages in thread From: Albert ARIBAUD @ 2011-11-08 21:15 UTC (permalink / raw) To: u-boot 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 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)) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library 2011-10-06 0:13 ` [U-Boot] [PATCH 1/2] " Marek Vasut 2011-10-06 0:13 ` [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code Marek Vasut @ 2011-10-06 15:54 ` Scott Wood 2011-10-06 23:35 ` Marek Vasut 1 sibling, 1 reply; 50+ messages in thread From: Scott Wood @ 2011-10-06 15:54 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library 2011-10-06 15:54 ` [U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library Scott Wood @ 2011-10-06 23:35 ` Marek Vasut 0 siblings, 0 replies; 50+ messages in thread From: Marek Vasut @ 2011-10-06 23:35 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 0/2] SPL improvements 2011-09-12 4:03 [U-Boot] [PATCH 0/2] SPL improvements Marek Vasut 2011-09-12 4:03 ` [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable Marek Vasut 2011-09-12 4:03 ` [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library Marek Vasut @ 2011-09-12 4:12 ` Marek Vasut 2011-10-05 11:04 ` Marek Vasut 3 siblings, 0 replies; 50+ messages in thread From: Marek Vasut @ 2011-09-12 4:12 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 0/2] SPL improvements 2011-09-12 4:03 [U-Boot] [PATCH 0/2] SPL improvements Marek Vasut ` (2 preceding siblings ...) 2011-09-12 4:12 ` [U-Boot] [PATCH 0/2] SPL improvements Marek Vasut @ 2011-10-05 11:04 ` Marek Vasut 2011-10-05 19:14 ` Wolfgang Denk 3 siblings, 1 reply; 50+ messages in thread From: Marek Vasut @ 2011-10-05 11:04 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 50+ messages in thread
* [U-Boot] [PATCH 0/2] SPL improvements 2011-10-05 11:04 ` Marek Vasut @ 2011-10-05 19:14 ` Wolfgang Denk 0 siblings, 0 replies; 50+ messages in thread From: Wolfgang Denk @ 2011-10-05 19:14 UTC (permalink / raw) To: u-boot 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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de And now remains That we find out the cause of this effect, Or rather say, the cause of this defect... -- Hamlet, Act II, Scene 2 ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2011-11-08 21:15 UTC | newest] Thread overview: 50+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-12 4:03 [U-Boot] [PATCH 0/2] SPL improvements Marek Vasut 2011-09-12 4:03 ` [U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable Marek Vasut 2011-10-05 19:08 ` Wolfgang Denk 2011-10-05 20:07 ` Wolfgang Denk 2011-10-05 20:15 ` Wolfgang Denk 2011-09-12 4:03 ` [U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library Marek Vasut 2011-09-15 22:57 ` Scott Wood 2011-09-15 23:17 ` Marek Vasut 2011-09-16 19:49 ` Scott Wood 2011-09-16 21:38 ` Marek Vasut 2011-09-16 21:42 ` Scott Wood 2011-09-16 21:47 ` Marek Vasut 2011-09-16 22:07 ` Scott Wood 2011-09-16 22:48 ` Marek Vasut 2011-09-19 18:13 ` Scott Wood 2011-09-19 22:31 ` Marek Vasut 2011-09-20 19:12 ` Scott Wood 2011-09-20 21:16 ` Marek Vasut 2011-09-20 21:23 ` Scott Wood 2011-09-20 21:30 ` Marek Vasut 2011-09-20 23:31 ` Scott Wood 2011-09-22 8:52 ` Marek Vasut 2011-10-05 21:44 ` Tom Rini 2011-10-05 22:02 ` Scott Wood 2011-10-05 22:20 ` Marek Vasut 2011-10-06 0:13 ` [U-Boot] [PATCH 1/2] " Marek Vasut 2011-10-06 0:13 ` [U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code Marek Vasut 2011-10-18 21:33 ` Albert ARIBAUD 2011-10-18 22:30 ` Marek Vasut 2011-10-21 20:44 ` Marek Vasut 2011-10-21 21:52 ` Albert ARIBAUD 2011-10-21 22:00 ` Marek Vasut 2011-10-21 22:44 ` Albert ARIBAUD 2011-10-21 22:46 ` Marek Vasut 2011-10-21 23:08 ` Albert ARIBAUD 2011-10-21 23:45 ` Marek Vasut 2011-10-22 0:04 ` Tom Rini 2011-10-22 0:19 ` Marek Vasut 2011-10-22 0:41 ` Albert ARIBAUD 2011-10-22 1:20 ` Marek Vasut 2011-10-22 7:05 ` Albert ARIBAUD 2011-10-24 10:14 ` [U-Boot] [PATCH 2/2 V2] " Marek Vasut 2011-11-03 0:05 ` Marek Vasut 2011-11-04 13:59 ` Marek Vasut 2011-11-08 21:15 ` Albert ARIBAUD 2011-10-06 15:54 ` [U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library Scott Wood 2011-10-06 23:35 ` Marek Vasut 2011-09-12 4:12 ` [U-Boot] [PATCH 0/2] SPL improvements Marek Vasut 2011-10-05 11:04 ` Marek Vasut 2011-10-05 19:14 ` Wolfgang Denk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox