[U-Boot] [PATCH v3] libgcc inclusion from common Makefile overwritable from platform configs files

[U-Boot] [PATCH v3] libgcc inclusion from common Makefile overwritable from platform configs files

[Jean-Christophe PLAGNIOL-VILLARD]

This patch allow to overwrit the libgcc Makefile inclusion from the toplevel
Makefile by the arch_config.mk files. This is in preparation for the ARM
architecture to move away from including libgcc function and only using
self-contained U-Boot functions as done in Linux.

Currently all the ARM boards that use the nand are broken due to the adding of
the 64 Bit device size support. In the past we have seen problems with different
toolchains due to EABI, FPU as example.
With this patch and the following one we move away from all these problems and
we will be able to have full control to have a functions embedded into u-boot.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
 Makefile                 |    3 ++-
 api_examples/Makefile    |    4 +---
 board/netstar/Makefile   |    4 +---
 board/sl8245/config.mk   |    1 -
 board/trab/Makefile      |    2 --
 board/voiceblue/Makefile |    4 +---
 examples/Makefile        |    2 +-
 7 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/Makefile b/Makefile
index 2a06440..e2a61fb 100644
--- a/Makefile
+++ b/Makefile
@@ -288,7 +288,8 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
 LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
 
 # Add GCC lib
-PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+PLATFORM_LIBGCC ?= -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+PLATFORM_LIBS += $(PLATFORM_LIBGCC)
 
 ifeq ($(CONFIG_NAND_U_BOOT),y)
 NAND_SPL = nand_spl
diff --git a/api_examples/Makefile b/api_examples/Makefile
index 4c01437..4bfa7e6 100644
--- a/api_examples/Makefile
+++ b/api_examples/Makefile
@@ -56,8 +56,6 @@ OBJS	:= $(addprefix $(obj),$(COBJS))
 ELF	:= $(addprefix $(obj),$(ELF))
 BIN	:= $(addprefix $(obj),$(BIN))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 CPPFLAGS += -I..
 
 all:	$(obj).depend $(OBJS) $(LIB) $(ELF) $(BIN)
@@ -70,7 +68,7 @@ $(ELF):
 $(obj)%:	$(obj)%.o $(LIB)
 		$(LD) $(obj)crt0.o -Ttext $(LOAD_ADDR) \
 			-o $@ $< $(LIB) \
-			-L$(gcclibdir) -lgcc
+			$(PLATFORM_LIBGCC)
 
 $(BIN):
 $(obj)%.bin:	$(obj)%
diff --git a/board/netstar/Makefile b/board/netstar/Makefile
index 91bac38..1cc2722 100644
--- a/board/netstar/Makefile
+++ b/board/netstar/Makefile
@@ -36,8 +36,6 @@ SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c \
 OBJS	:= $(addprefix $(obj),$(COBJS))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0x10400000
 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
 lnk = $(if $(obj),$(obj),.)
@@ -55,7 +53,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
-		-L$(gcclibdir) -lgcc
+		$(PLATFROM_LIBGCC)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/board/sl8245/config.mk b/board/sl8245/config.mk
index 022512b..299fc6c 100644
--- a/board/sl8245/config.mk
+++ b/board/sl8245/config.mk
@@ -28,4 +28,3 @@
 TEXT_BASE = 0xFFF00000
 
 PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE)
-PLATFORM_LIBS += $(shell $(CC) -print-libgcc-file-name)
diff --git a/board/trab/Makefile b/board/trab/Makefile
index 30e5fbb..a3661c4 100644
--- a/board/trab/Makefile
+++ b/board/trab/Makefile
@@ -36,8 +36,6 @@ SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
 OBJS_FKT := $(addprefix $(obj),$(COBJS_FKT))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0xc100000
 
 #########################################################################
diff --git a/board/voiceblue/Makefile b/board/voiceblue/Makefile
index e7c1cbb..0d1e079 100644
--- a/board/voiceblue/Makefile
+++ b/board/voiceblue/Makefile
@@ -33,8 +33,6 @@ SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c eeprom_start.S
 OBJS	:= $(addprefix $(obj),$(COBJS))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0x10400000
 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
 lnk = $(if $(obj),$(obj),.)
@@ -49,7 +47,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
-		-L$(gcclibdir) -lgcc
+		$(PLATFROM_LIBGCC)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/examples/Makefile b/examples/Makefile
index dbcfa92..5bd13f1 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -178,7 +178,7 @@ $(ELF):
 $(obj)%:	$(obj)%.o $(LIB)
 		$(LD) -g $(EX_LDFLAGS) -Ttext $(LOAD_ADDR) \
 			-o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \
-			-L$(gcclibdir) -lgcc
+			$(PLATFORM_LIBGCC)
 
 $(SREC):
 $(obj)%.srec:	$(obj)%
-- 
1.6.3.1

[U-Boot] [PATCH v3] libgcc inclusion from common Makefile overwritable from platform configs files

[Scott Wood]

Jean-Christophe PLAGNIOL-VILLARD wrote:
>  LOAD_ADDR = 0x10400000
>  LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
>  lnk = $(if $(obj),$(obj),.)
> @@ -49,7 +47,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
>  		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
>  		-L$(obj)../../examples -lstubs \
>  		-L$(obj)../../lib_generic -lgeneric \
> -		-L$(gcclibdir) -lgcc
> +		$(PLATFROM_LIBGCC)

PLATFROM?

-Scott

[U-Boot] [PATCH v3] libgcc inclusion from common Makefile overwritable from platform configs files

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:42 Wed 08 Jul     , Scott Wood wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> > LOAD_ADDR = 0x10400000
> > LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
> > lnk = $(if $(obj),$(obj),.)
> >@@ -49,7 +47,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
> > 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
> > 		-L$(obj)../../examples -lstubs \
> > 		-L$(obj)../../lib_generic -lgeneric \
> >-		-L$(gcclibdir) -lgcc
> >+		$(PLATFROM_LIBGCC)
> 
> PLATFROM?
I've build it
it does not to need the libgcc at all

I'll fix anyway

Best Regards,
J.

[U-Boot] [PATCH V4] libgcc inclusion from common Makefile overwritable from platform configs files

[Jean-Christophe PLAGNIOL-VILLARD]

This patch allow to overwrit the libgcc Makefile inclusion from the toplevel
Makefile by the arch_config.mk files. This is in preparation for the ARM
architecture to move away from including libgcc function and only using
self-contained U-Boot functions as done in Linux.

Currently all the ARM boards that use the nand are broken due to the adding of
the 64 Bit device size support. In the past we have seen problems with different
toolchains due to EABI, FPU as example.
With this patch and the following one we move away from all these problems and
we will be able to have full control to have a functions embedded into u-boot.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
v4:
fix typo

evenif that with the typo work fine
I'll send an other patch clean the non need lib link

Best Regards,
J.

 Makefile                 |    3 ++-
 api_examples/Makefile    |    4 +---
 board/netstar/Makefile   |    4 +---
 board/sl8245/config.mk   |    1 -
 board/trab/Makefile      |    2 --
 board/voiceblue/Makefile |    4 +---
 examples/Makefile        |    2 +-
 7 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/Makefile b/Makefile
index 2a06440..e2a61fb 100644
--- a/Makefile
+++ b/Makefile
@@ -288,7 +288,8 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
 LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
 
 # Add GCC lib
-PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+PLATFORM_LIBGCC ?= -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+PLATFORM_LIBS += $(PLATFORM_LIBGCC)
 
 ifeq ($(CONFIG_NAND_U_BOOT),y)
 NAND_SPL = nand_spl
diff --git a/api_examples/Makefile b/api_examples/Makefile
index 4c01437..4bfa7e6 100644
--- a/api_examples/Makefile
+++ b/api_examples/Makefile
@@ -56,8 +56,6 @@ OBJS	:= $(addprefix $(obj),$(COBJS))
 ELF	:= $(addprefix $(obj),$(ELF))
 BIN	:= $(addprefix $(obj),$(BIN))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 CPPFLAGS += -I..
 
 all:	$(obj).depend $(OBJS) $(LIB) $(ELF) $(BIN)
@@ -70,7 +68,7 @@ $(ELF):
 $(obj)%:	$(obj)%.o $(LIB)
 		$(LD) $(obj)crt0.o -Ttext $(LOAD_ADDR) \
 			-o $@ $< $(LIB) \
-			-L$(gcclibdir) -lgcc
+			$(PLATFORM_LIBGCC)
 
 $(BIN):
 $(obj)%.bin:	$(obj)%
diff --git a/board/netstar/Makefile b/board/netstar/Makefile
index 91bac38..a52ded4 100644
--- a/board/netstar/Makefile
+++ b/board/netstar/Makefile
@@ -36,8 +36,6 @@ SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c \
 OBJS	:= $(addprefix $(obj),$(COBJS))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0x10400000
 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
 lnk = $(if $(obj),$(obj),.)
@@ -55,7 +53,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
-		-L$(gcclibdir) -lgcc
+		$(PLATFORM_LIBGCC)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/board/sl8245/config.mk b/board/sl8245/config.mk
index 022512b..299fc6c 100644
--- a/board/sl8245/config.mk
+++ b/board/sl8245/config.mk
@@ -28,4 +28,3 @@
 TEXT_BASE = 0xFFF00000
 
 PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE)
-PLATFORM_LIBS += $(shell $(CC) -print-libgcc-file-name)
diff --git a/board/trab/Makefile b/board/trab/Makefile
index 30e5fbb..a3661c4 100644
--- a/board/trab/Makefile
+++ b/board/trab/Makefile
@@ -36,8 +36,6 @@ SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
 OBJS_FKT := $(addprefix $(obj),$(COBJS_FKT))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0xc100000
 
 #########################################################################
diff --git a/board/voiceblue/Makefile b/board/voiceblue/Makefile
index e7c1cbb..0d1e079 100644
--- a/board/voiceblue/Makefile
+++ b/board/voiceblue/Makefile
@@ -33,8 +33,6 @@ SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c eeprom_start.S
 OBJS	:= $(addprefix $(obj),$(COBJS))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0x10400000
 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
 lnk = $(if $(obj),$(obj),.)
@@ -49,7 +47,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
-		-L$(gcclibdir) -lgcc
+		$(PLATFROM_LIBGCC)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/examples/Makefile b/examples/Makefile
index dbcfa92..5bd13f1 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -178,7 +178,7 @@ $(ELF):
 $(obj)%:	$(obj)%.o $(LIB)
 		$(LD) -g $(EX_LDFLAGS) -Ttext $(LOAD_ADDR) \
 			-o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \
-			-L$(gcclibdir) -lgcc
+			$(PLATFORM_LIBGCC)
 
 $(SREC):
 $(obj)%.srec:	$(obj)%
-- 
1.6.3.1

[U-Boot] [PATCH V4] libgcc inclusion from common Makefile overwritable from platform configs files

[Scott Wood]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> This patch allow to overwrit the libgcc Makefile inclusion from the toplevel
> Makefile by the arch_config.mk files. This is in preparation for the ARM
> architecture to move away from including libgcc function and only using
> self-contained U-Boot functions as done in Linux.
> 
> Currently all the ARM boards that use the nand are broken due to the adding of
> the 64 Bit device size support. In the past we have seen problems with different
> toolchains due to EABI, FPU as example.
> With this patch and the following one we move away from all these problems and
> we will be able to have full control to have a functions embedded into u-boot.
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
> v4:
> fix typo
> 
> evenif that with the typo work fine

I'm assuming that the variable reference is there for a reason, even if 
it isn't necessary right now, and thus should be correct...

>  LOAD_ADDR = 0x10400000
>  LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
>  lnk = $(if $(obj),$(obj),.)
> @@ -49,7 +47,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
>  		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
>  		-L$(obj)../../examples -lstubs \
>  		-L$(obj)../../lib_generic -lgeneric \
> -		-L$(gcclibdir) -lgcc
> +		$(PLATFROM_LIBGCC)

Still there.

-Scott

[U-Boot] [PATCH V4] libgcc inclusion from common Makefile overwritable from platform configs files

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1247084077-12867-1-git-send-email-plagnioj@jcrosoft.com> you wrote:
> This patch allow to overwrit the libgcc Makefile inclusion from the toplevel

overwrite

> Makefile by the arch_config.mk files. This is in preparation for the ARM
> architecture to move away from including libgcc function and only using
> self-contained U-Boot functions as done in Linux.
> 
> Currently all the ARM boards that use the nand are broken due to the adding of
> the 64 Bit device size support. In the past we have seen problems with different
> toolchains due to EABI, FPU as example.

tool chains

> With this patch and the following one we move away from all these problems and

"the following one" makes no sense. After comitting the patch, nobody
knows what "the following one" might have been - even now I don't know
what you are referring to.

> we will be able to have full control to have a functions embedded into u-boot.

This sentence makes no sense to me either.

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
The high cost of living hasn't affected its popularity.

[U-Boot] [PATCH V4] libgcc inclusion from common Makefile overwritable from platform configs files

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:26 Wed 08 Jul     , Scott Wood wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> >This patch allow to overwrit the libgcc Makefile inclusion from the toplevel
> >Makefile by the arch_config.mk files. This is in preparation for the ARM
> >architecture to move away from including libgcc function and only using
> >self-contained U-Boot functions as done in Linux.
> >
> >Currently all the ARM boards that use the nand are broken due to the adding of
> >the 64 Bit device size support. In the past we have seen problems with different
> >toolchains due to EABI, FPU as example.
> >With this patch and the following one we move away from all these problems and
> >we will be able to have full control to have a functions embedded into u-boot.
> >
> >Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> >---
> >v4:
> >fix typo
> >
> >evenif that with the typo work fine
> 
> I'm assuming that the variable reference is there for a reason, even
> if it isn't necessary right now, and thus should be correct...
from the eeprom we can remove the libgcc include
as there is no need to use it

Best Regards,
J.

[U-Boot] [PATCH V5] libgcc inclusion from common Makefile overwritable from platform configs files

[Jean-Christophe PLAGNIOL-VILLARD]

This patch allow to overwrit the libgcc Makefile inclusion from the toplevel
Makefile by the arch_config.mk files. This is in preparation for the ARM
architecture to move away from including libgcc function and only using
self-contained U-Boot functions as done in Linux.

Currently all the ARM boards that use the nand are broken due to the adding of
the 64 Bit device size support. In the past we have seen problems with different
toolchains due to EABI, FPU as example.
With this patch and the following one we move away from all these problems and
we will be able to have full control to have a functions embedded into u-boot.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
V5
typo fix
 Makefile                 |    3 ++-
 api_examples/Makefile    |    4 +---
 board/netstar/Makefile   |    4 +---
 board/sl8245/config.mk   |    1 -
 board/trab/Makefile      |    2 --
 board/voiceblue/Makefile |    4 +---
 examples/Makefile        |    2 +-
 7 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/Makefile b/Makefile
index 2a06440..e2a61fb 100644
--- a/Makefile
+++ b/Makefile
@@ -288,7 +288,8 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
 LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
 
 # Add GCC lib
-PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+PLATFORM_LIBGCC ?= -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+PLATFORM_LIBS += $(PLATFORM_LIBGCC)
 
 ifeq ($(CONFIG_NAND_U_BOOT),y)
 NAND_SPL = nand_spl
diff --git a/api_examples/Makefile b/api_examples/Makefile
index 4c01437..4bfa7e6 100644
--- a/api_examples/Makefile
+++ b/api_examples/Makefile
@@ -56,8 +56,6 @@ OBJS	:= $(addprefix $(obj),$(COBJS))
 ELF	:= $(addprefix $(obj),$(ELF))
 BIN	:= $(addprefix $(obj),$(BIN))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 CPPFLAGS += -I..
 
 all:	$(obj).depend $(OBJS) $(LIB) $(ELF) $(BIN)
@@ -70,7 +68,7 @@ $(ELF):
 $(obj)%:	$(obj)%.o $(LIB)
 		$(LD) $(obj)crt0.o -Ttext $(LOAD_ADDR) \
 			-o $@ $< $(LIB) \
-			-L$(gcclibdir) -lgcc
+			$(PLATFORM_LIBGCC)
 
 $(BIN):
 $(obj)%.bin:	$(obj)%
diff --git a/board/netstar/Makefile b/board/netstar/Makefile
index 91bac38..a52ded4 100644
--- a/board/netstar/Makefile
+++ b/board/netstar/Makefile
@@ -36,8 +36,6 @@ SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c \
 OBJS	:= $(addprefix $(obj),$(COBJS))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0x10400000
 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
 lnk = $(if $(obj),$(obj),.)
@@ -55,7 +53,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
-		-L$(gcclibdir) -lgcc
+		$(PLATFORM_LIBGCC)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/board/sl8245/config.mk b/board/sl8245/config.mk
index 022512b..299fc6c 100644
--- a/board/sl8245/config.mk
+++ b/board/sl8245/config.mk
@@ -28,4 +28,3 @@
 TEXT_BASE = 0xFFF00000
 
 PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE)
-PLATFORM_LIBS += $(shell $(CC) -print-libgcc-file-name)
diff --git a/board/trab/Makefile b/board/trab/Makefile
index 30e5fbb..a3661c4 100644
--- a/board/trab/Makefile
+++ b/board/trab/Makefile
@@ -36,8 +36,6 @@ SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
 OBJS_FKT := $(addprefix $(obj),$(COBJS_FKT))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0xc100000
 
 #########################################################################
diff --git a/board/voiceblue/Makefile b/board/voiceblue/Makefile
index e7c1cbb..369dc0b 100644
--- a/board/voiceblue/Makefile
+++ b/board/voiceblue/Makefile
@@ -33,8 +33,6 @@ SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c eeprom_start.S
 OBJS	:= $(addprefix $(obj),$(COBJS))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0x10400000
 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
 lnk = $(if $(obj),$(obj),.)
@@ -49,7 +47,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
-		-L$(gcclibdir) -lgcc
+		$(PLATFORM_LIBGCC)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/examples/Makefile b/examples/Makefile
index dbcfa92..5bd13f1 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -178,7 +178,7 @@ $(ELF):
 $(obj)%:	$(obj)%.o $(LIB)
 		$(LD) -g $(EX_LDFLAGS) -Ttext $(LOAD_ADDR) \
 			-o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \
-			-L$(gcclibdir) -lgcc
+			$(PLATFORM_LIBGCC)
 
 $(SREC):
 $(obj)%.srec:	$(obj)%
-- 
1.6.3.1

[U-Boot] [PATCH 2/2] netstar/voiceblue: remove no-need libgcc link for eeprom standalone

[Jean-Christophe PLAGNIOL-VILLARD]

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
 board/netstar/Makefile   |    3 +--
 board/voiceblue/Makefile |    3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/board/netstar/Makefile b/board/netstar/Makefile
index a52ded4..7237a3d 100644
--- a/board/netstar/Makefile
+++ b/board/netstar/Makefile
@@ -52,8 +52,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 	cd $(lnk) && $(LD) -T $(LDSCRIPT) -g -Ttext $(LOAD_ADDR) \
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
-		-L$(obj)../../lib_generic -lgeneric \
-		$(PLATFORM_LIBGCC)
+		-L$(obj)../../lib_generic -lgeneric
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/board/voiceblue/Makefile b/board/voiceblue/Makefile
index 369dc0b..b7710ee 100644
--- a/board/voiceblue/Makefile
+++ b/board/voiceblue/Makefile
@@ -46,8 +46,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 	cd $(lnk) && $(LD) -T $(LDSCRIPT) -g -Ttext $(LOAD_ADDR) \
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
-		-L$(obj)../../lib_generic -lgeneric \
-		$(PLATFORM_LIBGCC)
+		-L$(obj)../../lib_generic -lgeneric
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
-- 
1.6.3.1

[U-Boot] [PATCH V4] libgcc inclusion from common Makefile overwritable from platform configs files

[Jean-Christophe PLAGNIOL-VILLARD]

On 22:30 Wed 08 Jul     , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <1247084077-12867-1-git-send-email-plagnioj@jcrosoft.com> you wrote:
> > This patch allow to overwrit the libgcc Makefile inclusion from the toplevel
> 
> overwrite
> 
> > Makefile by the arch_config.mk files. This is in preparation for the ARM
> > architecture to move away from including libgcc function and only using
> > self-contained U-Boot functions as done in Linux.
> > 
> > Currently all the ARM boards that use the nand are broken due to the adding of
> > the 64 Bit device size support. In the past we have seen problems with different
> > toolchains due to EABI, FPU as example.
> 
> tool chains
> 
> > With this patch and the following one we move away from all these problems and
> 
> "the following one" makes no sense. After comitting the patch, nobody
> knows what "the following one" might have been - even now I don't know
> what you are referring to.
I refer to the arm patch that remove the libgcc depency
> 
> > we will be able to have full control to have a functions embedded into u-boot.
> 
> This sentence makes no sense to me either.
for arm as example the gcc does not provide necessarely cored functions for
all ABI we do need to control wich one we need to use into u-boot

Best Regards,
J.

[U-Boot] [PATCH V4] libgcc inclusion from common Makefile overwritable from platform configs files

[Mike Frysinger]

On Wednesday 08 July 2009 16:30:03 Wolfgang Denk wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> > This patch allow to overwrit the libgcc Makefile inclusion from the
> > toplevel
>
> overwrite

override is a better word for this behavior

this general method works for me (ignoring the issues others point out), so 
assuming you fix those, acked-by-me
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090708/1a1d3866/attachment.pgp 

[U-Boot] [PATCH V5] libgcc inclusion from common Makefile overwritable from platform configs files

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1247085496-21754-1-git-send-email-plagnioj@jcrosoft.com> you wrote:
> This patch allow to overwrit the libgcc Makefile inclusion from the toplevel

Please mind the hints: "overwrit" is a typo. You  meant  "overwrite",
and  Mike  just  explained  that  "override" is even more appropriate
here.

> Makefile by the arch_config.mk files. This is in preparation for the ARM
> architecture to move away from including libgcc function and only using
> self-contained U-Boot functions as done in Linux.
> 
> Currently all the ARM boards that use the nand are broken due to the adding of
> the 64 Bit device size support. In the past we have seen problems with different
> toolchains due to EABI, FPU as example.

Correct spelling is "tool chains", not "toolchains".

> With this patch and the following one we move away from all these problems and
> we will be able to have full control to have a functions embedded into u-boot.

Please fix the comment.

In git history, there will be no "following one" patch, and here you
did not post one either. If you don't have it ready yet, then please
use a description of what it will do.

And "we will be able  to  have  full  control  to  have  a  functions
embedded  into  u-boot"  makes  no  sense.  Either it is "a function"
(singular), or it is "functions" (plural, without "a"). But  what  do
you  want  to  tell  us? "have functions embedded into U-Boot"? We do
this all the time by linking them in - we already have  full  control
over  it  (except  that  it's not working as expected sometimes), and
your patch does not really change anything of this.


You wrote: "gcc does not provide necessarely cored functions". Sorry,
but I have no idea what you are talking about here. What is a "cored
function"?

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
When some people discover the truth, they just can't  understand  why
everybody isn't eager to hear it.

[U-Boot] [PATCH V5] libgcc inclusion from common Makefile overwritable from platform configs files

[Jean-Christophe PLAGNIOL-VILLARD]

On 22:55 Wed 08 Jul     , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <1247085496-21754-1-git-send-email-plagnioj@jcrosoft.com> you wrote:
> > This patch allow to overwrit the libgcc Makefile inclusion from the toplevel
> 
> Please mind the hints: "overwrit" is a typo. You  meant  "overwrite",
> and  Mike  just  explained  that  "override" is even more appropriate
> here.
> 
> > Makefile by the arch_config.mk files. This is in preparation for the ARM
> > architecture to move away from including libgcc function and only using
> > self-contained U-Boot functions as done in Linux.
> > 
> > Currently all the ARM boards that use the nand are broken due to the adding of
> > the 64 Bit device size support. In the past we have seen problems with different
> > toolchains due to EABI, FPU as example.
> 
> Correct spelling is "tool chains", not "toolchains".
> 
> > With this patch and the following one we move away from all these problems and
> > we will be able to have full control to have a functions embedded into u-boot.
> 
> Please fix the comment.
> 
> In git history, there will be no "following one" patch, and here you
> did not post one either. If you don't have it ready yet, then please
> use a description of what it will do.
the precedent patch still apply cleany so I do not resend it
> 
> And "we will be able  to  have  full  control  to  have  a  functions
> embedded  into  u-boot"  makes  no  sense.  Either it is "a function"
> (singular), or it is "functions" (plural, without "a"). But  what  do
> you  want  to  tell  us? "have functions embedded into U-Boot"? We do
> this all the time by linking them in - we already have  full  control
> over  it  (except  that  it's not working as expected sometimes), and
> your patch does not really change anything of this.
gcc for arm is really boring about abi support and float support
so on arm we do need to control it and be sure about what we use for basic
function and do not use the libgcc provide by the tool chains as we can not
trust them
so for linux as example we implement it correctly and are able to manage
against what armv we want to compile or be comptatible
ditto when we will be able to support Thumb2 as needed for cortex-m3
> 
> 
> You wrote: "gcc does not provide necessarely cored functions". Sorry,
> but I have no idea what you are talking about here. What is a "cored
> function"?
correct function
> 
> 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
> When some people discover the truth, they just can't  understand  why
> everybody isn't eager to hear it.

[U-Boot] [PATCH V5] libgcc inclusion from common Makefile overwritable from platform configs files

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090708211902.GH12394@game.jcrosoft.org> you wrote:
>
> > > With this patch and the following one we move away from all these problems and
> > > we will be able to have full control to have a functions embedded into u-boot.
> > 
> > Please fix the comment.
> > 
> > In git history, there will be no "following one" patch, and here you
> > did not post one either. If you don't have it ready yet, then please
> > use a description of what it will do.
> the precedent patch still apply cleany so I do not resend it

You don't get it.

Your commit message uses the  phrase  "the  following  [patch]",  but
nobody knows what this "following one" is. I do not know it even now,
while  we  are  discussing it. Please use some form of reference that
can be understood.

> > And "we will be able  to  have  full  control  to  have  a  functions
> > embedded  into  u-boot"  makes  no  sense.  Either it is "a function"
> > (singular), or it is "functions" (plural, without "a"). But  what  do
> > you  want  to  tell  us? "have functions embedded into U-Boot"? We do
> > this all the time by linking them in - we already have  full  control
> > over  it  (except  that  it's not working as expected sometimes), and
> > your patch does not really change anything of this.
> gcc for arm is really boring about abi support and float support
> so on arm we do need to control it and be sure about what we use for basic
> function and do not use the libgcc provide by the tool chains as we can not
> trust them
> so for linux as example we implement it correctly and are able to manage
> against what armv we want to compile or be comptatible
> ditto when we will be able to support Thumb2 as needed for cortex-m3

I do understand the situation and what you are trying to do.

What I do not understand is the sentence you wrote in the commit
message.

> > You wrote: "gcc does not provide necessarely cored functions". Sorry,
> > but I have no idea what you are talking about here. What is a "cored
> > function"?
> correct function

Ah.


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
Q: How do you spell "onomatopoeia"?
A: The way it sounds.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Jean-Christophe PLAGNIOL-VILLARD]

This patch allows to override the libgcc Makefile inclusion from the toplevel
Makefile by the arch config.mk files. This is in preparation for the ARM
architecture to move away from including libgcc functions and only using
self-contained U-Boot functions as done in Linux.

Currently all the ARM boards that use NAND are broken due to the addition of
64 Bit device size support. In the past we have seen similar problems with
different tool chains due to EABI and FPU for example.

With this patch and this one: "ARM: Don't include libgcc anymore" we move away
from all these problems on ARM since we don't include any functions from
libgcc anymore.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
---
 Makefile                 |    3 ++-
 api_examples/Makefile    |    4 +---
 board/netstar/Makefile   |    4 +---
 board/sl8245/config.mk   |    1 -
 board/trab/Makefile      |    2 --
 board/voiceblue/Makefile |    4 +---
 examples/Makefile        |    2 +-
 7 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/Makefile b/Makefile
index 2a06440..e2a61fb 100644
--- a/Makefile
+++ b/Makefile
@@ -288,7 +288,8 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
 LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
 
 # Add GCC lib
-PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+PLATFORM_LIBGCC ?= -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+PLATFORM_LIBS += $(PLATFORM_LIBGCC)
 
 ifeq ($(CONFIG_NAND_U_BOOT),y)
 NAND_SPL = nand_spl
diff --git a/api_examples/Makefile b/api_examples/Makefile
index 4c01437..4bfa7e6 100644
--- a/api_examples/Makefile
+++ b/api_examples/Makefile
@@ -56,8 +56,6 @@ OBJS	:= $(addprefix $(obj),$(COBJS))
 ELF	:= $(addprefix $(obj),$(ELF))
 BIN	:= $(addprefix $(obj),$(BIN))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 CPPFLAGS += -I..
 
 all:	$(obj).depend $(OBJS) $(LIB) $(ELF) $(BIN)
@@ -70,7 +68,7 @@ $(ELF):
 $(obj)%:	$(obj)%.o $(LIB)
 		$(LD) $(obj)crt0.o -Ttext $(LOAD_ADDR) \
 			-o $@ $< $(LIB) \
-			-L$(gcclibdir) -lgcc
+			$(PLATFORM_LIBGCC)
 
 $(BIN):
 $(obj)%.bin:	$(obj)%
diff --git a/board/netstar/Makefile b/board/netstar/Makefile
index 91bac38..a52ded4 100644
--- a/board/netstar/Makefile
+++ b/board/netstar/Makefile
@@ -36,8 +36,6 @@ SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c \
 OBJS	:= $(addprefix $(obj),$(COBJS))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0x10400000
 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
 lnk = $(if $(obj),$(obj),.)
@@ -55,7 +53,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
-		-L$(gcclibdir) -lgcc
+		$(PLATFORM_LIBGCC)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/board/sl8245/config.mk b/board/sl8245/config.mk
index 022512b..299fc6c 100644
--- a/board/sl8245/config.mk
+++ b/board/sl8245/config.mk
@@ -28,4 +28,3 @@
 TEXT_BASE = 0xFFF00000
 
 PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE)
-PLATFORM_LIBS += $(shell $(CC) -print-libgcc-file-name)
diff --git a/board/trab/Makefile b/board/trab/Makefile
index 30e5fbb..a3661c4 100644
--- a/board/trab/Makefile
+++ b/board/trab/Makefile
@@ -36,8 +36,6 @@ SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
 OBJS_FKT := $(addprefix $(obj),$(COBJS_FKT))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0xc100000
 
 #########################################################################
diff --git a/board/voiceblue/Makefile b/board/voiceblue/Makefile
index e7c1cbb..369dc0b 100644
--- a/board/voiceblue/Makefile
+++ b/board/voiceblue/Makefile
@@ -33,8 +33,6 @@ SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c eeprom_start.S
 OBJS	:= $(addprefix $(obj),$(COBJS))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0x10400000
 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds
 lnk = $(if $(obj),$(obj),.)
@@ -49,7 +47,7 @@ $(obj)eeprom.srec:	$(obj)eeprom.o $(obj)eeprom_start.o
 		-o $(<:.o=) -e eeprom eeprom.o eeprom_start.o \
 		-L$(obj)../../examples -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
-		-L$(gcclibdir) -lgcc
+		$(PLATFORM_LIBGCC)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)eeprom.bin:	$(obj)eeprom.srec
diff --git a/examples/Makefile b/examples/Makefile
index dbcfa92..5bd13f1 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -178,7 +178,7 @@ $(ELF):
 $(obj)%:	$(obj)%.o $(LIB)
 		$(LD) -g $(EX_LDFLAGS) -Ttext $(LOAD_ADDR) \
 			-o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \
-			-L$(gcclibdir) -lgcc
+			$(PLATFORM_LIBGCC)
 
 $(SREC):
 $(obj)%.srec:	$(obj)%
-- 
1.6.3.1

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Dear Stefan and Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> This patch allows to override the libgcc Makefile inclusion from the toplevel
> Makefile by the arch config.mk files. This is in preparation for the ARM
> architecture to move away from including libgcc functions and only using
> self-contained U-Boot functions as done in Linux.
> 
> Currently all the ARM boards that use NAND are broken due to the addition of
> 64 Bit device size support. In the past we have seen similar problems with
> different tool chains due to EABI and FPU for example.
> 
> With this patch and this one: "ARM: Don't include libgcc anymore" we move away
> from all these problems on ARM since we don't include any functions from
> libgcc anymore.

You know, I'm a big fan of these two patches and like to see them in 
mainline asap ;)

I applied them locally. Now, I'm preparing a patch to enable 
CONFIG_SYS_64BIT_VSPRINTF for all OMAP3 boards to get rid of these 
annoying "warning: #warning Please define CONFIG_SYS_64BIT_VSPRINTF 
for correct output!".

While without CONFIG_SYS_64BIT_VSPRINTF everything compiles fine with 
both libgcc patches applied, enabling CONFIG_SYS_64BIT_VSPRINTF still 
results in

lib_generic/libgeneric.a(vsprintf.o): In function `put_dec': 

lib_generic/vsprintf.c:242: undefined reference to `__umoddi3' 
 

lib_generic/vsprintf.c:242: undefined reference to `__udivdi3'

Any idea why this still happens *with* libgcc patches? Any idea how to 
fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too?

Many thanks and best regards

Dirk

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Stefan Roese]

Hi Dirk,

On Sunday 12 July 2009 09:54:12 Dirk Behme wrote:
> While without CONFIG_SYS_64BIT_VSPRINTF everything compiles fine with
> both libgcc patches applied, enabling CONFIG_SYS_64BIT_VSPRINTF still
> results in
>
> lib_generic/libgeneric.a(vsprintf.o): In function `put_dec':
>
> lib_generic/vsprintf.c:242: undefined reference to `__umoddi3'
>
>
> lib_generic/vsprintf.c:242: undefined reference to `__udivdi3'
>
> Any idea why this still happens *with* libgcc patches? Any idea how to
> fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too?

I have to admit that I'm not sure why this is the case. But I suggest that you 
take a look at Simon's patch sent to the list a few days ago:

[PATCH 5/8]: Use do_div from div64.h for vsprintf

This should fix this issue.

Let me know if this helps.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Stefan Roese wrote:
> Hi Dirk,
> 
> On Sunday 12 July 2009 09:54:12 Dirk Behme wrote:
>> While without CONFIG_SYS_64BIT_VSPRINTF everything compiles fine with
>> both libgcc patches applied, enabling CONFIG_SYS_64BIT_VSPRINTF still
>> results in
>>
>> lib_generic/libgeneric.a(vsprintf.o): In function `put_dec':
>>
>> lib_generic/vsprintf.c:242: undefined reference to `__umoddi3'
>>
>>
>> lib_generic/vsprintf.c:242: undefined reference to `__udivdi3'
>>
>> Any idea why this still happens *with* libgcc patches? Any idea how to
>> fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too?
> 
> I have to admit that I'm not sure why this is the case. But I suggest that you 
> take a look at Simon's patch sent to the list a few days ago:
> 
> [PATCH 5/8]: Use do_div from div64.h for vsprintf
> 
> This should fix this issue.
> 
> Let me know if this helps.

Yes, thanks!

For the archives: With

http://lists.denx.de/pipermail/u-boot/2009-July/055599.html
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=07a6acbe20357ebc2af36ac32e7029828d895a62
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e2a7f3af809f828878fe

I'm now able to enable CONFIG_SYS_64BIT_VSPRINTF for all OMAP3 boards 
and compile it without (tool chain related) warnings. OMAP3 
CONFIG_SYS_64BIT_VSPRINTF patch will be sent, soon.

Thanks

Dirk

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Stefan Roese,

In message <200907121002.46516.sr@denx.de> you wrote:
> 
> > Any idea why this still happens *with* libgcc patches? Any idea how to
> > fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too?
> 
> I have to admit that I'm not sure why this is the case. But I suggest that you 
> take a look at Simon's patch sent to the list a few days ago:
> 
> [PATCH 5/8]: Use do_div from div64.h for vsprintf
> 
> This should fix this issue.

It will hush up the current errors, but that's actually a  bad  thing
here  -  the  errors  are  an indication that Jean-Christophe's patch
might not be working as it is supposed to.

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
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:29 Sun 12 Jul     , Wolfgang Denk wrote:
> Dear Stefan Roese,
> 
> In message <200907121002.46516.sr@denx.de> you wrote:
> > 
> > > Any idea why this still happens *with* libgcc patches? Any idea how to
> > > fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too?
> > 
> > I have to admit that I'm not sure why this is the case. But I suggest that you 
> > take a look at Simon's patch sent to the list a few days ago:
> > 
> > [PATCH 5/8]: Use do_div from div64.h for vsprintf
> > 
> > This should fix this issue.
> 
> It will hush up the current errors, but that's actually a  bad  thing
> here  -  the  errors  are  an indication that Jean-Christophe's patch
> might not be working as it is supposed to.
They do fix what they are suppose to , fix FPU and EABI problem which was
re-introduce by the 64 bit mtd support
here the problem is different you try to div64 which is not supported on arm
you do need to do_div

please apply this patch so I'll be able to send a pull request with the arm
specific part and other patch be go in vacancy for one week this night

Best Regards,
J.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Dear Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> be go in vacancy for one week this night

This does mean that we will have no more ARM patches merged until 
merge window closes, right?

Best regards

Dirk

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:13 Sun 12 Jul     , Dirk Behme wrote:
> Dear Jean-Christophe,
> 
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> >be go in vacancy for one week this night
> 
> This does mean that we will have no more ARM patches merged until
> merge window closes, right?
one tonight one next sunday

Best Regards,
J.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090712120655.GA21713@game.jcrosoft.org> you wrote:
>
> > It will hush up the current errors, but that's actually a  bad  thing
> > here  -  the  errors  are  an indication that Jean-Christophe's patch
> > might not be working as it is supposed to.
> They do fix what they are suppose to , fix FPU and EABI problem which was
> re-introduce by the 64 bit mtd support
> here the problem is different you try to div64 which is not supported on arm
> you do need to do_div

What do you mean - not supported by ARM?  Of course ARM supports 64
bit division.

Compiling this little test code:

	long long div(long long x, long long y)
	{
	        return x / y;
	}

will result in a call to  __aeabi_ldivmod  using  an  EABI  compliant
version  of  GCC,  resp.  to __divdi3 using an older compiler. So GCC
knows how to handle this, and it provides adequate  functions  to  do
it.

> please apply this patch so I'll be able to send a pull request with the arm
> specific part and other patch be go in vacancy for one week this night

I really hesitate to do that. It seems that not  using  the  compiler
provided library is not such a clever thing to do. The compile writes
probably  know  better  what  a  specific  version  of GCC needs that
anybody else.

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
The more complex the mind, the greater the need for the simplicity of
play.
	-- Kirk, "Shore Leave", stardate 3025.8

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090712120655.GA21713@game.jcrosoft.org> you wrote:
>>> It will hush up the current errors, but that's actually a  bad  thing
>>> here  -  the  errors  are  an indication that Jean-Christophe's patch
>>> might not be working as it is supposed to.
>> They do fix what they are suppose to , fix FPU and EABI problem which was
>> re-introduce by the 64 bit mtd support
>> here the problem is different you try to div64 which is not supported on arm
>> you do need to do_div
> 
> What do you mean - not supported by ARM?  Of course ARM supports 64
> bit division.
> 
> Compiling this little test code:
> 
> 	long long div(long long x, long long y)
> 	{
> 	        return x / y;
> 	}
> 
> will result in a call to  __aeabi_ldivmod  using  an  EABI  compliant
> version  of  GCC,  resp.  to __divdi3 using an older compiler. So GCC
> knows how to handle this, and it provides adequate  functions  to  do
> it.
> 
>> please apply this patch so I'll be able to send a pull request with the arm
>> specific part and other patch be go in vacancy for one week this night
> 
> I really hesitate to do that. It seems that not  using  the  compiler
> provided library is not such a clever thing to do. The compile writes
> probably  know  better  what  a  specific  version  of GCC needs that
> anybody else.

Yes, you are basically right. But ;)

But, as Jean-Christophe mentioned above, it's a pain with the various 
ARM tool chains floating around. Some are older, some are newer, some 
are configured for EABI, some not, some are configured for software 
floating point, some for hardware floating point, etc., etc.

While I as developer might be able to find a recent tool chain with a 
libgcc compatible with U-Boot, I think we should avoid this pain for 
our users. Users which like to "just compile U-Boot" and then we tell 
them "well, your tool chain you seem to be happy with doesn't link 
U-Boot, for U-Boot you have to install an other one" I think wouldn't 
make them happy.

Regarding not using the compilers library and if this clever: No, it 
isn't clever, you are right again. The compiler's library version is 
most probably better optimized. But, we are dealing with a boot loader 
here. So for the topic we discuss here, I think avoiding some pain for 
us ("my tool chain doesn't compile U-Boot, help!" mails at this list) 
and our users (see above) is the stronger argument than some 
optimization/performance issues in some (seldom?) used math functions.

Best regards

Dirk

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Dirk,

In message <4A59F95A.6060803@googlemail.com> you wrote:
> 
> > I really hesitate to do that. It seems that not  using  the  compiler
> > provided library is not such a clever thing to do. The compile writes
> > probably  know  better  what  a  specific  version  of GCC needs that
> > anybody else.
> 
> Yes, you are basically right. But ;)
> 
> But, as Jean-Christophe mentioned above, it's a pain with the various 
> ARM tool chains floating around. Some are older, some are newer, some 
> are configured for EABI, some not, some are configured for software 
> floating point, some for hardware floating point, etc., etc.

Right. And each of these is supposed to come with it's own version of
libgcc, configured exactly for  the  requirements  of  this  specific
version and configuration of GCC.

And it turns out that the majority of architectures works  just  fine
with  such  a setup, just using libgcc for functions required for and
provided by the compiler.

If the compiler provided functions cannot be used,  this  is  IMO  an
indication  of  a  broken toolchain, which should either be fixed (if
it's under some form of maintenance) or abandoned (because  you  will
have the same problems again in other situations outside of U-Boot).

> While I as developer might be able to find a recent tool chain with a 
> libgcc compatible with U-Boot, I think we should avoid this pain for 
> our users. Users which like to "just compile U-Boot" and then we tell 
> them "well, your tool chain you seem to be happy with doesn't link 
> U-Boot, for U-Boot you have to install an other one" I think wouldn't 
> make them happy.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Dirk,
> 
> In message <4A59F95A.6060803@googlemail.com> you wrote:
>>> I really hesitate to do that. It seems that not  using  the  compiler
>>> provided library is not such a clever thing to do. The compile writes
>>> probably  know  better  what  a  specific  version  of GCC needs that
>>> anybody else.
>> Yes, you are basically right. But ;)
>>
>> But, as Jean-Christophe mentioned above, it's a pain with the various 
>> ARM tool chains floating around. Some are older, some are newer, some 
>> are configured for EABI, some not, some are configured for software 
>> floating point, some for hardware floating point, etc., etc.
> 
> Right. And each of these is supposed to come with it's own version of
> libgcc, configured exactly for  the  requirements  of  this  specific
> version and configuration of GCC.
> 
> And it turns out that the majority of architectures works  just  fine
> with  such  a setup, just using libgcc for functions required for and
> provided by the compiler.
> 
> If the compiler provided functions cannot be used,  this  is  IMO  an
> indication  of  a  broken toolchain, which should either be fixed (if
> it's under some form of maintenance) or abandoned (because  you  will
> have the same problems again in other situations outside of U-Boot).
> 
>> While I as developer might be able to find a recent tool chain with a 
>> libgcc compatible with U-Boot, I think we should avoid this pain for 
>> our users. Users which like to "just compile U-Boot" and then we tell 
>> them "well, your tool chain you seem to be happy with doesn't link 
>> U-Boot, for U-Boot you have to install an other one" I think wouldn't 
>> make them happy.
> 
>>From the technical point of view it is only reasonable to  point  out
> that  these  users have a broken toolchain, and that they should take
> the first opportunity to fix or replace it.
> 
> Of course it it nice if we can also provide a workaround for them, so
> they can update at a point in time that is convenient to them. But the
> implementation of such a workaround should be clean, and eventually be
> used only for systems that really need it.
 >
> In no case we should make the use of such a workaround for broken
> setups the rule which has to be used by all systems (and eventually
> all architectures, even those that never had such problems in the
> first place).

Ah, I understand, most probably we are not aligned about what we talk, 
sorry. Yes, I know, there was some discussion about the Makefiles and 
that there are some requests to change them. Unfortunately, I'm no 
Makefile expert.

So I'm only talking about ARM systems/architecture. If the Makefiles 
discussed previously touch other systems/architectures, too, then this 
is not what I'm talking about.

> This is why I really hesitate to apply these patches - they make  the
> workaround for a few broken systems the rule, instead of making clear
> that this is an exception needed only by some (broken) systems.

For me the broken systems are in a first step ARM tool chains. Nothing 
more. Not sure if we can limit it to a sub-group of ARM systems, 
though? E.g. would it possible to have a CONFIG_SYS_DONT_RELY_ON_LIBGCC?

>> Regarding not using the compilers library and if this clever: No, it 
>> isn't clever, you are right again. The compiler's library version is 
>> most probably better optimized. But, we are dealing with a boot loader 
> 
> This is  in  no  way  a  question  of  optimization.  If  we  provide
> replacements  for  the  libgcc  functions, _we_ will have to maintain
> these and make sure they work correctly with all versions of GCC that
> exist in the multiverse and with all of their possible and impossible
> configurations. 

It was my understanding that Jean-Christophe copied this code from 
kernel? Like we do with some other systems, e.g. MTD? So it's 
maintained by kernel developers? Sorry if I missed something here.

> That's a lot of work we put on ouw own back for - for
> what?
> 
>> here. So for the topic we discuss here, I think avoiding some pain for 
>> us ("my tool chain doesn't compile U-Boot, help!" mails at this list) 
>> and our users (see above) is the stronger argument than some 
>> optimization/performance issues in some (seldom?) used math functions.
> 
> I think that answering a few mails, pointing out known problems  with
> broken  tool chains requires by far less amount of effort than adding
> this code. Heck, discussing and testing of this  patch  took  already
> way more of my time than replying to all related messages in the last
> 3 years together...
> 
> 
> I think the patch needs to be  changed  such  that  it  needs  to  be
> specifically  enabled for broken tool chains, and that by default all
> systems behave the same, i. e. assume a working tool  chain  and  use
> libgcc.

Yes. I talk about "broken tool chains == ARM tool chains". Nothing 
more. If the Makefile changes in the patches we talk about do some 
more, then that's not what I mean.

Best regards

Dirk

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:50 Sun 12 Jul     , Wolfgang Denk wrote:
> Dear Dirk,
> 
> In message <4A59F95A.6060803@googlemail.com> you wrote:
> > 
> > > I really hesitate to do that. It seems that not  using  the  compiler
> > > provided library is not such a clever thing to do. The compile writes
> > > probably  know  better  what  a  specific  version  of GCC needs that
> > > anybody else.
> > 
> > Yes, you are basically right. But ;)
> > 
> > But, as Jean-Christophe mentioned above, it's a pain with the various 
> > ARM tool chains floating around. Some are older, some are newer, some 
> > are configured for EABI, some not, some are configured for software 
> > floating point, some for hardware floating point, etc., etc.
> 
> Right. And each of these is supposed to come with it's own version of
> libgcc, configured exactly for  the  requirements  of  this  specific
> version and configuration of GCC.
the problem is that it's not really possible on arm
because you will need a toolchain for u-boot and an other for the userland
and in somecase an other for the kernel

We can not trust at all the libgcc provide by the toolchains we have see this
kind of problem thousand of times on the kernel and of course in U-Boot
and it's not the only arch to have this kind of problem the mips have too.

I can give 10's of toolchains which are correctly configured but never acheive
to build u-boot or the kernel just because of the libgcc.

Btw it will not be a huge work for U-Boot at all as we do this job in the
kernel anyway

Best Regards,
J.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Dirk Behme,

In message <4A5A0B5B.2010408@googlemail.com> you wrote:
> 
> > Of course it it nice if we can also provide a workaround for them, so
> > they can update at a point in time that is convenient to them. But the
> > implementation of such a workaround should be clean, and eventually be
> > used only for systems that really need it.
>  >
> > In no case we should make the use of such a workaround for broken
> > setups the rule which has to be used by all systems (and eventually
> > all architectures, even those that never had such problems in the
> > first place).
> 
> Ah, I understand, most probably we are not aligned about what we talk, 
> sorry. Yes, I know, there was some discussion about the Makefiles and 
> that there are some requests to change them. Unfortunately, I'm no 
> Makefile expert.
> 
> So I'm only talking about ARM systems/architecture. If the Makefiles 
> discussed previously touch other systems/architectures, too, then this 
> is not what I'm talking about.

Note that this is not a question of ARM versus  other  architectures.
On  ARM  the  use  of  libgcc should be the default like on all other
architectures - only if needed it should be possible to switch  on  a
don't-use-libgcc  mode,  but  this  should  then  be  independent  of
architecture, either.

> > This is why I really hesitate to apply these patches - they make  the
> > workaround for a few broken systems the rule, instead of making clear
> > that this is an exception needed only by some (broken) systems.
> 
> For me the broken systems are in a first step ARM tool chains. Nothing 
> more. Not sure if we can limit it to a sub-group of ARM systems, 
> though? E.g. would it possible to have a CONFIG_SYS_DONT_RELY_ON_LIBGCC?

That would be a board specific thing, which is inappropriate,  as  it
does  not  depend on a specific board. The selection could be done by
passing some argument or environment variables to "make", though.

> > This is  in  no  way  a  question  of  optimization.  If  we  provide
> > replacements  for  the  libgcc  functions, _we_ will have to maintain
> > these and make sure they work correctly with all versions of GCC that
> > exist in the multiverse and with all of their possible and impossible
> > configurations. 
> 
> It was my understanding that Jean-Christophe copied this code from 
> kernel? Like we do with some other systems, e.g. MTD? So it's 
> maintained by kernel developers? Sorry if I missed something here.

Even if it's maintained in Linux, we still have to follow any changes
there, and port these to U-Boot, and analyse each new problem popping
up by future uses of C statements that cause GCC to generate libgcc
calls - that may or may not be covered by the kernel provided code.

No matter where we get the code from, an ongoing effort will be
needed to maintain this.

> Yes. I talk about "broken tool chains == ARM tool chains". Nothing 

This is where I disagree. Why should we automatically assume that
there are no sane ARM toolchains?

We should always assume to have a usable toolchain  first,  and  only
fall  back  on the workaround if it's really necessary - no matter if
it's ARM or anything else.

Binding this to ARM is IMHO inherently wrong.

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
That said, there may be good reasons for what you did beyond obsequi-
ous sycophantic parody. Perhaps you might be so kind as to elucidate.
         -- Tom Christiansen in <5ldjbm$jtk$1@csnews.cs.colorado.edu>

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090712161700.GD21651@game.jcrosoft.org> you wrote:
>
> > Right. And each of these is supposed to come with it's own version of
> > libgcc, configured exactly for  the  requirements  of  this  specific
> > version and configuration of GCC.
> the problem is that it's not really possible on arm
> because you will need a toolchain for u-boot and an other for the userland
> and in somecase an other for the kernel

You mean it is impossible to build a tool chain for ARM that can be
used to build U-Boot, Linux, and user space code?  I can't believe
that ARM support in GCC is that seriously broken.

> We can not trust at all the libgcc provide by the toolchains we have see this
> kind of problem thousand of times on the kernel and of course in U-Boot
> and it's not the only arch to have this kind of problem the mips have too.

What do you mean?  Are  there  examples  where  the  libgcc  provided
functions  are  incorrect?  But  then  -  isn't the Linux kernel code
drived from the very same set of sources?

The only problems that I have seen in the past is  that  for  example
libgcc   code   assumes  hardware  FP  support  (ironically  even  on
processors that never had a FPU) while U-Boot uses "-msoft-float". In
that case it would be sufficient  if  the  GCC  builders  provided  a
version of libgcc configured for soft-float.

Are you aware of problems that have a different nature, i. e. where
the libgcc provided source code is actually incorrect for some
system?

> I can give 10's of toolchains which are correctly configured but never acheive
> to build u-boot or the kernel just because of the libgcc.

The questionhere is probably how you define "correctly". If these tool
chains are supposed to be used for U-Boot and kenrel development, then
they are probably at least not complete. 

> Btw it will not be a huge work for U-Boot at all as we do this job in the
> kernel anyway

You still have to keep both in sync.

And as I mantioned before: I do not oppose the change itself. I agree
that it is useful and actually a very good idea to support users  who
really  need  this.  The only things I oppose are (1) making this the
default (or even mandatory) for all tool chains  and  (2)  making  it
architecture-dependent.

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
In the beginning, there was nothing, which exploded.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090712161700.GD21651@game.jcrosoft.org> you wrote:
>>> Right. And each of these is supposed to come with it's own version of
>>> libgcc, configured exactly for  the  requirements  of  this  specific
>>> version and configuration of GCC.
>> the problem is that it's not really possible on arm
>> because you will need a toolchain for u-boot and an other for the userland
>> and in somecase an other for the kernel
> 
> You mean it is impossible to build a tool chain for ARM that can be
> used to build U-Boot, Linux, and user space code?  I can't believe
> that ARM support in GCC is that seriously broken.
> 
>> We can not trust at all the libgcc provide by the toolchains we have see this
>> kind of problem thousand of times on the kernel and of course in U-Boot
>> and it's not the only arch to have this kind of problem the mips have too.
> 
> What do you mean?  Are  there  examples  where  the  libgcc  provided
> functions  are  incorrect?  But  then  -  isn't the Linux kernel code
> drived from the very same set of sources?
> 
> The only problems that I have seen in the past is  that  for  example
> libgcc   code   assumes  hardware  FP  support  (ironically  even  on
> processors that never had a FPU) while U-Boot uses "-msoft-float". In
> that case it would be sufficient  if  the  GCC  builders  provided  a
> version of libgcc configured for soft-float.
> 
> Are you aware of problems that have a different nature, i. e. where
> the libgcc provided source code is actually incorrect for some
> system?
> 
>> I can give 10's of toolchains which are correctly configured but never acheive
>> to build u-boot or the kernel just because of the libgcc.
> 
> The questionhere is probably how you define "correctly". If these tool
> chains are supposed to be used for U-Boot and kenrel development, then
> they are probably at least not complete. 
> 
>> Btw it will not be a huge work for U-Boot at all as we do this job in the
>> kernel anyway
> 
> You still have to keep both in sync.
> 
> And as I mantioned before: I do not oppose the change itself. I agree
> that it is useful and actually a very good idea to support users  who
> really  need  this.  The only things I oppose are (1) making this the
> default (or even mandatory) for all tool chains  and  (2)  making  it
> architecture-dependent.

So to do in in positive logic, what do you propose how to enable it? 
In the other mail you mentioned "The selection could be done by 
passing some argument or environment variables to "make""?

Maybe you could give some (Makefile?) (pseudo?) code that 
Jean-Christophe gets an idea how to do this correctly? Sorry if this 
was given already in the Makefile discussion and I missed it.

Many thanks

Dirk

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:17 Sun 12 Jul     , Wolfgang Denk wrote:
> Dear Dirk Behme,
> 
> In message <4A5A0B5B.2010408@googlemail.com> you wrote:
> > 
> > > Of course it it nice if we can also provide a workaround for them, so
> > > they can update at a point in time that is convenient to them. But the
> > > implementation of such a workaround should be clean, and eventually be
> > > used only for systems that really need it.
> >  >
> > > In no case we should make the use of such a workaround for broken
> > > setups the rule which has to be used by all systems (and eventually
> > > all architectures, even those that never had such problems in the
> > > first place).
> > 
> > Ah, I understand, most probably we are not aligned about what we talk, 
> > sorry. Yes, I know, there was some discussion about the Makefiles and 
> > that there are some requests to change them. Unfortunately, I'm no 
> > Makefile expert.
> > 
> > So I'm only talking about ARM systems/architecture. If the Makefiles 
> > discussed previously touch other systems/architectures, too, then this 
> > is not what I'm talking about.
> 
> Note that this is not a question of ARM versus  other  architectures.
> On  ARM  the  use  of  libgcc should be the default like on all other
> architectures - only if needed it should be possible to switch  on  a
> don't-use-libgcc  mode,  but  this  should  then  be  independent  of
> architecture, either.
which is the case no arch are force to switch the current patch just allow
to switch to this mode.
> 
> > > This is why I really hesitate to apply these patches - they make  the
> > > workaround for a few broken systems the rule, instead of making clear
> > > that this is an exception needed only by some (broken) systems.
> > 
> > For me the broken systems are in a first step ARM tool chains. Nothing 
> > more. Not sure if we can limit it to a sub-group of ARM systems, 
> > though? E.g. would it possible to have a CONFIG_SYS_DONT_RELY_ON_LIBGCC?
> 
> That would be a board specific thing, which is inappropriate,  as  it
> does  not  depend on a specific board. The selection could be done by
> passing some argument or environment variables to "make", though.
> 
> > > This is  in  no  way  a  question  of  optimization.  If  we  provide
> > > replacements  for  the  libgcc  functions, _we_ will have to maintain
> > > these and make sure they work correctly with all versions of GCC that
> > > exist in the multiverse and with all of their possible and impossible
> > > configurations. 
> > 
> > It was my understanding that Jean-Christophe copied this code from 
> > kernel? Like we do with some other systems, e.g. MTD? So it's 
> > maintained by kernel developers? Sorry if I missed something here.
> 
> Even if it's maintained in Linux, we still have to follow any changes
> there, and port these to U-Boot, and analyse each new problem popping
> up by future uses of C statements that cause GCC to generate libgcc
> calls - that may or may not be covered by the kernel provided code.
> 
> No matter where we get the code from, an ongoing effort will be
> needed to maintain this.
> 
> > Yes. I talk about "broken tool chains == ARM tool chains". Nothing 
> 
> This is where I disagree. Why should we automatically assume that
> there are no sane ARM toolchains?
unfortunately most of the arm toolchains are not sane for every point of view
as you can not build U-Boot, kernel and userland with the same optimized
toolchain most of the time.

Maybe oneday we can assume that we could use any arm toolchain to build the
3, but for now I can assure it's not the case.

On other it maybe not the case but as example on mips we have similar issue
to workaround to be able to build U-Boot & Kernel

Best Regards,
J.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Dirk,

In message <4A5A3439.9000208@googlemail.com> you wrote:
> 
> > And as I mantioned before: I do not oppose the change itself. I agree
> > that it is useful and actually a very good idea to support users  who
> > really  need  this.  The only things I oppose are (1) making this the
> > default (or even mandatory) for all tool chains  and  (2)  making  it
> > architecture-dependent.
> 
> So to do in in positive logic, what do you propose how to enable it? 
> In the other mail you mentioned "The selection could be done by 
> passing some argument or environment variables to "make""?

Right.

> Maybe you could give some (Makefile?) (pseudo?) code that 
> Jean-Christophe gets an idea how to do this correctly? Sorry if this 
> was given already in the Makefile discussion and I missed it.

No example was given yet.

If someone puts enough effort into it, a clean  implementation  would
probably provide a "spec string" with a "%G" definition to the CFLAGS
and thus to the cross compiler's command-line options to override the
GCC-provided  definition of 'libgcc' with a new (U-Boot provided) one
(see gcc.info, Node: Spec Files, Section 3.15 Specifying subprocesses
and the switches to pass to them).

A simpler implementation  could  use  the  '-B_prefix_'  command-line
option to select a different run-time support library.

The feature itself could for example be triggered by using something
like

	$ make USE_PRIVATE_LIBGCC=yes

or
	$ USE_PRIVATE_LIBGCC=yes
	$ export USE_PRIVATE_LIBGCC
	$ make

or similar.

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
Philosophy is a game with objectives and no rules.
Mathematics is a game with rules and no objectives.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090712192216.GA1686@game.jcrosoft.org> you wrote:
>
> > Note that this is not a question of ARM versus  other  architectures.
> > On  ARM  the  use  of  libgcc should be the default like on all other
> > architectures - only if needed it should be possible to switch  on  a
> > don't-use-libgcc  mode,  but  this  should  then  be  independent  of
> > architecture, either.
> which is the case no arch are force to switch the current patch just allow
> to switch to this mode.

My understanding was that the current patch (1) makes not using
lingcc the default for ARM, and (2) makes it the default for ARM for
all too chains.

Please show me how to activate the feature from the command line, as
I seem to have missed this option (and the documentation for it).

> > This is where I disagree. Why should we automatically assume that
> > there are no sane ARM toolchains?
> unfortunately most of the arm toolchains are not sane for every point of view
> as you can not build U-Boot, kernel and userland with the same optimized
> toolchain most of the time.

But ARM is just one out of many different  architectures,  and  there
are  eventually  (sufficently)  sane  ARM tool chains available, too.
This is the default case, and shall remain it.

For broken tool chains (ARM or other) the feature can be activated
(when running make).


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
Blast medicine anyway!  We've learned to tie into every organ in the
human body but one.  The brain!  The brain is what life is all about.
	-- McCoy, "The Menagerie", stardate 3012.4

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:35 Sun 12 Jul     , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090712192216.GA1686@game.jcrosoft.org> you wrote:
> >
> > > Note that this is not a question of ARM versus  other  architectures.
> > > On  ARM  the  use  of  libgcc should be the default like on all other
> > > architectures - only if needed it should be possible to switch  on  a
> > > don't-use-libgcc  mode,  but  this  should  then  be  independent  of
> > > architecture, either.
> > which is the case no arch are force to switch the current patch just allow
> > to switch to this mode.
> 
> My understanding was that the current patch (1) makes not using
> lingcc the default for ARM, and (2) makes it the default for ARM for
> all too chains.
the current patch do 2 thinks
PATCH 1 allow to switch or not (by default use the toolchains libgcc)
PATCH 2 for ARM only switch and do not use the libgcc anymore
> 
> Please show me how to activate the feature from the command line, as
> I seem to have missed this option (and the documentation for it).
> 
> > > This is where I disagree. Why should we automatically assume that
> > > there are no sane ARM toolchains?
> > unfortunately most of the arm toolchains are not sane for every point of view
> > as you can not build U-Boot, kernel and userland with the same optimized
> > toolchain most of the time.
> 
> But ARM is just one out of many different  architectures,  and  there
> are  eventually  (sufficently)  sane  ARM tool chains available, too.
> This is the default case, and shall remain it.
> 
> For broken tool chains (ARM or other) the feature can be activated
> (when running make).
Currently on arm you have more unsane toolchains than sane

so I'll prefer to avoid the dual config as it will be safer
I've test recently gcc-4.4.0 and it's the same you still have the problem
you build some of the board but not all of them

here is my status
I've test to MAKEALL arm with the following toolchains on the current U-Boot
ARM tree and different arch for the kernel
I'll avoid the gcc-3.x.x
		U-Boot		Kernel (without libgcc)	Kernel (with libgcc)
gcc-4.1.1	Fail		Fail				Fail
gcc-4.1.2	Fail		OK				Fail
gcc-4.2.1	Fail		OK				Fail
gcc-4.2.4	Fail		OK				Fail
gcc-4.3.2	Fail		OK				Fail
gcc-4.4.0	Fail		not tested			not tested

Fail = mean one or more board fail to build evenif for the kernel there are
       reported ok by the autobuild kernel tool
OK   = all build (do not count the board report broken for the kernel by the
       autobuild kernel tool)

Best Regards,
J.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090712195107.GC1686@game.jcrosoft.org> you wrote:
>
> > > > On  ARM  the  use  of  libgcc should be the default like on all other
> > > > architectures - only if needed it should be possible to switch  on  a
> > > > don't-use-libgcc  mode,  but  this  should  then  be  independent  of
> > > > architecture, either.
> > > which is the case no arch are force to switch the current patch just allow
> > > to switch to this mode.
> > 
> > My understanding was that the current patch (1) makes not using
> > lingcc the default for ARM, and (2) makes it the default for ARM for
> > all too chains.
> the current patch do 2 thinks
> PATCH 1 allow to switch or not (by default use the toolchains libgcc)

The switch will be based on a configuration setting, i.  e.  you  can
change  it  only  by changing the source code. You cannot for example
compile the very same source code  (without  any  changes  to  U-Boot
source  files) one time with and one time without using libgcc.

> PATCH 2 for ARM only switch and do not use the libgcc anymore

So it makes it not only the default, but actually the only  supported
setting (assuming you do not change the source code).

Thanks for explaining the implementation to me.

> > > unfortunately most of the arm toolchains are not sane for every point of view
> > > as you can not build U-Boot, kernel and userland with the same optimized
> > > toolchain most of the time.
> > 
> > But ARM is just one out of many different  architectures,  and  there
> > are  eventually  (sufficently)  sane  ARM tool chains available, too.
> > This is the default case, and shall remain it.
> > 
> > For broken tool chains (ARM or other) the feature can be activated
> > (when running make).
> Currently on arm you have more unsane toolchains than sane

Maybe. This does not change any of my arguments.


I have made up my mind. I hereby reject patches 1 and 2 in their
current form.

To have the patches accepted for imainline, use of libgcc  should  be
the  common  default  setting for all architectures, and switching of
the use of libgcc should be possible for any board and any  architec-
ture without having to change any file in the U-Boot source tree.

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
No question is too silly to ask. Of course, some  questions  are  too
silly to to answer...  - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Stefan Roese]

Hi Wolfgang,

On Sunday 12 July 2009 12:29:32 Wolfgang Denk wrote:
> > > Any idea why this still happens *with* libgcc patches? Any idea how to
> > > fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too?
> >
> > I have to admit that I'm not sure why this is the case. But I suggest
> > that you take a look at Simon's patch sent to the list a few days ago:
> >
> > [PATCH 5/8]: Use do_div from div64.h for vsprintf
> >
> > This should fix this issue.
>
> It will hush up the current errors, but that's actually a  bad  thing
> here  -  the  errors  are  an indication that Jean-Christophe's patch
> might not be working as it is supposed to.

From my point of view those two patches address different issues. I just 
noticed that Simon's patch solved some of the current ARM toolchain problems 
as well. That's why I referred to it.

So I think that regardless of this ARM libgcc discussion, we should apply 
Simons patch "[PATCH 5/8]: Use do_div from div64.h for vsprintf" as it uses 
the common do_div() implementation instead of a local version.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Mike Frysinger]

On Sunday 12 July 2009 14:29:46 Wolfgang Denk wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > Right. And each of these is supposed to come with it's own version of
> > > libgcc, configured exactly for  the  requirements  of  this  specific
> > > version and configuration of GCC.
> >
> > the problem is that it's not really possible on arm
> > because you will need a toolchain for u-boot and an other for the
> > userland and in somecase an other for the kernel
>
> You mean it is impossible to build a tool chain for ARM that can be
> used to build U-Boot, Linux, and user space code?  I can't believe
> that ARM support in GCC is that seriously broken.

basically, that is correct.  arm's libgcc is just that whacky because of all 
the different ABIs that exist.  although citing the Linux kernel here may not 
be appropriate because they specifically avoid libgcc -- because it's so 
screwed up.

last i looked, some of the math functions in arm's libgcc depended on C 
library functions (like raise() and abort()).  this is the kind of stuff Jean 
is trying to avoid.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090713/565cb534/attachment.pgp 

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Stefan Roese wrote:
> Hi Wolfgang,
> 
> On Sunday 12 July 2009 12:29:32 Wolfgang Denk wrote:
>>>> Any idea why this still happens *with* libgcc patches? Any idea how to
>>>> fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too?
>>> I have to admit that I'm not sure why this is the case. But I suggest
>>> that you take a look at Simon's patch sent to the list a few days ago:
>>>
>>> [PATCH 5/8]: Use do_div from div64.h for vsprintf
>>>
>>> This should fix this issue.
>> It will hush up the current errors, but that's actually a  bad  thing
>> here  -  the  errors  are  an indication that Jean-Christophe's patch
>> might not be working as it is supposed to.
> 
>>From my point of view those two patches address different issues. I just 
> noticed that Simon's patch solved some of the current ARM toolchain problems 
> as well. That's why I referred to it.
> 
> So I think that regardless of this ARM libgcc discussion, we should apply 
> Simons patch "[PATCH 5/8]: Use do_div from div64.h for vsprintf" as it uses 
> the common do_div() implementation instead of a local version.

Yes, please.

Thanks,

Dirk

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Mike Frysinger wrote:
> On Sunday 12 July 2009 14:29:46 Wolfgang Denk wrote:
>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>> Right. And each of these is supposed to come with it's own version of
>>>> libgcc, configured exactly for  the  requirements  of  this  specific
>>>> version and configuration of GCC.
>>> the problem is that it's not really possible on arm
>>> because you will need a toolchain for u-boot and an other for the
>>> userland and in somecase an other for the kernel
>> You mean it is impossible to build a tool chain for ARM that can be
>> used to build U-Boot, Linux, and user space code?  I can't believe
>> that ARM support in GCC is that seriously broken.
> 
> basically, that is correct.  arm's libgcc is just that whacky because of all 
> the different ABIs that exist.  although citing the Linux kernel here may not 
> be appropriate because they specifically avoid libgcc -- because it's so 
> screwed up.
> 
> last i looked, some of the math functions in arm's libgcc depended on C 
> library functions (like raise() and abort()).  this is the kind of stuff Jean 
> is trying to avoid.

Yes, this is my understanding, too.

Conclusion seems to be that we can get this feature/functionality if 
it is configurable using the way Wolfgang proposed in

http://lists.denx.de/pipermail/u-boot/2009-July/056185.html

Best regards

Dirk

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Mike Frysinger]

On Monday 13 July 2009 03:36:39 Stefan Roese wrote:
> On Sunday 12 July 2009 12:29:32 Wolfgang Denk wrote:
> > > > Any idea why this still happens *with* libgcc patches? Any idea how
> > > > to fix this? Add __umoddi3 and __udivdi3 to libgcc patch, too?
> > >
> > > I have to admit that I'm not sure why this is the case. But I suggest
> > > that you take a look at Simon's patch sent to the list a few days ago:
> > >
> > > [PATCH 5/8]: Use do_div from div64.h for vsprintf
> > >
> > > This should fix this issue.
> >
> > It will hush up the current errors, but that's actually a  bad  thing
> > here  -  the  errors  are  an indication that Jean-Christophe's patch
> > might not be working as it is supposed to.
>
> From my point of view those two patches address different issues. I just
> noticed that Simon's patch solved some of the current ARM toolchain
> problems as well. That's why I referred to it.
>
> So I think that regardless of this ARM libgcc discussion, we should apply
> Simons patch "[PATCH 5/8]: Use do_div from div64.h for vsprintf" as it uses
> the common do_div() implementation instead of a local version.

correct.  doing 64bit math is expensive and should be avoided.  this is 
another reason the linux kernel includes libgcc -- they dont import many of 
the 64bit math functions because it's so expensive and 99% of the time, it's 
wrong.  when the source uses it, they get link failures right away.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090713/0f3bd181/attachment.pgp 

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Scott Wood]

On Mon, Jul 13, 2009 at 05:25:35AM -0400, Mike Frysinger wrote:
> On Sunday 12 July 2009 14:29:46 Wolfgang Denk wrote:
> > You mean it is impossible to build a tool chain for ARM that can be
> > used to build U-Boot, Linux, and user space code?  I can't believe
> > that ARM support in GCC is that seriously broken.
> 
> basically, that is correct.  arm's libgcc is just that whacky because of all 
> the different ABIs that exist.  although citing the Linux kernel here may not 
> be appropriate because they specifically avoid libgcc -- because it's so 
> screwed up.

Isn't that what multilib is for?

On a related note, I wish GCC had a "no-float" option that could be used
in place of soft-float.  It would be ABI-compatible with either soft or
hard float, because it doesn't use float at all (GCC would raise an error
if you try).

> last i looked, some of the math functions in arm's libgcc depended on C 
> library functions (like raise() and abort()).  this is the kind of stuff Jean 
> is trying to avoid.

It seems pretty reasonable for U-Boot to provide functions like
raise()/abort() that take the place of a hardware exception, and display
an error message.

-Scott

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Mike Frysinger]

On Wednesday 15 July 2009 18:18:20 Scott Wood wrote:
> On Mon, Jul 13, 2009 at 05:25:35AM -0400, Mike Frysinger wrote:
> > On Sunday 12 July 2009 14:29:46 Wolfgang Denk wrote:
> > > You mean it is impossible to build a tool chain for ARM that can be
> > > used to build U-Boot, Linux, and user space code?  I can't believe
> > > that ARM support in GCC is that seriously broken.
> >
> > basically, that is correct.  arm's libgcc is just that whacky because of
> > all the different ABIs that exist.  although citing the Linux kernel here
> > may not be appropriate because they specifically avoid libgcc -- because
> > it's so screwed up.
>
> Isn't that what multilib is for?

yes, but Jean is attempting to deal with reality of arm toolchains rather than 
telling users to go install one that isnt broken

> > last i looked, some of the math functions in arm's libgcc depended on C
> > library functions (like raise() and abort()).  this is the kind of stuff
> > Jean is trying to avoid.
>
> It seems pretty reasonable for U-Boot to provide functions like
> raise()/abort() that take the place of a hardware exception, and display
> an error message.

i disagree here.  how much of the C library are you proposing we implement ?  
if libgcc keeps calling more and more functions, you suggest we keep adding 
stubs for it ?  seems like a never ending losing battle where we get screwed.  
(well, *i'm* not getting screwed because i dont care about u-boot on arm ;])
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090715/7319cfbb/attachment.pgp 

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Scott Wood]

Mike Frysinger wrote:
> On Wednesday 15 July 2009 18:18:20 Scott Wood wrote:
>> It seems pretty reasonable for U-Boot to provide functions like
>> raise()/abort() that take the place of a hardware exception, and display
>> an error message.
> 
> i disagree here.  how much of the C library are you proposing we implement ?  
> if libgcc keeps calling more and more functions,

Has it been?

> you suggest we keep adding stubs for it ?  seems like a never ending losing battle where we get screwed.  

I don't see any slippery slope here, just a handful of functions that 
any reasonable freestanding implementation is going to want (memcpy, 
etc) and some way of getting an error out (raise/abort).

If it starts wanting libc functions that aren't reasonable, then of 
course we should complain (possibly with patches, for those willing to 
deal with the copyright assignment process).

-Scott

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Mike Frysinger]

On Wednesday 15 July 2009 19:03:36 Scott Wood wrote:
> Mike Frysinger wrote:
> > On Wednesday 15 July 2009 18:18:20 Scott Wood wrote:
> >> It seems pretty reasonable for U-Boot to provide functions like
> >> raise()/abort() that take the place of a hardware exception, and display
> >> an error message.
> >
> > i disagree here.  how much of the C library are you proposing we
> > implement ? if libgcc keeps calling more and more functions,
>
> Has it been?
>
> > you suggest we keep adding stubs for it ?  seems like a never ending
> > losing battle where we get screwed.
>
> I don't see any slippery slope here, just a handful of functions that
> any reasonable freestanding implementation is going to want (memcpy,
> etc) and some way of getting an error out (raise/abort).
>
> If it starts wanting libc functions that aren't reasonable, then of
> course we should complain (possibly with patches, for those willing to
> deal with the copyright assignment process).

i think calling raise/abort is already unreasonable for bare metal 
applications.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090715/77ce2643/attachment.pgp 

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Scott Wood,

In message <20090715221820.GA16203@b07421-ec1.am.freescale.net> you wrote:
> On Mon, Jul 13, 2009 at 05:25:35AM -0400, Mike Frysinger wrote:
...
> > basically, that is correct.  arm's libgcc is just that whacky because of all 
> > the different ABIs that exist.  although citing the Linux kernel here may not 
> > be appropriate because they specifically avoid libgcc -- because it's so 
> > screwed up.

I'm continually amazed to see again and again many otherwise clever
software developers investing efforts to solve the same problems again
and again locally in separate projects, instead of fixing them once at
the central point where the problem actually lies.

So instead of fixing the "screwed up" libgcc code for ARM such thatit
can be used for applications _and_ Linux kernel _and_ U-Boot and other
projects, we re-invent and copy and improve the code locally in each
project (and I cannot tell what would surprise me more - to hear that
the libgcc maintainers are not involved, or that they are).

Instead of adding a new feature to "make" once, Linux and several
other projects add complicated Makefile rules to produce "hort" output
like

	  CC      fs/inode.o
	  CALL    arch/powerpc/kernel/prom_init_check.sh
	  AS      arch/powerpc/kernel/head_32.o
	  LDS     arch/powerpc/kernel/vmlinux.lds

I always though softwre engineering was about _not_ re-inventing the
wheel again and again and again... :-(

> Isn't that what multilib is for?

hm... wrong forum to ask, I guess...

> On a related note, I wish GCC had a "no-float" option that could be used
> in place of soft-float.  It would be ABI-compatible with either soft or
> hard float, because it doesn't use float at all (GCC would raise an error
> if you try).

You should ask this on a GCC related list, or submit a proposal to the
GCC stearing committee.

> It seems pretty reasonable for U-Boot to provide functions like
> raise()/abort() that take the place of a hardware exception, and display
> an error message.

This does not sound reasonable to me.

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
In any group of employed individuals the only naturally  early  riser
is  _always_  the office manager, who will _always_ leave reproachful
little notes ... on the desks of their subordinates.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Scott Wood]

Mike Frysinger wrote:
> i think calling raise/abort is already unreasonable for bare metal 
> applications.

So how do you propose that illegal divide operations be reported to the 
application?

What is so unreasonable about having a function to print a message and 
dump registers?

You could even make it a weak symbol that stays at NULL, so any attempt 
to call it will trap that way (assuming NULL pointers are trapped in 
U-Boot on that architecture...).

-Scott

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Scott Wood,

In message <4A5F4913.5030808@freescale.com> you wrote:
> 
> So how do you propose that illegal divide operations be reported to the 
> application?

In the same way as Linux is doing it (i. e. usually nothing at all) ?

> What is so unreasonable about having a function to print a message and 
> dump registers?

We didn't need one for the so far. What exactly do we need it for now?

> You could even make it a weak symbol that stays at NULL, so any attempt 
> to call it will trap that way (assuming NULL pointers are trapped in 
> U-Boot on that architecture...).

As you know, they are not.

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
The shortest unit of time in the multiverse is the News York  Second,
defined  as  the  period  of  time between the traffic lights turning
green and the cab behind you honking.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Scott Wood]

On Thu, Jul 16, 2009 at 05:42:27PM +0200, Wolfgang Denk wrote:
> Dear Scott Wood,
> 
> In message <4A5F4913.5030808@freescale.com> you wrote:
> > 
> > So how do you propose that illegal divide operations be reported to the 
> > application?
> 
> In the same way as Linux is doing it (i. e. usually nothing at all) ?

Yay bugs.

> > What is so unreasonable about having a function to print a message and 
> > dump registers?
> 
> We didn't need one for the so far. What exactly do we need it for now?

For the same reason we have cpu/*/traps.c.

> > You could even make it a weak symbol that stays at NULL, so any attempt 
> > to call it will trap that way (assuming NULL pointers are trapped in 
> > U-Boot on that architecture...).
> 
> As you know, they are not.

If you're happy with not making it debuggable, then there's no need to
trap on the NULL -- just make sure it never happens. :-)

I'd much rather spend the handful of bytes on at least a
__builtin_trap(), though.

Or do compiler implementation specific things such as reimplementing
libgcc functions or carefully avoiding generating calls to them, if you
prefer.  Whatever.

-Scott

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Detlev Zundel]

Hi Scott,

>> > You could even make it a weak symbol that stays at NULL, so any attempt 
>> > to call it will trap that way (assuming NULL pointers are trapped in 
>> > U-Boot on that architecture...).
>> 
>> As you know, they are not.
>
> If you're happy with not making it debuggable, then there's no need to
> trap on the NULL -- just make sure it never happens. :-)
>
> I'd much rather spend the handful of bytes on at least a
> __builtin_trap(), though.

I also think that making our lifes easier is a very good thing.  Our
"it's only a bootloader" codebase is pretty complex already so I welcome
making it more robust.  I was kind of surprised the other day that
null-pointer jumps(*) did not result in immediate "bad programmer, no
cookie this time" messages but in random crashes.

Cheers
  Detlev

(*) well, actually they were jumps to _relocated_ NULL pointers, but
still ;)

-- 
I will use free software even if it is less powerful, or less reliable,
because freedom is the most important thing, and that is what the Free
Software movement is about.  How we get freedom.
                       -- Richard M. Stallman
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Detlev Zundel,

In message <m2r5wfzh0l.fsf@ohwell.denx.de> you wrote:
> 
> I also think that making our lifes easier is a very good thing.  Our
> "it's only a bootloader" codebase is pretty complex already so I welcome
> making it more robust.  I was kind of surprised the other day that
> null-pointer jumps(*) did not result in immediate "bad programmer, no
> cookie this time" messages but in random crashes.

Well, what do you suggest? remember for example that booting a  Linux
kernel  means  jumping to it's entry point address - which happens to
be 0 - or is this NULL ? How do you detemine the difference?

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
Vulcans do not approve of violence.
	-- Spock, "Journey to Babel", stardate 3842.4

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Detlev,

In message <20090717113714.4BF10832E416@gemini.denx.de> I wrote:
> 
> Well, what do you suggest? remember for example that booting a  Linux
> kernel  means  jumping to it's entry point address - which happens to
> be 0 - or is this NULL ? How do you detemine the difference?

... at least on PowerPC the EPA is 0.

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
We are all agreed that your  theory  is  crazy.  The  question  which
divides  us  is  whether it is crazy enough to have a chance of being
correct. My own feeling is that it is not crazy enough.  - Niels Bohr

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Scott Wood]

On Fri, Jul 17, 2009 at 01:37:14PM +0200, Wolfgang Denk wrote:
> Dear Detlev Zundel,
> 
> In message <m2r5wfzh0l.fsf@ohwell.denx.de> you wrote:
> > 
> > I also think that making our lifes easier is a very good thing.  Our
> > "it's only a bootloader" codebase is pretty complex already so I welcome
> > making it more robust.  I was kind of surprised the other day that
> > null-pointer jumps(*) did not result in immediate "bad programmer, no
> > cookie this time" messages but in random crashes.
> 
> Well, what do you suggest? remember for example that booting a  Linux
> kernel  means  jumping to it's entry point address - which happens to
> be 0 - or is this NULL ? How do you detemine the difference?

The MMU configuration that the OS wants on entry does not necessarily
have to be the same one that the majority of U-Boot code runs with.

-Scott

[U-Boot] [PATCH 2/2] netstar/voiceblue: remove no-need libgcc link for eeprom standalone

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1247085496-21754-2-git-send-email-plagnioj@jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
>  board/netstar/Makefile   |    3 +--
>  board/voiceblue/Makefile |    3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)

Sorry, patch does not apply:

Applying: netstar/voiceblue: netstar/voiceblue: remove no-need libgcc link for eeprom standalone
error: patch failed: board/netstar/Makefile:52
error: board/netstar/Makefile: patch does not apply
error: patch failed: board/voiceblue/Makefile:46
error: board/voiceblue/Makefile: patch does not apply
fatal: sha1 information is lacking or useless (board/netstar/Makefile).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.


Please clean up (and when doing so, please change the subject into
"don't link unneeded libgcc for eeprom standalone") and resubmit.
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
"Text processing has made it possible to right-justify any idea, even
one which cannot be justified on any other grounds."
                                                 -- J. Finnegan, USC.

[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1247135043-3494-1-git-send-email-plagnioj@jcrosoft.com> you wrote:
> This patch allows to override the libgcc Makefile inclusion from the toplevel
> Makefile by the arch config.mk files. This is in preparation for the ARM
> architecture to move away from including libgcc functions and only using
> self-contained U-Boot functions as done in Linux.
> 
> Currently all the ARM boards that use NAND are broken due to the addition of
> 64 Bit device size support. In the past we have seen similar problems with
> different tool chains due to EABI and FPU for example.
> 
> With this patch and this one: "ARM: Don't include libgcc anymore" we move away
> from all these problems on ARM since we don't include any functions from
> libgcc anymore.
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Acked-by: Mike Frysinger <vapier@gentoo.org>

As discussed before, I rejected this patch because it seems wrong to
me 1) to assume that all ARM tool chains have a broken/unusable
implementation of the libgcc runtime support library, 2) I don't want
to make a workaround for a broken tool chain the default setting, and
3) we should not restrict this to the ARM architecture but allow the
same for other architectures as well.

I suggested another approach in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63156/focus=63550
but no one commented on this.

As there are some people suffereing from the current situation and no
progress has been visible for some time, I wll soon post a patch that
implements my proposal.

Hope this allows to bring this topic to an end.

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
But it's real. And if it's real it can be affected ... we may not  be
able  to break it, but, I'll bet you credits to Navy Beans we can put
a dent in it.
	-- deSalle, "Catspaw", stardate 3018.2

[U-Boot] [PATCH] Make linking against libgcc configurable

[Wolfgang Denk]

Many (especially ARM) tool chains seem to come with broken or
otherwise unusable (for the purposes of builing U-Boot) run-time
support libraries `libgcc.a'. By using the "USE_PRIVATE_LIBGCC"
setting we allow to use alternative libraries instead.

"USE_PRIVATE_LIBGCC" can either be set as an environment variable in
the shell, or as a command line argument when running "make", i. e.
	$ make USE_PRIVATE_LIBGCC=yes
or
	$ USE_PRIVATE_LIBGCC=yes
	$ export USE_PRIVATE_LIBGCC
	$ make

The value of "USE_PRIVATE_LIBGCC" is the name of the directory which
contains the alternative run-time support library `libgcc.a'. The
special value "yes" selects the directory $(OBJTREE)/lib_$(ARCH) .

Note that not all architectures provide an alternative `libgcc.a' in
their lib_$(ARCH) directories - so far, only ARM does.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
cc: Stefan Roese <sr@denx.de>
---
 Makefile            |   12 +++++++++++-
 board/trab/Makefile |    4 +---
 lib_arm/Makefile    |   31 +++++++++++++++++++++++--------
 3 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/Makefile b/Makefile
index 25a6254..7c99ac2 100644
--- a/Makefile
+++ b/Makefile
@@ -247,7 +247,17 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
 LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
 
 # Add GCC lib
-PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+ifdef USE_PRIVATE_LIBGCC
+ifeq ("$(USE_PRIVATE_LIBGCC)", "yes")
+PLATFORM_LIBGCC = -L $(OBJTREE)/lib_$(ARCH) -lgcc
+else
+PLATFORM_LIBGCC = -L $(USE_PRIVATE_LIBGCC) -lgcc
+endif
+else
+PLATFORM_LIBGCC = -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+endif
+PLATFORM_LIBS += $(PLATFORM_LIBGCC)
+export PLATFORM_LIBS
 
 ifeq ($(CONFIG_NAND_U_BOOT),y)
 NAND_SPL = nand_spl
diff --git a/board/trab/Makefile b/board/trab/Makefile
index 3a92c0d..2afad88 100644
--- a/board/trab/Makefile
+++ b/board/trab/Makefile
@@ -36,8 +36,6 @@ SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
 OBJS_FKT := $(addprefix $(obj),$(COBJS_FKT))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0xc100000
 
 #########################################################################
@@ -52,7 +50,7 @@ $(obj)trab_fkt.srec:	$(OBJS_FKT) $(LIB)
 		-L$(obj)../../examples/standalone -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
 		$(obj)../../lib_arm/div0.o \
-		$(obj)../../lib_arm/_*.o
+		$(PLATFORM_LIBS)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)trab_fkt.bin:	$(obj)trab_fkt.srec
diff --git a/lib_arm/Makefile b/lib_arm/Makefile
index 4469361..30922a6 100644
--- a/lib_arm/Makefile
+++ b/lib_arm/Makefile
@@ -24,13 +24,17 @@
 include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(ARCH).a
+LIBGCC	= $(obj)libgcc.a
 
-SOBJS-y	+= _ashldi3.o
-SOBJS-y	+= _ashrdi3.o
-SOBJS-y	+= _divsi3.o
-SOBJS-y	+= _modsi3.o
-SOBJS-y	+= _udivsi3.o
-SOBJS-y	+= _umodsi3.o
+GLSOBJS	+= _ashldi3.o
+GLSOBJS	+= _ashrdi3.o
+GLSOBJS	+= _lshrdi3.o
+GLSOBJS	+= _divsi3.o
+GLSOBJS	+= _modsi3.o
+GLSOBJS	+= _udivsi3.o
+GLSOBJS	+= _umodsi3.o
+
+GLCOBJS	+= div0.o
 
 COBJS-y	+= board.o
 COBJS-y	+= bootm.o
@@ -38,16 +42,27 @@ COBJS-y	+= cache.o
 ifndef CONFIG_SYS_NO_CP15_CACHE
 COBJS-y	+= cache-cp15.o
 endif
-COBJS-y	+= div0.o
 COBJS-y	+= interrupts.o
 COBJS-y	+= reset.o
 
-SRCS	:= $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+SRCS	:= $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
+	   $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
 OBJS	:= $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
+LGOBJS	:= $(addprefix $(obj),$(GLSOBJS)) \
+	   $(addprefix $(obj),$(GLCOBJS))
+
+ifdef USE_PRIVATE_LIBGCC
+all:	$(LIB) $(LIBGCC)
+else
+all:	$(LIB)
+endif
 
 $(LIB):	$(obj).depend $(OBJS)
 	$(AR) $(ARFLAGS) $@ $(OBJS)
 
+$(LIBGCC): $(obj).depend $(LGOBJS)
+	$(AR) $(ARFLAGS) $@ $(LGOBJS)
+
 #########################################################################
 
 # defines $(obj).depend target
-- 
1.6.0.6

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Wolfgang Denk]

Many (especially ARM) tool chains seem to come with broken or
otherwise unusable (for the purposes of builing U-Boot) run-time
support libraries `libgcc.a'. By using the "USE_PRIVATE_LIBGCC"
setting we allow to use alternative libraries instead.

"USE_PRIVATE_LIBGCC" can either be set as an environment variable in
the shell, or as a command line argument when running "make", i. e.
	$ make USE_PRIVATE_LIBGCC=yes
or
	$ USE_PRIVATE_LIBGCC=yes
	$ export USE_PRIVATE_LIBGCC
	$ make

The value of "USE_PRIVATE_LIBGCC" is the name of the directory which
contains the alternative run-time support library `libgcc.a'. The
special value "yes" selects the directory $(OBJTREE)/lib_$(ARCH) .

Note that not all architectures provide an alternative `libgcc.a' in
their lib_$(ARCH) directories - so far, only ARM does.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
cc: Stefan Roese <sr@denx.de>
---
v2: Removed crap left over from testing.

 Makefile            |   12 +++++++++++-
 board/trab/Makefile |    4 +---
 lib_arm/Makefile    |   30 ++++++++++++++++++++++--------
 3 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/Makefile b/Makefile
index 25a6254..7c99ac2 100644
--- a/Makefile
+++ b/Makefile
@@ -247,7 +247,17 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
 LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
 
 # Add GCC lib
-PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+ifdef USE_PRIVATE_LIBGCC
+ifeq ("$(USE_PRIVATE_LIBGCC)", "yes")
+PLATFORM_LIBGCC = -L $(OBJTREE)/lib_$(ARCH) -lgcc
+else
+PLATFORM_LIBGCC = -L $(USE_PRIVATE_LIBGCC) -lgcc
+endif
+else
+PLATFORM_LIBGCC = -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
+endif
+PLATFORM_LIBS += $(PLATFORM_LIBGCC)
+export PLATFORM_LIBS
 
 ifeq ($(CONFIG_NAND_U_BOOT),y)
 NAND_SPL = nand_spl
diff --git a/board/trab/Makefile b/board/trab/Makefile
index 3a92c0d..2afad88 100644
--- a/board/trab/Makefile
+++ b/board/trab/Makefile
@@ -36,8 +36,6 @@ SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
 OBJS_FKT := $(addprefix $(obj),$(COBJS_FKT))
 
-gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`)
-
 LOAD_ADDR = 0xc100000
 
 #########################################################################
@@ -52,7 +50,7 @@ $(obj)trab_fkt.srec:	$(OBJS_FKT) $(LIB)
 		-L$(obj)../../examples/standalone -lstubs \
 		-L$(obj)../../lib_generic -lgeneric \
 		$(obj)../../lib_arm/div0.o \
-		$(obj)../../lib_arm/_*.o
+		$(PLATFORM_LIBS)
 	$(OBJCOPY) -O srec $(<:.o=) $@
 
 $(obj)trab_fkt.bin:	$(obj)trab_fkt.srec
diff --git a/lib_arm/Makefile b/lib_arm/Makefile
index 4469361..241782c 100644
--- a/lib_arm/Makefile
+++ b/lib_arm/Makefile
@@ -24,13 +24,16 @@
 include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(ARCH).a
+LIBGCC	= $(obj)libgcc.a
 
-SOBJS-y	+= _ashldi3.o
-SOBJS-y	+= _ashrdi3.o
-SOBJS-y	+= _divsi3.o
-SOBJS-y	+= _modsi3.o
-SOBJS-y	+= _udivsi3.o
-SOBJS-y	+= _umodsi3.o
+GLSOBJS	+= _ashldi3.o
+GLSOBJS	+= _ashrdi3.o
+GLSOBJS	+= _divsi3.o
+GLSOBJS	+= _modsi3.o
+GLSOBJS	+= _udivsi3.o
+GLSOBJS	+= _umodsi3.o
+
+GLCOBJS	+= div0.o
 
 COBJS-y	+= board.o
 COBJS-y	+= bootm.o
@@ -38,16 +41,27 @@ COBJS-y	+= cache.o
 ifndef CONFIG_SYS_NO_CP15_CACHE
 COBJS-y	+= cache-cp15.o
 endif
-COBJS-y	+= div0.o
 COBJS-y	+= interrupts.o
 COBJS-y	+= reset.o
 
-SRCS	:= $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+SRCS	:= $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
+	   $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
 OBJS	:= $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
+LGOBJS	:= $(addprefix $(obj),$(GLSOBJS)) \
+	   $(addprefix $(obj),$(GLCOBJS))
+
+ifdef USE_PRIVATE_LIBGCC
+all:	$(LIB) $(LIBGCC)
+else
+all:	$(LIB)
+endif
 
 $(LIB):	$(obj).depend $(OBJS)
 	$(AR) $(ARFLAGS) $@ $(OBJS)
 
+$(LIBGCC): $(obj).depend $(LGOBJS)
+	$(AR) $(ARFLAGS) $@ $(LGOBJS)
+
 #########################################################################
 
 # defines $(obj).depend target
-- 
1.6.0.6

[U-Boot] [PATCH] arm: add _lshrdi3.S

[Heiko Schocher]

Signed-off-by: Heiko Schocher <hs@denx.de>
---
 lib_arm/Makefile   |    1 +
 lib_arm/_lshrdi3.S |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 0 deletions(-)
 create mode 100644 lib_arm/_lshrdi3.S

diff --git a/lib_arm/Makefile b/lib_arm/Makefile
index 241782c..c37e2e0 100644
--- a/lib_arm/Makefile
+++ b/lib_arm/Makefile
@@ -29,6 +29,7 @@ LIBGCC	= $(obj)libgcc.a
 GLSOBJS	+= _ashldi3.o
 GLSOBJS	+= _ashrdi3.o
 GLSOBJS	+= _divsi3.o
+GLSOBJS	+= _lshrdi3.o
 GLSOBJS	+= _modsi3.o
 GLSOBJS	+= _udivsi3.o
 GLSOBJS	+= _umodsi3.o
diff --git a/lib_arm/_lshrdi3.S b/lib_arm/_lshrdi3.S
new file mode 100644
index 0000000..fabfd9f
--- /dev/null
+++ b/lib_arm/_lshrdi3.S
@@ -0,0 +1,46 @@
+/* Copyright 1995, 1996, 1998, 1999, 2000, 2003, 2004, 2005
+   Free Software Foundation, Inc.
+
+This file is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the
+Free Software Foundation; either version 2, or (at your option) any
+later version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file.  (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; see the file COPYING.  If not, write to
+the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+Boston, MA 02110-1301, USA.  */
+
+
+#ifdef __ARMEB__
+#define al r1
+#define ah r0
+#else
+#define al r0
+#define ah r1
+#endif
+
+.globl __lshrdi3
+__lshrdi3:
+
+	subs	r3, r2, #32
+	rsb	ip, r2, #32
+	movmi	al, al, lsr r2
+	movpl	al, ah, lsr r3
+	orrmi	al, al, ah, lsl ip
+	mov	ah, ah, lsr r2
+	mov	pc, lr
-- 
1.6.0.6

[U-Boot] [PATCH] arm: add _lshrdi3.S

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4A684908.8070402@invitel.hu> you wrote:
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
>  lib_arm/Makefile   |    1 +
>  lib_arm/_lshrdi3.S |   46 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 47 insertions(+), 0 deletions(-)
>  create mode 100644 lib_arm/_lshrdi3.S

Why should we add this? Where it is needed?

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
The nice thing about  standards  is that there are  so many to choose
from.                                           - Andrew S. Tanenbaum

[U-Boot] [PATCH] arm: add _lshrdi3.S

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> In message <4A684908.8070402@invitel.hu> you wrote:
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> ---
>>  lib_arm/Makefile   |    1 +
>>  lib_arm/_lshrdi3.S |   46 ++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 47 insertions(+), 0 deletions(-)
>>  create mode 100644 lib_arm/_lshrdi3.S
> 
> Why should we add this? Where it is needed?

This is needed for the upcoming suen3 support.
Maybe I sould have written this in the commit
message?

This board uses NAND, and if I compile it, I get this
errors:

[hs at pollux u-boot]$ make mrproper
[hs at pollux u-boot]$ make suen3_config
Configuring for suen3 board...
[hs at pollux u-boot]$ make USE_PRIVATE_LIBGCC=yes -s all
drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_write_oob':
/home/hs/keymile/suen3/u-boot/drivers/mtd/nand/nand_base.c:2019: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_erase_nand':
/home/hs/keymile/suen3/u-boot/drivers/mtd/nand/nand_base.c:2199: undefined reference to `__lshrdi3'
/home/hs/keymile/suen3/u-boot/drivers/mtd/nand/nand_base.c:2198: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_read_oob':
/home/hs/keymile/suen3/u-boot/drivers/mtd/nand/nand_base.c:1519: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_bbt.o): In function `search_bbt':
/home/hs/keymile/suen3/u-boot/drivers/mtd/nand/nand_bbt.c:482: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_bbt.o):/home/hs/keymile/suen3/u-boot/drivers/mtd/nand/nand_bbt.c:413: more undefined references to `__lshrdi3' follow
make: *** [u-boot] Fehler 1
[hs at pollux u-boot]$

above patch fixes this. And I thought better to post such
a fix immediately ...

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Daniel Gorsulowski]

Hi Wolfgang,

buid on meesc board (arm) is still broken.
It's roughly the same problem, as Heiko Schocher reported in
4A6854B1.5000205 at denx.de. But his patch doesn't fix the problem either.

danielg at debby:~/git/u-boot$ make USE_PRIVATE_LIBGCC=yes
...
drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_write_oob':
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2019: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_erase_nand':
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2199: undefined reference to `__lshrdi3'
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2198: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_read_oob':
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:1519: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_bbt.o): In function `search_bbt':
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_bbt.c:482: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_bbt.o):/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_bbt.c:413: more undefined references to `__lshrdi3' follow
lib_generic/libgeneric.a(vsprintf.o): In function `put_dec':
/data/home/danielg/git/u-boot/lib_generic/vsprintf.c:242: undefined reference to `__umoddi3'
/data/home/danielg/git/u-boot/lib_generic/vsprintf.c:242: undefined reference to `__udivdi3'
lib_generic/libgeneric.a(vsprintf.o): In function `number':
/data/home/danielg/git/u-boot/lib_generic/vsprintf.c:306: undefined reference to `__lshrdi3'
make: *** [u-boot] Error 1

Best regards, Daniel


Wolfgang Denk wrote:
> Many (especially ARM) tool chains seem to come with broken or
> otherwise unusable (for the purposes of builing U-Boot) run-time
> support libraries `libgcc.a'. By using the "USE_PRIVATE_LIBGCC"
> setting we allow to use alternative libraries instead.
> 
> "USE_PRIVATE_LIBGCC" can either be set as an environment variable in
> the shell, or as a command line argument when running "make", i. e.
> 	$ make USE_PRIVATE_LIBGCC=yes
> or
> 	$ USE_PRIVATE_LIBGCC=yes
> 	$ export USE_PRIVATE_LIBGCC
> 	$ make
> 
> The value of "USE_PRIVATE_LIBGCC" is the name of the directory which
> contains the alternative run-time support library `libgcc.a'. The
> special value "yes" selects the directory $(OBJTREE)/lib_$(ARCH) .
> 
> Note that not all architectures provide an alternative `libgcc.a' in
> their lib_$(ARCH) directories - so far, only ARM does.
> 
> Signed-off-by: Wolfgang Denk <wd@denx.de>
...

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Heiko Schocher]

Hello Daniel,

Daniel Gorsulowski wrote:
> buid on meesc board (arm) is still broken.
> It's roughly the same problem, as Heiko Schocher reported in
> 4A6854B1.5000205 at denx.de. But his patch doesn't fix the problem either.
> 
> danielg at debby:~/git/u-boot$ make USE_PRIVATE_LIBGCC=yes
> ...
> drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_write_oob':
> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2019: undefined reference to `__lshrdi3'
> drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_erase_nand':
> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2199: undefined reference to `__lshrdi3'
> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2198: undefined reference to `__lshrdi3'
> drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_read_oob':
> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:1519: undefined reference to `__lshrdi3'
> drivers/mtd/nand/libnand.a(nand_bbt.o): In function `search_bbt':
> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_bbt.c:482: undefined reference to `__lshrdi3'
> drivers/mtd/nand/libnand.a(nand_bbt.o):/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_bbt.c:413: more undefined references to `__lshrdi3' follow
> lib_generic/libgeneric.a(vsprintf.o): In function `put_dec':
> /data/home/danielg/git/u-boot/lib_generic/vsprintf.c:242: undefined reference to `__umoddi3'
> /data/home/danielg/git/u-boot/lib_generic/vsprintf.c:242: undefined reference to `__udivdi3'

Maybe you need also this fix from Dirk Behme

http://lists.denx.de/pipermail/u-boot/2009-July/057265.html

I see on this Hardware is CONFIG_SYS_64BIT_VSPRINTF activated ... so
I think, the above patch will fix this. Can you give this a try?

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Daniel Gorsulowski]

Hello Heiko,

Dirks patch reduces the errors, but I still get:

drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_write_oob':
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2019: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_erase_nand':
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2199: undefined reference to `__lshrdi3'
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2198: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_read_oob':
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:1519: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_bbt.o): In function `search_bbt':
/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_bbt.c:482: undefined reference to `__lshrdi3'
drivers/mtd/nand/libnand.a(nand_bbt.o):/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_bbt.c:413: more undefined references to `__lshrdi3' follow
make: *** [u-boot] Error 1

I noticed, that lib_arm/_lshrdi3.a is not beeing compiled.
So i added 'GLSOBJS += _lshrdi3.S' to lib_arm/Makefile (this line is missing
in your patch, i guess). But _lshrdi3.a still does not compile.

So I took a look at lib_arm/.depend:
_ashldi3.o: _ashldi3.S
_ashrdi3.o: _ashrdi3.S
_divsi3.o: _divsi3.S
_lshrdi3.o: _lshrdi3.S
_modsi3.o: _modsi3.S
_udivsi3.o: _udivsi3.S
_umodsi3.o: _umodsi3.S

I have no explanation for that, do you have?

bye, Daniel


Heiko Schocher wrote:
> Hello Daniel,
> 
> Daniel Gorsulowski wrote:
>> buid on meesc board (arm) is still broken.
>> It's roughly the same problem, as Heiko Schocher reported in
>> 4A6854B1.5000205 at denx.de. But his patch doesn't fix the problem either.
>>
>> danielg at debby:~/git/u-boot$ make USE_PRIVATE_LIBGCC=yes
>> ...
>> drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_write_oob':
>> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2019: undefined reference to `__lshrdi3'
>> drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_erase_nand':
>> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2199: undefined reference to `__lshrdi3'
>> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2198: undefined reference to `__lshrdi3'
>> drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_read_oob':
>> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:1519: undefined reference to `__lshrdi3'
>> drivers/mtd/nand/libnand.a(nand_bbt.o): In function `search_bbt':
>> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_bbt.c:482: undefined reference to `__lshrdi3'
>> drivers/mtd/nand/libnand.a(nand_bbt.o):/data/home/danielg/git/u-boot/drivers/mtd/nand/nand_bbt.c:413: more undefined references to `__lshrdi3' follow
>> lib_generic/libgeneric.a(vsprintf.o): In function `put_dec':
>> /data/home/danielg/git/u-boot/lib_generic/vsprintf.c:242: undefined reference to `__umoddi3'
>> /data/home/danielg/git/u-boot/lib_generic/vsprintf.c:242: undefined reference to `__udivdi3'
> 
> Maybe you need also this fix from Dirk Behme
> 
> http://lists.denx.de/pipermail/u-boot/2009-July/057265.html
> 
> I see on this Hardware is CONFIG_SYS_64BIT_VSPRINTF activated ... so
> I think, the above patch will fix this. Can you give this a try?
> 
> bye
> Heiko

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Daniel Gorsulowski]

Sorry, it was my misstake.

By c&p and applying yout patch I missed the changes in lib_arm/Makefile.
But as i wrote, _lshrdi3.a does not compile.

Daniel

Daniel Gorsulowski wrote:
> So i added 'GLSOBJS += _lshrdi3.S' to lib_arm/Makefile (this line is missing
> in your patch, i guess). But _lshrdi3.a still does not compile.

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Heiko Schocher]

Hello Daniel,

Daniel Gorsulowski wrote:
> Sorry, it was my misstake.
> 
> By c&p and applying yout patch I missed the changes in lib_arm/Makefile.
> But as i wrote, _lshrdi3.a does not compile.

Why do you use c&p, and not better tools?

Compiling the meesc board with actual u-boot and the patches
from Wolfgang, Dirk and me, works fine for me:

[hs at pollux u-boot]$ make mrproper
[hs at pollux u-boot]$ make meesc_config
Configuring for meesc board...
[hs at pollux u-boot]$ make USE_PRIVATE_LIBGCC=yes -s all
[hs at pollux u-boot]$
[hs at pollux u-boot]$ ls -al u-boot.bin
-rwxrwxr-x 1 hs hs 136820 23. Jul 17:25 u-boot.bin
[hs at pollux u-boot]$
[hs at pollux u-boot]$ git log
commit 21fd74874f0f7d95509c726162da213dcc6e7db1
Author: Heiko Schocher <hs@denx.de>
Date:   Thu Jul 23 13:18:40 2009 +0200

    arm: add _lshrdi3.S

    Signed-off-by: Heiko Schocher <hs@denx.de>

commit de463168e15733fd1f66f472399f7b93758f6a9e
Author: Wolfgang Denk <wd@denx.de>
Date:   Thu Jul 23 13:15:59 2009 +0200

    Make linking against libgcc configurable

    Many (especially ARM) tool chains seem to come with broken or
    otherwise unusable (for the purposes of builing U-Boot) run-time
    support libraries `libgcc.a'. By using the "USE_PRIVATE_LIBGCC"
    setting we allow to use alternative libraries instead.

    "USE_PRIVATE_LIBGCC" can either be set as an environment variable in
    the shell, or as a command line argument when running "make", i. e.
        $ make USE_PRIVATE_LIBGCC=yes
    or
        $ USE_PRIVATE_LIBGCC=yes
        $ export USE_PRIVATE_LIBGCC
        $ make

    The value of "USE_PRIVATE_LIBGCC" is the name of the directory which
    contains the alternative run-time support library `libgcc.a'. The
    special value "yes" selects the directory $(OBJTREE)/lib_$(ARCH) .

    Note that not all architectures provide an alternative `libgcc.a' in
    their lib_$(ARCH) directories - so far, only ARM does.

    Signed-off-by: Wolfgang Denk <wd@denx.de>
    Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
    Cc: Prafulla Wadaskar <prafulla@marvell.com>
    cc: Stefan Roese <sr@denx.de>

commit 6da36a407c7e0d48789f10338477a3a8f612301f
Author: Dirk Behme <dirk.behme@googlemail.com>
Date:   Wed Jul 22 17:51:56 2009 +0200

    Use do_div from div64.h for vsprintf

    Use do_div from div64.h for vsprintf in case of 64bit division.
    For 32bit division, do_div from div64.h can't be used as it
    needs a 64bit parameter.

    Signed-off-by: Dirk Behme <dirk.behme@googlemail.com>
    CC: Simon Kagstrom <simon.kagstrom@netinsight.net>

commit 189eec77795553157c087cd45555695fb3ce2433
Merge: faca03c... 84efbf4...
Author: Wolfgang Denk <wd@denx.de>
Date:   Thu Jul 23 01:00:17 2009 +0200

    Merge branch 'master' of /home/wd/git/u-boot/custodians

commit 84efbf4d144ff8aaed3cca036aebb1fe69eff3f4
Merge: 49a7720... 57215cd...
Author: Wolfgang Denk <wd@denx.de>
Date:   Thu Jul 23 00:59:37 2009 +0200

    Merge branch 'master' of git://git.denx.de/u-boot-arm

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Wolfgang Denk]

Dear Daniel Gorsulowski,

In message <4A686566.409@esd.eu> you wrote:
> 
> buid on meesc board (arm) is still broken.
> It's roughly the same problem, as Heiko Schocher reported in
> 4A6854B1.5000205 at denx.de. But his patch doesn't fix the problem either.
> 
> danielg at debby:~/git/u-boot$ make USE_PRIVATE_LIBGCC=yes
> ...
> drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_do_write_oob':
> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2019: undefined reference to `__lshrdi3'
> drivers/mtd/nand/libnand.a(nand_base.o): In function `nand_erase_nand':
> /data/home/danielg/git/u-boot/drivers/mtd/nand/nand_base.c:2199: undefined reference to `__lshrdi3'

Well, my patch makes the use of libgcc configurable - it does not
attempt to fix any remaining problems in the private ARM
implementation of this library - I think Jean-Christophe has a full
port of the related Linux code ready available, and I think he should
rebase and post this.

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
When a man sits with a pretty girl for  an  hour,  it  seems  like  a
minute.  But let him sit on a hot stove for a minute -- and it's lon-
ger than any hour. That's relativity.              -- Albert Einstein

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Daniel Gorsulowski]

Heiko Schocher wrote:
> Hello Daniel,
> 
Hello Heiko,

First, I would like to apologize for top posting in my last 3 mails.
I am anxious to avoid that in the feature.

> Daniel Gorsulowski wrote:
>> Sorry, it was my misstake.
>>
>> By c&p and applying yout patch I missed the changes in lib_arm/Makefile.
>> But as i wrote, _lshrdi3.a does not compile.
> 
> Why do you use c&p, and not better tools?
>
Thank you, now I learned using git-am as well by patches, created with
git-format-patch, as by emails from my mailbox.

> Compiling the meesc board with actual u-boot and the patches
> from Wolfgang, Dirk and me, works fine for me:
> 
> [hs at pollux u-boot]$ make mrproper
> [hs at pollux u-boot]$ make meesc_config
> Configuring for meesc board...
> [hs at pollux u-boot]$ make USE_PRIVATE_LIBGCC=yes -s all
> [hs at pollux u-boot]$
> [hs at pollux u-boot]$ ls -al u-boot.bin
> -rwxrwxr-x 1 hs hs 136820 23. Jul 17:25 u-boot.bin
...
> 
After re-applying the patches by git-am, everything workes fine for me too.
Sorry for confusing...

> bye
> Heiko

Bye, Daniel

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Wolfgang Denk]

In message <1248347759-28119-1-git-send-email-wd@denx.de> you wrote:
> Many (especially ARM) tool chains seem to come with broken or
> otherwise unusable (for the purposes of builing U-Boot) run-time
> support libraries `libgcc.a'. By using the "USE_PRIVATE_LIBGCC"
> setting we allow to use alternative libraries instead.
> 
> "USE_PRIVATE_LIBGCC" can either be set as an environment variable in
> the shell, or as a command line argument when running "make", i. e.
> 	$ make USE_PRIVATE_LIBGCC=yes
> or
> 	$ USE_PRIVATE_LIBGCC=yes
> 	$ export USE_PRIVATE_LIBGCC
> 	$ make
> 
> The value of "USE_PRIVATE_LIBGCC" is the name of the directory which
> contains the alternative run-time support library `libgcc.a'. The
> special value "yes" selects the directory $(OBJTREE)/lib_$(ARCH) .
> 
> Note that not all architectures provide an alternative `libgcc.a' in
> their lib_$(ARCH) directories - so far, only ARM does.
> 
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Prafulla Wadaskar <prafulla@marvell.com>
> cc: Stefan Roese <sr@denx.de>
> ---
> v2: Removed crap left over from testing.
> 
>  Makefile            |   12 +++++++++++-
>  board/trab/Makefile |    4 +---
>  lib_arm/Makefile    |   30 ++++++++++++++++++++++--------
>  3 files changed, 34 insertions(+), 12 deletions(-)

Applied.

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
Men don't talk peace unless they're ready to back it up with war.
	-- Col. Green, "The Savage Curtain", stardate 5906.4

[U-Boot] [PATCH] arm: add _lshrdi3.S

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4A684908.8070402@invitel.hu> you wrote:
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
>  lib_arm/Makefile   |    1 +
>  lib_arm/_lshrdi3.S |   46 ++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 47 insertions(+), 0 deletions(-)
>  create mode 100644 lib_arm/_lshrdi3.S

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
You humans have that emotional need  to  express  gratitude.  "You're
welcome," I believe, is the correct response.
	-- Spock, "Bread and Circuses", stardate 4041.2

[U-Boot] [PATCH v2] Make linking against libgcc configurable

[Heiko Schocher]

Hello Daniel,

Daniel Gorsulowski wrote:
> Heiko Schocher wrote:
>> Daniel Gorsulowski wrote:
>>> Sorry, it was my misstake.
>>>
>>> By c&p and applying yout patch I missed the changes in lib_arm/Makefile.
>>> But as i wrote, _lshrdi3.a does not compile.
>> Why do you use c&p, and not better tools?
>>
> Thank you, now I learned using git-am as well by patches, created with
> git-format-patch, as by emails from my mailbox.

Fine.

>> Compiling the meesc board with actual u-boot and the patches
>> from Wolfgang, Dirk and me, works fine for me:
>>
>> [hs at pollux u-boot]$ make mrproper
>> [hs at pollux u-boot]$ make meesc_config
>> Configuring for meesc board...
>> [hs at pollux u-boot]$ make USE_PRIVATE_LIBGCC=yes -s all
>> [hs at pollux u-boot]$
>> [hs at pollux u-boot]$ ls -al u-boot.bin
>> -rwxrwxr-x 1 hs hs 136820 23. Jul 17:25 u-boot.bin
> ...
> After re-applying the patches by git-am, everything workes fine for me too.

Great. One more test, thanks. :-)

> Sorry for confusing...

No problem.

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany