[U-Boot] [PATCH v3] libgcc inclusion from common Makefile overwritable from platform configs files
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)%
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
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.
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)%
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
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.
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)%
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
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
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
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@denx.de When some people discover the truth, they just can't understand why everybody isn't eager to hear it.
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
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
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.
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
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)%
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
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@denx.de =====================================================================
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=07a6acbe20357ebc2af36... http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=40cebd2af1379f2cd815e...
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
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
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.
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
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.
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
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
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).
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.
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. 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.
Best regards,
Wolfgang Denk
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
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
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.
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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 ;)
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
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
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
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
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@denx.de =====================================================================
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
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
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
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
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
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
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
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@pollux u-boot]$ make mrproper [hs@pollux u-boot]$ make suen3_config Configuring for suen3 board... [hs@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@pollux u-boot]$
above patch fixes this. And I thought better to post such a fix immediately ...
bye Heiko
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
Hi Wolfgang,
buid on meesc board (arm) is still broken. It's roughly the same problem, as Heiko Schocher reported in 4A6854B1.5000205@denx.de. But his patch doesn't fix the problem either.
danielg@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
...
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@denx.de. But his patch doesn't fix the problem either.
danielg@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
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@denx.de. But his patch doesn't fix the problem either.
danielg@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
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.
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@pollux u-boot]$ make mrproper [hs@pollux u-boot]$ make meesc_config Configuring for meesc board... [hs@pollux u-boot]$ make USE_PRIVATE_LIBGCC=yes -s all [hs@pollux u-boot]$ [hs@pollux u-boot]$ ls -al u-boot.bin -rwxrwxr-x 1 hs hs 136820 23. Jul 17:25 u-boot.bin [hs@pollux u-boot]$ [hs@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
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@pollux u-boot]$ make mrproper [hs@pollux u-boot]$ make meesc_config Configuring for meesc board... [hs@pollux u-boot]$ make USE_PRIVATE_LIBGCC=yes -s all [hs@pollux u-boot]$ [hs@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
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@pollux u-boot]$ make mrproper [hs@pollux u-boot]$ make meesc_config Configuring for meesc board... [hs@pollux u-boot]$ make USE_PRIVATE_LIBGCC=yes -s all [hs@pollux u-boot]$ [hs@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
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@denx.de. But his patch doesn't fix the problem either.
danielg@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
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
participants (10)
-
Daniel Gorsulowski -
Detlev Zundel -
Dirk Behme -
Heiko Schocher -
Heiko Schocher -
Jean-Christophe PLAGNIOL-VILLARD -
Mike Frysinger -
Scott Wood -
Stefan Roese -
Wolfgang Denk