[U-Boot] [PATCH 0/2] SPL improvements

[U-Boot] [PATCH 0/2] SPL improvements

[Marek Vasut]

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

[U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 0/2] SPL improvements

[Marek Vasut]

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.

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 0/2] SPL improvements

[Marek Vasut]

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

[U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable

[Wolfgang Denk]

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.

[U-Boot] [PATCH 0/2] SPL improvements

[Wolfgang Denk]

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

[U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable

[Wolfgang Denk]

Dear Wolfgang Denk,

In message <20111005190852.9AD2B18E5B48@gemini.denx.de> you wrote:
> Dear Marek Vasut,
> 
> In message <1315800204-19705-2-git-send-email-marek.vasut@gmail.com> you wrote:
> > Introduce CONFIG_SPL_START_S_PATH to configure path to start.S file. It's not
> > always fitting to use CPU's start.S .
> > 
> > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Wolfgang Denk <wd@denx.de>
> > Cc: Detlev Zundel <dzu@denx.de>
> > Cc: Chander Kashyap <chander.kashyap@linaro.org>
> > ---
> >  spl/Makefile |   10 ++++++++--
> >  1 files changed, 8 insertions(+), 2 deletions(-)
> 
> Applied, thanks.

No sorry, I backjed out this commit again.  It causes compile
warnings, for example:

running MAKEALL TQM860L
Configuring for TQM860L board...
aisimage.c: In function 'ais_insert_cmd_header':
aisimage.c:183:11: warning: variable 'len_cmd' set but not used [-Wunused-but-set-variable]

5bf222bcf7889c73771b291dbfda6be2567a915d is the first bad commit
commit 5bf222bcf7889c73771b291dbfda6be2567a915d
Author: Marek Vasut <marek.vasut@gmail.com>
Date:   Sun Sep 11 17:56:19 2011 +0000

    SPL: Make path to start.S configurable


Best regards,

Wolfgang Denk

-- 
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."

[U-Boot] [PATCH 1/2 RESEND] SPL: Make path to start.S configurable

[Wolfgang Denk]

Dear Marek,

In message <20111005200736.8FCE418E5B48@gemini.denx.de> you wrote:
> 
> No sorry, I backjed out this commit again.  It causes compile
> warnings, for example:
> 
> running MAKEALL TQM860L
> Configuring for TQM860L board...
> aisimage.c: In function 'ais_insert_cmd_header':
> aisimage.c:183:11: warning: variable 'len_cmd' set but not used [-Wunused-but-set-variable]

oops. Sorry, false alarm.  We cannot use "git bisect run MAKEALL" when
only wanrings are issued :-(

Looking manually for the real culprit.

Best regards,

Wolfgang Denk

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Tom Rini]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 2/2 RESEND] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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

[U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library

[Scott Wood]

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

[U-Boot] [PATCH 1/2] SPL: Allow user to disable CPU support library

[Marek Vasut]

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

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Albert ARIBAUD]

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.

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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,

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Albert ARIBAUD]

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.

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Albert ARIBAUD]

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.

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Albert ARIBAUD]

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.

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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,

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Tom Rini]

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

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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.

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Albert ARIBAUD]

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.

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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

[U-Boot] [PATCH 2/2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Albert ARIBAUD]

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.

[U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

> 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

[U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Marek Vasut]

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

[U-Boot] [PATCH 2/2 V2] SPL: Allow ARM926EJS to avoid compiling in the CPU support code

[Albert ARIBAUD]

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.