SPL improvements

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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Chander Kashyap <[email protected]>

---
 spl/Makefile |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

Dear Marek Vasut,

Quoted 11 lines · In message <[email protected]> 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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Chander Kashyap <[email protected]>

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

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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Chander Kashyap <[email protected]>

---
 spl/Makefile |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

spl/Makefile +0 -0

index 56d8ea1..63d1a8a 100644

Quoted 8 lines · 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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Chander Kashyap <[email protected]>

But you didn't CC these...

Quoted 14 lines

---

 spl/Makefile |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

spl/Makefile +0 -0

index 56d8ea1..63d1a8a 100644
@@ -20,6 +20,11 @@ export CONFIG_SPL_BUILD
 
 include $(TOPDIR)/config.mk
 

spl/Makefile export CONFIG_SPL_BUILD · line 26

Quoted 4 lines

spl/Makefile +4 -0

+# 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

Quoted 10 lines · Scott Wood

Quoted 8 lines · 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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Chander Kashyap <[email protected]>

Quoted 1 line

But you didn't CC these...

git send-email should handle those ?

Quoted 7 lines

spl/Makefile export CONFIG_SPL_BUILD · line 26

Quoted 4 lines

spl/Makefile +4 -0

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

Quoted 11 lines · Marek Vasut

Quoted 10 lines · Scott Wood

Quoted 8 lines · 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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Chander Kashyap <[email protected]>

Quoted 3 lines

Quoted 1 line

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.

Quoted 11 lines

Quoted 7 lines

spl/Makefile export CONFIG_SPL_BUILD · line 26

Quoted 4 lines

+# In case we want to avoid the CPU support code, we need to define
this: +ifndef CONFIG_SPL_NO_CPU_SUPPORT_CODE

spl/Makefile +2 -0

+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

Quoted 2 lines · Scott Wood

Still, this seems hackish. Shouldn't the control be on specific files that you include, not directories?

I don't think so ... why ?

Quoted 4 lines · Marek Vasut

Quoted 2 lines · Scott Wood

Still, this seems hackish. Shouldn't the control be on specific files that you include, not directories?

Quoted 1 line

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

Quoted 7 lines · Scott Wood

Quoted 5 lines · Marek Vasut

Quoted 2 lines · Scott Wood

Still, this seems hackish. Shouldn't the control be on specific files that you include, not directories?

I don't think so ... why ?

Quoted 5 lines

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.

Quoted 14 lines · Marek Vasut

Quoted 12 lines · Scott Wood

Quoted 5 lines · Marek Vasut

Quoted 2 lines · Scott Wood

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.

Quoted 2 lines

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

Quoted 2 lines · Scott Wood

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.

Quoted 1 line

Quoted 5 lines

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 !

Quoted 12 lines · Marek Vasut

Quoted 2 lines · Scott Wood

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.

Quoted 5 lines

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.

Quoted 1 line

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

Quoted 7 lines · Scott Wood

Quoted 1 line · Marek Vasut

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 ?

Quoted 3 lines

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

Quoted 3 lines

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.

Quoted 5 lines · Marek Vasut

Quoted 4 lines · Scott Wood

Quoted 2 lines · Marek Vasut

The stuff in arch/arm/cpu should be exactly what you need, nothing more !

Quoted 8 lines

Quoted 4 lines

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.

Quoted 4 lines

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 4 lines

Quoted 3 lines

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.

Quoted 2 lines

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

Quoted 7 lines · Scott Wood

Quoted 1 line · Marek Vasut

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.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 9 lines · Marek Vasut

Quoted 7 lines · Scott Wood

Quoted 1 line · Marek Vasut

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.

Quoted 2 lines

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

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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

Quoted 13 lines · Scott Wood

Quoted 11 lines · Marek Vasut

Quoted 7 lines · Scott Wood

Quoted 1 line · Marek Vasut

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.

Quoted 4 lines

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.

Quoted 6 lines

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 ?

Quoted 14 lines · Marek Vasut

Quoted 13 lines · Scott Wood

Quoted 11 lines · Marek Vasut

Quoted 7 lines · Scott Wood

Quoted 1 line · Marek Vasut

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 10 lines

Quoted 6 lines

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

Quoted 40 lines · Scott Wood

Quoted 14 lines · Marek Vasut

Quoted 13 lines · Scott Wood

Quoted 11 lines · Marek Vasut

Quoted 7 lines · Scott Wood

Quoted 1 line · Marek Vasut

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 10 lines

Quoted 6 lines

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 ?

Quoted 5 lines

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.

Quoted 5 lines · Marek Vasut

Quoted 4 lines · Scott Wood

Is it really such a burden to put something like

#define CONFIG_SPL_ARCH_CPU

Quoted 4 lines

Quoted 1 line

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.

Quoted 8 lines · Tom Rini

Quoted 7 lines · Marek Vasut

Quoted 5 lines · Scott Wood

Is it really such a burden to put something like

#define CONFIG_SPL_ARCH_CPU

in your board config header?

Quoted 7 lines

Quoted 2 lines

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

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---
  arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
  1 files changed, 7 insertions(+), 0 deletions(-)

arch/arm/cpu/arm926ejs/Makefile +0 -0

index 930e0d1..3f9b0f1 100644
@@ -28,6 +28,13 @@ LIB	= $(obj)lib$(CPU).o
  START	= start.o
  COBJS	= cpu.o
 

Hi Marek,

Le 06/10/2011 02:13, Marek Vasut a ?crit :

Quoted 29 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

  arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
  1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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
+
 

Quoted 3 lines

arch/arm/cpu/arm926ejs/Makefile +0 -0

  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,

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Scott Wood <[email protected]>

---
 arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +0 -0

@@ -28,6 +28,13 @@ LIB	= $(obj)lib$(CPU).o
 START	= start.o
 COBJS	= cpu.o
 

Quoted 19 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---
  arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
  1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +0 -0

@@ -28,6 +28,13 @@ LIB	= $(obj)lib$(CPU).o
  START	= start.o
  COBJS	= cpu.o
 

arch/arm/cpu/arm926ejs/Makefile LIB = $(obj)lib$(CPU).o · line 40

Quoted 10 lines

arch/arm/cpu/arm926ejs/Makefile +7 -0

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

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 36 lines · Marek Vasut

Quoted 30 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

  arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
  1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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)

Quoted 2 lines

  OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
  START	:= $(addprefix $(obj),$(START))

Hi Albert,

Quoted 1 line

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,

Quoted 41 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 37 lines · Marek Vasut

Quoted 30 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

   arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
   1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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)

Quoted 2 lines

   OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
   START	:= $(addprefix $(obj),$(START))

Hi Albert,

can we get this applied please?

Quoted 4 lines

I still don't understand what this is supposed to do -- why not linking this code is required.

Amicalement,

Hi Albert,

I use very different start.S in SPL. And I don't need cpu.o at all.

Cheers

Le 22/10/2011 00:00, Marek Vasut a ?crit :

Quoted 45 lines · Albert ARIBAUD

Quoted 44 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 30 lines · Marek Vasut

Quoted 29 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

   arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
   1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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
+
 

Quoted 7 lines

Quoted 3 lines

arch/arm/cpu/arm926ejs/Makefile +0 -0

   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.

Quoted 5 lines

Quoted 1 line

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?

Quoted 48 lines

Le 22/10/2011 00:00, Marek Vasut a ?crit :

Quoted 47 lines · Albert ARIBAUD

Quoted 45 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 30 lines · Marek Vasut

Quoted 29 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

    arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
    1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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
+
 

Quoted 7 lines

Quoted 3 lines

arch/arm/cpu/arm926ejs/Makefile +0 -0

    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,

Quoted 5 lines

Quoted 3 lines

Hi Albert,

I use very different start.S in SPL. And I don't need cpu.o at all.

That I understand; but is there a /problem/ in linking cpu.o in?

I suppose it'll be optimized out at link time ?

Cheers

Le 22/10/2011 00:46, Marek Vasut a ?crit :

Quoted 51 lines · Albert ARIBAUD

Quoted 50 lines

Le 22/10/2011 00:00, Marek Vasut a ?crit :

Quoted 49 lines · Albert ARIBAUD

Quoted 39 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 36 lines · Marek Vasut

Quoted 30 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

    arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
    1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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)

Quoted 2 lines

    OBJS	:= $(addprefix $(obj),$(COBJS) $(SOBJS))
    START	:= $(addprefix $(obj),$(START))

Hi Albert,

Quoted 6 lines

Quoted 1 line

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,

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

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

Quoted 2 lines

Cheers

Amicalement,

Quoted 54 lines · Albert ARIBAUD

Le 22/10/2011 00:46, Marek Vasut a ?crit :

Quoted 53 lines · Albert ARIBAUD

Quoted 52 lines

Le 22/10/2011 00:00, Marek Vasut a ?crit :

Quoted 50 lines · Albert ARIBAUD

Quoted 39 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 36 lines · Marek Vasut

Quoted 29 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

? ? arch/arm/cpu/arm926ejs/Makefile | ? ?7 +++++++ ? ? 1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +0 -0

@@ -28,6 +28,13 @@ LIB = $(obj)lib$(CPU).o
 

? ? START ? ? ?= start.o
? ? COBJS ? ? ?= cpu.o

arch/arm/cpu/arm926ejs/Makefile +7 -0

+ifdef CONFIG_SPL_BUILD
+ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
+START :=
+COBJS :=
+endif
+endif
+

Quoted 3 lines

? ? SRCS ? ? ? := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) ? ? OBJS ? ? ? := $(addprefix $(obj),$(COBJS) $(SOBJS)) ? ? START ? ? ?:= $(addprefix $(obj),$(START))

Hi Albert,

Quoted 6 lines

Quoted 1 line

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.

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

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 !

Quoted 55 lines · Marek Vasut

Quoted 54 lines · Albert ARIBAUD

Le 22/10/2011 00:46, Marek Vasut a ?crit :

Quoted 53 lines · Albert ARIBAUD

Quoted 52 lines

Le 22/10/2011 00:00, Marek Vasut a ?crit :

Quoted 50 lines · Albert ARIBAUD

Quoted 39 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 36 lines · Marek Vasut

Quoted 30 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

    arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
    1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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)

Quoted 2 lines

    OBJS       := $(addprefix $(obj),$(COBJS) $(SOBJS))
    START      := $(addprefix $(obj),$(START))

Hi Albert,

Quoted 6 lines

Quoted 1 line

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.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

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.

Quoted 65 lines · Marek Vasut

Quoted 55 lines · Albert ARIBAUD

Quoted 54 lines

Le 22/10/2011 00:46, Marek Vasut a ?crit :

Quoted 53 lines · Albert ARIBAUD

Quoted 52 lines

Le 22/10/2011 00:00, Marek Vasut a ?crit :

Quoted 50 lines · Albert ARIBAUD

Quoted 39 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 36 lines · Marek Vasut

Quoted 30 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

     arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
     1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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)

Quoted 2 lines

     OBJS       := $(addprefix $(obj),$(COBJS) $(SOBJS))
     START      := $(addprefix $(obj),$(START))

Hi Albert,

Quoted 6 lines

Quoted 1 line

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.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

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 !

Quoted 7 lines

Right, but linked and unused code in SPL is (or should be!) thrown away, is what's
trying to be driven home right now. If the file is going to go away, and it's compiled
thrown away at final link of SPL, lets just ignore that it exists for a little longer, and
then it won't.

My distrust towards compiler abilities to optimize such stuff out tells me it's better to avoid it even to be compiled in at all.

Le 22/10/2011 02:19, Marek Vasut a ?crit :

Quoted 74 lines · Tom Rini

Quoted 65 lines · Marek Vasut

Quoted 55 lines · Albert ARIBAUD

Quoted 54 lines

Le 22/10/2011 00:46, Marek Vasut a ?crit :

Quoted 53 lines · Albert ARIBAUD

Quoted 52 lines

Le 22/10/2011 00:00, Marek Vasut a ?crit :

Quoted 50 lines · Albert ARIBAUD

Quoted 39 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 36 lines · Marek Vasut

Quoted 30 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

     arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
     1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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)

Quoted 2 lines

     OBJS       := $(addprefix $(obj),$(COBJS) $(SOBJS))
     START      := $(addprefix $(obj),$(START))

Hi Albert,

Quoted 6 lines

Quoted 1 line

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.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

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 !

Quoted 7 lines

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.

Quoted 2 lines

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,

Quoted 84 lines

Le 22/10/2011 02:19, Marek Vasut a ?crit :

Quoted 74 lines · Tom Rini

Quoted 65 lines · Marek Vasut

Quoted 55 lines · Albert ARIBAUD

Quoted 54 lines

Le 22/10/2011 00:46, Marek Vasut a ?crit :

Quoted 53 lines · Albert ARIBAUD

Quoted 52 lines

Le 22/10/2011 00:00, Marek Vasut a ?crit :

Quoted 50 lines · Albert ARIBAUD

Quoted 39 lines

Hi Marek,

Le 21/10/2011 22:44, Marek Vasut a ?crit :

Quoted 36 lines · Marek Vasut

Quoted 30 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

---

      arch/arm/cpu/arm926ejs/Makefile |    7 +++++++
      1 files changed, 7 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..3f9b0f1 100644

arch/arm/cpu/arm926ejs/Makefile +7 -0

@@ -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)

Quoted 2 lines

      OBJS       := $(addprefix $(obj),$(COBJS) $(SOBJS))
      START      := $(addprefix $(obj),$(START))

Hi Albert,

Quoted 6 lines

Quoted 1 line

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.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Quoted 1 line

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 !

Quoted 7 lines

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.

Quoted 2 lines

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

Quoted 1 line

Amicalement,

So what you suggest is to leave cpu.o compiling and drop only start.S ?

Cheers

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Scott Wood <[email protected]>

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

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..a56ff08 100644

arch/arm/cpu/arm926ejs/Makefile +0 -0

@@ -28,6 +28,12 @@ LIB	= $(obj)lib$(CPU).o
 START	= start.o
 COBJS	= cpu.o

Quoted 31 lines

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Scott Wood <[email protected]>

---

 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.

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..a56ff08 100644

arch/arm/cpu/arm926ejs/Makefile +6 -0

@@ -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)

Quoted 2 lines

OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
START := $(addprefix $(obj),$(START))

Hi Albert,

can you apply please?

Thanks

This allows the SPL to avoid compiling in the CPU support code.

Signed-off-by Marek Vasut<[email protected]>

Cc Stefano Babic<[email protected]>

Cc Wolfgang Denk<[email protected]>

Cc Detlev Zundel<[email protected]>

Cc Scott Wood<[email protected]>

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

arch/arm/cpu/arm926ejs/Makefile +0 -0

index 930e0d1..a56ff08 100644
@@ -28,6 +28,12 @@ LIB	= $(obj)lib$(CPU).o
  START	= start.o
  COBJS	= cpu.o

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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Scott Wood <[email protected]>

---
 spl/Makefile |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

spl/Makefile +0 -0

index 91dd11a..fc9360f 100644

Quoted 18 lines · 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 <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Cc Scott Wood <[email protected]>

---

 spl/Makefile |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

spl/Makefile +0 -0

index 91dd11a..fc9360f 100644

spl/Makefile line 25

Quoted 8 lines

spl/Makefile +4 -0

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

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 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(-)

Quoted 9 lines · 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

Quoted 2 lines

 spl/Makefile |   17 ++++++++++++++---
 1 files changed, 14 insertions(+), 3 deletions(-)

Wolfgang, can you please apply the series?