[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier:
- Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead.
- So far, we only checked if "-mapcs-32" was supported by the tool chain; if yes, this was used, if not, "-mabi=apcs-gnu" was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic:
1) If the tool chain supports "-mabi=aapcs-linux -mno-thumb-interwork" we use these options (EABI conformant tool chain). 2) Otherwise, we check first if "-mapcs-32" is supported, and then check for "-mabi=apcs-gnu" If one test succeeds, we use the first found option. 3) In case 2), we also test if "-mno-thumb-interwork", and use this if the test succeeds. [For "-mabi=aapcs-linux" we set "-mno-thumb-interwork" mandatorily.]
This way we use a similar logic for the compile options as the Linux kenrel does.
- Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c
Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list.
Signed-off-by: Wolfgang Denk wd@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com Cc: Dirk Behme dirk.behme@googlemail.com Cc: Magnus Lilja lilja.magnus@gmail.com Cc: Tom Rix Tom.Rix@windriver.com Cc: Prafulla Wadaskar prafulla@marvell.com ---
I have run a full "MAKEALL arm" for ELDK releases 3.1 (gcc 3.3.3), 3.1.1 (gcc 3.3.3), 4.1 (gcc 4.0.0) and 4.2 (gcc 4.2.2, both as "arm" [softfloat] and "armVFP" [VFP hardfloat]), and all of these both with USE_PRIVATE_LIBGCC=yes (i. e. using U-Boot internal libgcc replacement code) and without (i. e. using the tool chain provided standard libgcc instead).
The ELDK fails to build the big-endian IXP boards, but this is a restriction of the ELDK, not a new issue introcued by this patch. Except of this, all build were succesful.
Note 1: Please note that older tool chains (based on binutils versions older than 2.16) will have problems with the SORT_BY_ALIGNMENT() and SORT_BY_NAME() functions introduced to the linker scripts with commit f62fb99941c6. I'll soon submit a patch to fix this issue. Final tests are running right now.
Note 2: Even though this is a bigger change, I consider it a bug fix and therefor tend to have it included into the upcoming release. Of course this requires sufficient test coverage and feedback. Please help!!
Note 3: Most ARM systems also define this: PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) I guess this can be unified and moved to lib_arm/config.mk, too, but I would like to handle this in a separate, later patch. This makes testing (and bisecting) easier, and it is a non-critical problem.
config.mk | 2 +- cpu/arm1136/config.mk | 2 -- cpu/arm1176/config.mk | 2 -- cpu/arm1176/s3c64xx/config.mk | 1 - cpu/arm720t/config.mk | 2 -- cpu/arm920t/config.mk | 2 -- cpu/arm925t/config.mk | 2 -- cpu/arm926ejs/config.mk | 2 -- cpu/arm926ejs/davinci/config.mk | 2 -- cpu/arm946es/config.mk | 2 -- cpu/arm_cortexa8/config.mk | 1 - cpu/arm_cortexa8/omap3/board.c | 7 ------- cpu/arm_intcm/config.mk | 2 -- cpu/ixp/config.mk | 1 - cpu/lh7a40x/config.mk | 2 -- cpu/pxa/config.mk | 2 -- cpu/s3c44b0/config.mk | 2 -- cpu/sa1100/config.mk | 2 -- lib_arm/Makefile | 15 ++++++++++++--- lib_arm/config.mk | 28 ++++++++++++++++++++++++++++ lib_arm/eabi_compat.c | 18 ++++++++++++++++++ 21 files changed, 59 insertions(+), 40 deletions(-) create mode 100644 lib_arm/eabi_compat.c
diff --git a/config.mk b/config.mk index fd56621..0c6d1d1 100644 --- a/config.mk +++ b/config.mk @@ -86,7 +86,7 @@ ifdef ARCH sinclude $(TOPDIR)/lib_$(ARCH)/config.mk # include architecture dependend rules endif ifdef CPU -sinclude $(TOPDIR)/cpu/$(CPU)/config.mk # include CPU specific rules +sinclude $(TOPDIR)/cpu/$(CPU)/config.mk # include CPU specific rules endif ifdef SOC sinclude $(TOPDIR)/cpu/$(CPU)/$(SOC)/config.mk # include SoC specific rules diff --git a/cpu/arm1136/config.mk b/cpu/arm1136/config.mk index 295e8a5..61d5a38 100644 --- a/cpu/arm1136/config.mk +++ b/cpu/arm1136/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv5 # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm1176/config.mk b/cpu/arm1176/config.mk index d2f057b..a31c7b0 100644 --- a/cpu/arm1176/config.mk +++ b/cpu/arm1176/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv5t # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm1176/s3c64xx/config.mk b/cpu/arm1176/s3c64xx/config.mk index 4f3b66c..a31c7b0 100644 --- a/cpu/arm1176/s3c64xx/config.mk +++ b/cpu/arm1176/s3c64xx/config.mk @@ -30,5 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv5t # Supply options according to compiler version # # ========================================================================= -#PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm720t/config.mk b/cpu/arm720t/config.mk index 3cae1dc..74d5283 100644 --- a/cpu/arm720t/config.mk +++ b/cpu/arm720t/config.mk @@ -31,6 +31,4 @@ PLATFORM_CPPFLAGS += -march=armv4 -mtune=arm7tdmi # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm920t/config.mk b/cpu/arm920t/config.mk index 5d8a10f..a43b156 100644 --- a/cpu/arm920t/config.mk +++ b/cpu/arm920t/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv4 # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm925t/config.mk b/cpu/arm925t/config.mk index 5d8a10f..a43b156 100644 --- a/cpu/arm925t/config.mk +++ b/cpu/arm925t/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv4 # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk index 885d5c1..90eb3c0 100644 --- a/cpu/arm926ejs/config.mk +++ b/cpu/arm926ejs/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv5te # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm926ejs/davinci/config.mk b/cpu/arm926ejs/davinci/config.mk index a57d03a..7757be3 100644 --- a/cpu/arm926ejs/davinci/config.mk +++ b/cpu/arm926ejs/davinci/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv5te # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm946es/config.mk b/cpu/arm946es/config.mk index 9d62ba8..a81321b 100644 --- a/cpu/arm946es/config.mk +++ b/cpu/arm946es/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv4 # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/arm_cortexa8/config.mk b/cpu/arm_cortexa8/config.mk index 3bfe3db..da5ee16 100644 --- a/cpu/arm_cortexa8/config.mk +++ b/cpu/arm_cortexa8/config.mk @@ -30,6 +30,5 @@ PLATFORM_CPPFLAGS += -march=armv5 # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,\ $(call cc-option,-malignment-traps,)) diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c index 2337287..b8bd052 100644 --- a/cpu/arm_cortexa8/omap3/board.c +++ b/cpu/arm_cortexa8/omap3/board.c @@ -300,13 +300,6 @@ int dram_init(void) /****************************************************************************** * Dummy function to handle errors for EABI incompatibility *****************************************************************************/ -void raise(void) -{ -} - -/****************************************************************************** - * Dummy function to handle errors for EABI incompatibility - *****************************************************************************/ void abort(void) { } diff --git a/cpu/arm_intcm/config.mk b/cpu/arm_intcm/config.mk index 9d62ba8..a81321b 100644 --- a/cpu/arm_intcm/config.mk +++ b/cpu/arm_intcm/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv4 # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/ixp/config.mk b/cpu/ixp/config.mk index a71a20b..2c33b40 100644 --- a/cpu/ixp/config.mk +++ b/cpu/ixp/config.mk @@ -33,5 +33,4 @@ PLATFORM_CPPFLAGS += -mbig-endian -march=armv5te -mtune=strongarm1100 # Supply options according to compiler version # # ========================================================================= -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/lh7a40x/config.mk b/cpu/lh7a40x/config.mk index c0e7a1d..27bc481 100644 --- a/cpu/lh7a40x/config.mk +++ b/cpu/lh7a40x/config.mk @@ -30,6 +30,4 @@ PLATFORM_CPPFLAGS += -march=armv4 # Supply options according to compiler version # # ======================================================================== -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/pxa/config.mk b/cpu/pxa/config.mk index af910e2..f360478 100644 --- a/cpu/pxa/config.mk +++ b/cpu/pxa/config.mk @@ -31,6 +31,4 @@ PLATFORM_CPPFLAGS += -march=armv5te -mtune=xscale # Supply options according to compiler version # # ======================================================================== -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/s3c44b0/config.mk b/cpu/s3c44b0/config.mk index 01e7040..3623f25 100644 --- a/cpu/s3c44b0/config.mk +++ b/cpu/s3c44b0/config.mk @@ -31,6 +31,4 @@ PLATFORM_CPPFLAGS += -march=armv4 -mtune=arm7tdmi -msoft-float # Supply options according to compiler version # # ======================================================================== -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/cpu/sa1100/config.mk b/cpu/sa1100/config.mk index 9ef4a19..553cd0c 100644 --- a/cpu/sa1100/config.mk +++ b/cpu/sa1100/config.mk @@ -31,6 +31,4 @@ PLATFORM_CPPFLAGS += -march=armv4 -mtune=strongarm1100 # Supply options according to compiler version # # ======================================================================== -PLATFORM_CPPFLAGS +=$(call cc-option,-mapcs-32,-mabi=apcs-gnu) -PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) diff --git a/lib_arm/Makefile b/lib_arm/Makefile index c37e2e0..0293348 100644 --- a/lib_arm/Makefile +++ b/lib_arm/Makefile @@ -51,12 +51,21 @@ OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) LGOBJS := $(addprefix $(obj),$(GLSOBJS)) \ $(addprefix $(obj),$(GLCOBJS))
+# Always build libarm.a +TARGETS := $(LIB) + +# Build private libgcc only when asked for ifdef USE_PRIVATE_LIBGCC -all: $(LIB) $(LIBGCC) -else -all: $(LIB) +TARGETS += $(LIBGCC) +endif + +# For EABI conformant tool chains, provide eabi_compat() +ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS))) +TARGETS += $(obj)eabi_compat.o endif
+all: $(TARGETS) + $(LIB): $(obj).depend $(OBJS) $(AR) $(ARFLAGS) $@ $(OBJS)
diff --git a/lib_arm/config.mk b/lib_arm/config.mk index a13603e..705dfc3 100644 --- a/lib_arm/config.mk +++ b/lib_arm/config.mk @@ -25,4 +25,32 @@ CROSS_COMPILE ?= arm-linux-
PLATFORM_CPPFLAGS += -DCONFIG_ARM -D__ARM__
+# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: +PLATFORM_CPPFLAGS += $(call cc-option,-marm,) + +# Try if EABI is supported, else fall back to old API, +# i. e. for example: +# - with ELDK 4.2 (EABI supported), use: +# -mabi=aapcs-linux -mno-thumb-interwork +# - with ELDK 4.1 (gcc 4.x, no EABI), use: +# -mabi=apcs-gnu -mno-thumb-interwork +# - with ELDK 3.1 (gcc 3.x), use: +# -mapcs-32 -mno-thumb-interwork +PLATFORM_CPPFLAGS += $(call cc-option,\ + -mabi=aapcs-linux -mno-thumb-interwork,\ + $(call cc-option,\ + -mapcs-32,\ + $(call cc-option,\ + -mabi=apcs-gnu,\ + )\ + ) $(call cc-option,-mno-thumb-interwork,)\ + ) + +# For EABI, make sure to provide raise() +ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS))) +# This file is parsed several times; make sure to add only once. +ifeq (,$(findstring lib_arm/eabi_compat.o,$(PLATFORM_LIBS))) +PLATFORM_LIBS += $(OBJTREE)/lib_arm/eabi_compat.o +endif +endif LDSCRIPT := $(SRCTREE)/cpu/$(CPU)/u-boot.lds diff --git a/lib_arm/eabi_compat.c b/lib_arm/eabi_compat.c new file mode 100644 index 0000000..86eacf1 --- /dev/null +++ b/lib_arm/eabi_compat.c @@ -0,0 +1,18 @@ +/* + * Utility functions needed for (some) EABI conformant tool chains. + * + * (C) Copyright 2009 Wolfgang Denk wd@denx.de + * + * This program 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 of the + * License, or (at your option) any later version. + */ + +#include <common.h> + +int raise (int signum) +{ + printf("raise: Signal # %d caught\n", signum); + return 0; +}
Wolfgang Denk wrote:
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier:
I am testing this on the toolchain I usually use. The Code Sourcery arm-2008q3 http://www.codesourcery.com/sgpp/lite/arm
I see they have a 2009 version. I will download that and test that as well.
Be aware that MAKEALL arm takes a couple of hours.
Tom
Dear Tom,
In message 4A895462.1020205@windriver.com you wrote:
I am testing this on the toolchain I usually use. The Code Sourcery arm-2008q3 http://www.codesourcery.com/sgpp/lite/arm
I see they have a 2009 version. I will download that and test that as well.
Thanks.
Be aware that MAKEALL arm takes a couple of hours.
Seems you need a faster machine...
Best regards,
Wolfgang Denk
Tom wrote:
I am testing this on the toolchain I usually use. The Code Sourcery arm-2008q3 http://www.codesourcery.com/sgpp/lite/arm
I see they have a 2009 version. I will download that and test that as well.
Yes, using recent 2009q1-203 is the recommended one.
2008q3 is known to have some (minor?) issues:
http://elinux.org/ARMCompilers#Limitations
Best regards
Dirk
On Mon, 17 Aug 2009, Wolfgang Denk wrote:
Ack-by: Sergey Kubushyn ksi@koi8.net ---
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier:
Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead.
So far, we only checked if "-mapcs-32" was supported by the tool chain; if yes, this was used, if not, "-mabi=apcs-gnu" was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic:
- If the tool chain supports
"-mabi=aapcs-linux -mno-thumb-interwork" we use these options (EABI conformant tool chain). 2) Otherwise, we check first if "-mapcs-32" is supported, and then check for "-mabi=apcs-gnu" If one test succeeds, we use the first found option. 3) In case 2), we also test if "-mno-thumb-interwork", and use this if the test succeeds. [For "-mabi=aapcs-linux" we set "-mno-thumb-interwork" mandatorily.]
This way we use a similar logic for the compile options as the Linux kenrel does.
Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c
Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list.
Signed-off-by: Wolfgang Denk wd@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com Cc: Dirk Behme dirk.behme@googlemail.com Cc: Magnus Lilja lilja.magnus@gmail.com Cc: Tom Rix Tom.Rix@windriver.com Cc: Prafulla Wadaskar prafulla@marvell.com
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
Hi Wolfgang,
2009/8/17 Wolfgang Denk wd@denx.de:
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier:
- Even though all ARM systems basicy used the same compiler options
to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead.
- So far, we only checked if "-mapcs-32" was supported by the tool
chain; if yes, this was used, if not, "-mabi=apcs-gnu" was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic:
1) If the tool chain supports "-mabi=aapcs-linux -mno-thumb-interwork" we use these options (EABI conformant tool chain). 2) Otherwise, we check first if "-mapcs-32" is supported, and then check for "-mabi=apcs-gnu" If one test succeeds, we use the first found option. 3) In case 2), we also test if "-mno-thumb-interwork", and use this if the test succeeds. [For "-mabi=aapcs-linux" we set "-mno-thumb-interwork" mandatorily.]
This way we use a similar logic for the compile options as the Linux kenrel does.
"kenrel" => "kernel" :-)
- Some EABI conformant tool chains cause external references to
utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c
Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list.
Signed-off-by: Wolfgang Denk wd@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com Cc: Dirk Behme dirk.behme@googlemail.com Cc: Magnus Lilja lilja.magnus@gmail.com Cc: Tom Rix Tom.Rix@windriver.com Cc: Prafulla Wadaskar prafulla@marvell.com
I have run a full "MAKEALL arm" for ELDK releases 3.1 (gcc 3.3.3), 3.1.1 (gcc 3.3.3), 4.1 (gcc 4.0.0) and 4.2 (gcc 4.2.2, both as "arm" [softfloat] and "armVFP" [VFP hardfloat]), and all of these both with USE_PRIVATE_LIBGCC=yes (i. e. using U-Boot internal libgcc replacement code) and without (i. e. using the tool chain provided standard libgcc instead).
The ELDK fails to build the big-endian IXP boards, but this is a restriction of the ELDK, not a new issue introcued by this patch. Except of this, all build were succesful.
Note 1: Please note that older tool chains (based on binutils versions older than 2.16) will have problems with the SORT_BY_ALIGNMENT() and SORT_BY_NAME() functions introduced to the linker scripts with commit f62fb99941c6. I'll soon submit a patch to fix this issue. Final tests are running right now.
Note 2: Even though this is a bigger change, I consider it a bug fix and therefor tend to have it included into the upcoming release. Of course this requires sufficient test coverage and feedback. Please help!!
I've done compile time testing for the ARM11 boards using a gcc 4.1.2 toolchain that I often use and also Codesourcery's 2009-q1 (gcc 4.3.3) (both with and without USE_PRIVATE_LIBGCC=yes), everything compiles fine.
I hope to be able to do some run-time testing of some i.MX31 U-boot binaries later this week, so far I haven't tried them at all.
Regards, Magnus
Dear Magnus Lilja,
In message 59b21cf20908171317s10d7fdb5t631c37f06707e1c3@mail.gmail.com you wrote:
This way we use a similar logic for the compile options as the Linux kenrel does.
"kenrel" => "kernel" :-)
Thanks, will try to remember to edit the commit message.
I've done compile time testing for the ARM11 boards using a gcc 4.1.2 toolchain that I often use and also Codesourcery's 2009-q1 (gcc 4.3.3) (both with and without USE_PRIVATE_LIBGCC=yes), everything compiles fine.
I hope to be able to do some run-time testing of some i.MX31 U-boot binaries later this week, so far I haven't tried them at all.
Excellent., Thanks a lot. Can you please send an ACK or Tested-by, then?
Best regards,
Wolfgang Denk
Wolfgang,
2009/8/17 Wolfgang Denk wd@denx.de:
Dear Magnus Lilja,
In message 59b21cf20908171317s10d7fdb5t631c37f06707e1c3@mail.gmail.com you wrote:
This way we use a similar logic for the compile options as the Linux kenrel does.
"kenrel" => "kernel" :-)
Thanks, will try to remember to edit the commit message.
I've done compile time testing for the ARM11 boards using a gcc 4.1.2 toolchain that I often use and also Codesourcery's 2009-q1 (gcc 4.3.3) (both with and without USE_PRIVATE_LIBGCC=yes), everything compiles fine.
I hope to be able to do some run-time testing of some i.MX31 U-boot binaries later this week, so far I haven't tried them at all.
Excellent., Thanks a lot. Can you please send an ACK or Tested-by, then?
Tested-by: Magnus Lilja lilja.magnus@gmail.com
Run-time tested on i.MX31 PDK board using the above toolchains.
Regards, Magnus
Dear Magnus Lilja,
In message 59b21cf20908181008t75a981d8g512c10687c0b884a@mail.gmail.com you wrote:
Tested-by: Magnus Lilja lilja.magnus@gmail.com
Run-time tested on i.MX31 PDK board using the above toolchains.
Thanks a lot!
Best regards,
Wolfgang Denk
Dear Wolfgang Denk, I tested your patch against 7dedefdf749ff02c1086f7ddb8cb83a77b00d030 (latest revision at the moment of writing of u-boot.git). My toolchain is a home-made toolchain and contains gcc-4.4.1, binutils-2.19.1, eglibc-2.10.1, kernel headers 2.6.30.4, configured to generate binaries for arm little endian, eabi, and multilib disable.
Results: I was unable to compile without the patch in this thread http://lists.denx.de/pipermail/u-boot/2009-August/058193.html (which is normal because of gcc-4.4.1). With 'MAKEALL arm' I have no compile errors except for: * actux1, actux2, actux3, actux4, ixdp425, ixdpg425, pdnb3, which seem to be big endian (my toolchain only generates binaries for little endian). * and "trab board" with this error: armel-unknown-linux-gnueabi-ld: ../../lib_arm/div0.o: No such file: No such file or directory
Regards
Dear Gaye Abdoulaye Walsimou,
In message 4A8A8B27.7080403@walsimou.com you wrote:
I tested your patch against 7dedefdf749ff02c1086f7ddb8cb83a77b00d030
Thanks for testing!
Results: I was unable to compile without the patch in this thread http://lists.denx.de/pipermail/u-boot/2009-August/058193.html (which is normal because of gcc-4.4.1).
Yes, this is to be expected.
With 'MAKEALL arm' I have no compile errors except for:
- actux1, actux2, actux3, actux4, ixdp425, ixdpg425, pdnb3, which seem
to be big endian (my toolchain only generates binaries for little endian).
correct, to be expected, too.
- and "trab board" with this error: armel-unknown-linux-gnueabi-ld:
../../lib_arm/div0.o: No such file: No such file or directory
I posted a patch to fix this issue. This is a problem in the trab board code.
Would you please be so kind and post a formal "Tested-by:" or "Acked-by": message? Thanks in advance.
Best regards,
Wolfgang Denk
Results: I was unable to compile without the patch in this thread http://lists.denx.de/pipermail/u-boot/2009-August/058193.html (which is normal because of gcc-4.4.1). With 'MAKEALL arm' I have no compile errors except for:
- actux1, actux2, actux3, actux4, ixdp425, ixdpg425, pdnb3, which seem
to be big endian (my toolchain only generates binaries for little endian).
- and "trab board" with this error: armel-unknown-linux-gnueabi-ld:
../../lib_arm/div0.o: No such file: No such file or directory
I've tested it with gcc 4.1.2 and 4.3.3 from Buildroot, with the same results. Tests only without USE_PRIVATE_LIBGCC=yes.
Tested-by: Andrzej Wolski awolski@poczta.fm
Regards
---------------------------------------------------------------------- Wygraj telefon dla swojego dziecka. 20 sztuk czeka! Sprawdz >> http://link.interia.pl/f22d8
Wolfgang Denk wrote:
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier:
Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead.
So far, we only checked if "-mapcs-32" was supported by the tool chain; if yes, this was used, if not, "-mabi=apcs-gnu" was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic:
- If the tool chain supports
"-mabi=aapcs-linux -mno-thumb-interwork" we use these options (EABI conformant tool chain). 2) Otherwise, we check first if "-mapcs-32" is supported, and then check for "-mabi=apcs-gnu" If one test succeeds, we use the first found option. 3) In case 2), we also test if "-mno-thumb-interwork", and use this if the test succeeds. [For "-mabi=aapcs-linux" we set "-mno-thumb-interwork" mandatorily.]
This way we use a similar logic for the compile options as the Linux kenrel does.
Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c
Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list.
Signed-off-by: Wolfgang Denk wd@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com Cc: Dirk Behme dirk.behme@googlemail.com Cc: Magnus Lilja lilja.magnus@gmail.com Cc: Tom Rix Tom.Rix@windriver.com Cc: Prafulla Wadaskar prafulla@marvell.com
I have run a full "MAKEALL arm" for ELDK releases 3.1 (gcc 3.3.3), 3.1.1 (gcc 3.3.3), 4.1 (gcc 4.0.0) and 4.2 (gcc 4.2.2, both as "arm" [softfloat] and "armVFP" [VFP hardfloat]), and all of these both with USE_PRIVATE_LIBGCC=yes (i. e. using U-Boot internal libgcc replacement code) and without (i. e. using the tool chain provided standard libgcc instead).
The ELDK fails to build the big-endian IXP boards, but this is a restriction of the ELDK, not a new issue introcued by this patch. Except of this, all build were succesful.
Note 1: Please note that older tool chains (based on binutils versions older than 2.16) will have problems with the SORT_BY_ALIGNMENT() and SORT_BY_NAME() functions introduced to the linker scripts with commit f62fb99941c6. I'll soon submit a patch to fix this issue. Final tests are running right now.
Note 2: Even though this is a bigger change, I consider it a bug fix and therefor tend to have it included into the upcoming release. Of course this requires sufficient test coverage and feedback. Please help!!
Note 3: Most ARM systems also define this: PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) I guess this can be unified and moved to lib_arm/config.mk, too, but I would like to handle this in a separate, later patch. This makes testing (and bisecting) easier, and it is a non-critical problem.
Tested-by: Gaye Abdoulaye Walsimou walsimou@walsimou.com
Wolfgang Denk wrote:
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier:
Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead.
So far, we only checked if "-mapcs-32" was supported by the tool chain; if yes, this was used, if not, "-mabi=apcs-gnu" was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic:
- If the tool chain supports
"-mabi=aapcs-linux -mno-thumb-interwork" we use these options (EABI conformant tool chain). 2) Otherwise, we check first if "-mapcs-32" is supported, and then check for "-mabi=apcs-gnu" If one test succeeds, we use the first found option. 3) In case 2), we also test if "-mno-thumb-interwork", and use this if the test succeeds. [For "-mabi=aapcs-linux" we set "-mno-thumb-interwork" mandatorily.]
This way we use a similar logic for the compile options as the Linux kenrel does.
Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c
Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list.
Signed-off-by: Wolfgang Denk wd@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com Cc: Dirk Behme dirk.behme@googlemail.com Cc: Magnus Lilja lilja.magnus@gmail.com Cc: Tom Rix Tom.Rix@windriver.com Cc: Prafulla Wadaskar prafulla@marvell.com
MAKEALL arm with CodeSourcery's arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu
and this patch differ from
USE_PRIVATE_LIBGCC=yes ./MAKEALL arm
only in these targets
actux1 actux2 actux3 actux4 ixdp425 ixdpg425 pdnb3 scpu trab
As already mentioned already by
http://lists.denx.de/pipermail/u-boot/2009-August/058838.html
Tested-by : Tom Rix Tom.Rix@windriver.com
Dear Tom,
In message 4A8AF7D9.7070201@windriver.com you wrote:
MAKEALL arm with CodeSourcery's arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu
and this patch differ from
USE_PRIVATE_LIBGCC=yes ./MAKEALL arm
only in these targets
actux1 actux2 actux3 actux4 ixdp425 ixdpg425 pdnb3 scpu trab
As already mentioned already by
http://lists.denx.de/pipermail/u-boot/2009-August/058838.html
Tested-by : Tom Rix Tom.Rix@windriver.com
Thanks a lot, Tom.
Best regards,
Wolfgang Denk
In message 1250507849-31660-1-git-send-email-wd@denx.de I wrote:
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier:
Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead.
So far, we only checked if "-mapcs-32" was supported by the tool chain; if yes, this was used, if not, "-mabi=apcs-gnu" was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic:
- If the tool chain supports
"-mabi=aapcs-linux -mno-thumb-interwork" we use these options (EABI conformant tool chain). 2) Otherwise, we check first if "-mapcs-32" is supported, and then check for "-mabi=apcs-gnu" If one test succeeds, we use the first found option. 3) In case 2), we also test if "-mno-thumb-interwork", and use this if the test succeeds. [For "-mabi=aapcs-linux" we set "-mno-thumb-interwork" mandatorily.]
This way we use a similar logic for the compile options as the Linux kenrel does.
Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c
Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list.
Signed-off-by: Wolfgang Denk wd@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com Cc: Dirk Behme dirk.behme@googlemail.com Cc: Magnus Lilja lilja.magnus@gmail.com Cc: Tom Rix Tom.Rix@windriver.com Cc: Prafulla Wadaskar prafulla@marvell.com
I have run a full "MAKEALL arm" for ELDK releases 3.1 (gcc 3.3.3), 3.1.1 (gcc 3.3.3), 4.1 (gcc 4.0.0) and 4.2 (gcc 4.2.2, both as "arm" [softfloat] and "armVFP" [VFP hardfloat]), and all of these both with USE_PRIVATE_LIBGCC=yes (i. e. using U-Boot internal libgcc replacement code) and without (i. e. using the tool chain provided standard libgcc instead).
The ELDK fails to build the big-endian IXP boards, but this is a restriction of the ELDK, not a new issue introcued by this patch. Except of this, all build were succesful.
Note 1: Please note that older tool chains (based on binutils versions older than 2.16) will have problems with the SORT_BY_ALIGNMENT() and SORT_BY_NAME() functions introduced to the linker scripts with commit f62fb99941c6. I'll soon submit a patch to fix this issue. Final tests are running right now.
Note 2: Even though this is a bigger change, I consider it a bug fix and therefor tend to have it included into the upcoming release. Of course this requires sufficient test coverage and feedback. Please help!!
Note 3: Most ARM systems also define this: PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) I guess this can be unified and moved to lib_arm/config.mk, too, but I would like to handle this in a separate, later patch. This makes testing (and bisecting) easier, and it is a non-critical problem.
config.mk | 2 +- cpu/arm1136/config.mk | 2 -- cpu/arm1176/config.mk | 2 -- cpu/arm1176/s3c64xx/config.mk | 1 - cpu/arm720t/config.mk | 2 -- cpu/arm920t/config.mk | 2 -- cpu/arm925t/config.mk | 2 -- cpu/arm926ejs/config.mk | 2 -- cpu/arm926ejs/davinci/config.mk | 2 -- cpu/arm946es/config.mk | 2 -- cpu/arm_cortexa8/config.mk | 1 - cpu/arm_cortexa8/omap3/board.c | 7 ------- cpu/arm_intcm/config.mk | 2 -- cpu/ixp/config.mk | 1 - cpu/lh7a40x/config.mk | 2 -- cpu/pxa/config.mk | 2 -- cpu/s3c44b0/config.mk | 2 -- cpu/sa1100/config.mk | 2 -- lib_arm/Makefile | 15 ++++++++++++--- lib_arm/config.mk | 28 ++++++++++++++++++++++++++++ lib_arm/eabi_compat.c | 18 ++++++++++++++++++ 21 files changed, 59 insertions(+), 40 deletions(-) create mode 100644 lib_arm/eabi_compat.c
Applied.
Thanks to everybody who helped testing.
Best regards,
Wolfgang Denk
Hi,
On Fri, 21 Aug 2009 23:12:45 +0200 Wolfgang Denk wd@denx.de wrote:
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier:
I updated my git tree today and got this patch (among other things). It does not work very well for me, unfortunately. I've tried three toolchains (4.3.3, 4.3.4, 4.4.1) built with crosstool-ng, and all of them build an image which doesn't run correct.
It appears to be 64-bit issue:
U-Boot 2009.08-rc3-00014-gcea1f2a (Aug 24 2009 - 10:31:57) Marvell-OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 27507994220560384 MB NAND: 27510416582115328 MiB nand_bbt: Can't scan flash and build the RAM-based BBT Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 6871947673 0 Marvell>> Marvell>> Marvell>>
(I have 64-bit vsnprintf, and DRAM/NAND is reported correct without it). If I change PLATFORM_CPPFLAGS in lib_arm/config.mk to use apcs-linux instead of aapcs-linux it works again.
// Simon
Dear Simon Kagstrom,
In message 20090824105935.038bd229@marrow.netinsight.se you wrote:
I updated my git tree today and got this patch (among other things). It does not work very well for me, unfortunately. I've tried three toolchains (4.3.3, 4.3.4, 4.4.1) built with crosstool-ng, and all of them build an image which doesn't run correct.
Hm... aren't there known issues with these compiler versions on ARM?
It appears to be 64-bit issue:
U-Boot 2009.08-rc3-00014-gcea1f2a (Aug 24 2009 - 10:31:57) Marvell-OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 27507994220560384 MB NAND: 27510416582115328 MiB
Is this with or without USE_PRIVATE_LIBGCC=yes ?
Do you see any compiler warnings?
And - which board / configuration name is this?
Best regards,
Wolfgang Denk
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, August 24, 2009 3:32 PM To: Simon Kagstrom Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Simon Kagstrom,
In message 20090824105935.038bd229@marrow.netinsight.se you wrote:
I updated my git tree today and got this patch (among other
things). It
does not work very well for me, unfortunately. I've tried three toolchains (4.3.3, 4.3.4, 4.4.1) built with crosstool-ng, and all of them build an image which doesn't run correct.
Hm... aren't there known issues with these compiler versions on ARM?
I don't think so, I observed same behavior with sheevaplug, i.e. "nand_bbt: Can't scan flash and build the RAM-based BBT" message in nand init which was okay before this git pull
It appears to be 64-bit issue:
U-Boot 2009.08-rc3-00014-gcea1f2a (Aug 24 2009 - 10:31:57) Marvell-OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 27507994220560384 MB NAND: 27510416582115328 MiB
Is this with or without USE_PRIVATE_LIBGCC=yes ?
Yes, the build might be with this defined "yes", without this build throws error message
Do you see any compiler warnings?
I didn't see any warning on sheevaplug
And - which board / configuration name is this?
This is openrd board, not yet mainlined, it is derived from sheevaplug, (nand is similar) Alternately you can refer sheevaplug.h since problem is on sheevaplug too.
I tried removing this patch and things are normal on sheevaplug
Regards.. Prafulla . .
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Prafulla Wadaskar,
In message 73173D32E9439E4ABB5151606C3E19E202E3915D8B@SC-VEXCH1.marvell.com you wrote:
Hm... aren't there known issues with these compiler versions on ARM?
I don't think so, I observed same behavior with sheevaplug,
Which tool chain are you using? Do you see differnt behaviour with and without USE_PRIVATE_LIBGCC=yes ?
i.e. "nand_bbt: Can't scan flash and build the RAM-based BBT" message in nand init which was okay before this git pull
But this is a different error message, isn;t it?
Is this with or without USE_PRIVATE_LIBGCC=yes ?
Yes, the build might be with this defined "yes", without this build throws error message
Argh...
Could you please provide a usable error report?
Which exact tool chain is this? What are your exact commands to configure and build the board? What are the exact error messages?
This is openrd board, not yet mainlined, it is derived from sheevaplug, (na> nd is similar) Alternately you can refer sheevaplug.h since problem is on sheevaplug too.
I don;t see any error messages when building, and I don't have such a board to actually run the code.
I tried removing this patch and things are normal on sheevaplug
I wish you had reported such issues when the patch was posted. There has been _long_ discussion about it.
Best regards,
Wolfgang Denk
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Monday, August 24, 2009 5:27 PM To: Prafulla Wadaskar Cc: Simon Kagstrom; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Prafulla Wadaskar,
In message <73173D32E9439E4ABB5151606C3E19E202E3915D8B@SC-VEXCH1.marvell. com> you wrote:
Hm... aren't there known issues with these compiler
versions on ARM?
I don't think so, I observed same behavior with sheevaplug,
Which tool chain are you using? Do you see differnt behaviour with and without USE_PRIVATE_LIBGCC=yes ?
i.e. "nand_bbt: Can't scan flash and build the RAM-based
BBT" message in nand init
which was okay before this git pull
But this is a different error message, isn;t it?
Is this with or without USE_PRIVATE_LIBGCC=yes ?
Yes, the build might be with this defined "yes", without
this build throws error message
Argh...
Could you please provide a usable error report?
Which exact tool chain is this? What are your exact commands to configure and build the board? What are the exact error messages?
Toolchain I am using toolchain bundled with fedora arm distribution i.e. armv5tel-redhat-linux-gnueabi-gcc -v Using built-in specs. Target: armv5tel-redhat-linux-gnueabi Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++ --disable-libgcj --with-sysroot=yes --enable-version-specific-runtime-libs --target=armv5tel-redhat-linux-gnueabi Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33.fa1)
Build commands: make mrproper; make sheevaplug_config; make CROSS_COMPILE=armv5tel-redhat-linux-gnueabi- 2> warn.txt
This is openrd board, not yet mainlined, it is derived from
sheevaplug, (na> nd is similar)
Alternately you can refer sheevaplug.h since problem is on
sheevaplug too.
I don;t see any error messages when building, and I don't have such a board to actually run the code.
I get following erro only if I execute following build command make mrproper; make sheevaplug_config; make USE_PRIVATE_LIBGCC=no CROSS_COMPILE=armv5tel-redhat-linux-gnueabi- 2> warn.txt
And cat warn.txt armv5tel-redhat-linux-gnueabi-ld: cannot find -lgcc make: *** [u-boot] Error 1
Whereas, if I unset first USE_PRIVATE_LIBGCC then I do not get this error and build is through My invocation may be wrong but shouldn't it treat USE_PRIVATE_LIBGCC=no as unset?
I tried removing this patch and things are normal on sheevaplug
I wish you had reported such issues when the patch was posted. There has been _long_ discussion about it.
I am really sory about this, I was away from h/w hence could not check in time :-(
Regards.. Prafulla . .
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 "This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you?"
On Mon, 24 Aug 2009 05:41:59 -0700 Prafulla Wadaskar prafulla@marvell.com wrote:
I get following erro only if I execute following build command make mrproper; make sheevaplug_config; make USE_PRIVATE_LIBGCC=no CROSS_COMPILE=armv5tel-redhat-linux-gnueabi- 2> warn.txt
And cat warn.txt armv5tel-redhat-linux-gnueabi-ld: cannot find -lgcc make: *** [u-boot] Error 1
Whereas, if I unset first USE_PRIVATE_LIBGCC then I do not get this error and build is through My invocation may be wrong but shouldn't it treat USE_PRIVATE_LIBGCC=no as unset?
Well, I also got confused by this, but went through Wolfgangs exercise program. The top-level Makefile treats USE_PRIVATE_LIBGCC like this:
# Add GCC lib 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
and in this case, since USE_PRIVATE_LIBGCC is defined, but is not "yes", we will use it to set the linker search path. And indeed, it tries to link with
arm-unknown-linux-gnu-ld -Bstatic -T u-boot.lds [...] -L no -lgcc -Map u-boot.map -o u-boot
which ... will fail.
// Simon
Dear Prafulla Wadaskar,
In message 73173D32E9439E4ABB5151606C3E19E202E3915D98@SC-VEXCH1.marvell.com you wrote:
I get following erro only if I execute following build command make mrproper; make sheevaplug_config; make USE_PRIVATE_LIBGCC=no CROSS_COMPILE=armv5tel-redhat-linux-gnueabi- 2> warn.txt
And cat warn.txt armv5tel-redhat-linux-gnueabi-ld: cannot find -lgcc make: *** [u-boot] Error 1
This is to be expected, because the command is wrong. USE_PRIVATE_LIBGCC takes either the value "yes" (to use the U-Boot supplied routines, or the name of a directory which contains the needed libgcc.a library - and you don;t have a directory "no", it seems.
Whereas, if I unset first USE_PRIVATE_LIBGCC then I do not get this error and build is through My invocation may be wrong but shouldn't it treat USE_PRIVATE_LIBGCC=no as unset?
No, it should not.
Best regards,
Wolfgang Denk
On Mon, 24 Aug 2009 12:01:54 +0200 Wolfgang Denk wd@denx.de wrote:
I updated my git tree today and got this patch (among other things). It does not work very well for me, unfortunately. I've tried three toolchains (4.3.3, 4.3.4, 4.4.1) built with crosstool-ng, and all of them build an image which doesn't run correct.
Hm... aren't there known issues with these compiler versions on ARM?
I don't know, not that I've heard of at least, but perhaps someone else knows of something?
It appears to be 64-bit issue:
U-Boot 2009.08-rc3-00014-gcea1f2a (Aug 24 2009 - 10:31:57) Marvell-OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 27507994220560384 MB NAND: 27510416582115328 MiB
Is this with or without USE_PRIVATE_LIBGCC=yes ?
Yes, I believe so. If compiling with USE_PRIVATE_LIBGCC=no, the linker can't find libgcc.
Do you see any compiler warnings?
No.
And - which board / configuration name is this?
Sorry. As Prafulla said, it's openrd_base. I sent patches from this some time back,
http://lists.denx.de/pipermail/u-boot/2009-July/055374.html
I'll send an updated version of the patch, but it can't go in until mach-types.h has been updated at least. It's very similar to sheevaplug though, but uses 64-bit vsnprintf since it needs UBIFS support. I guess the nand_bbt problem is a similar issue.
// Simon
Dear Simon Kagstrom,
In message 20090824133829.6657fd66@marrow.netinsight.se you wrote:
Is this with or without USE_PRIVATE_LIBGCC=yes ?
Yes, I believe so. If compiling with USE_PRIVATE_LIBGCC=no, the linker can't find libgcc.
Arghh..
How am I supposed to help when all you can say is "I believe so" ???
Please understand that we cannot work based on same vague believes. We need clear facts.
Please re-run the tests with
$ USE_PRIVATE_LIBGCC=yes $ export USE_PRIVATE_LIBGCC $ make mrproper $ make ..._config $ make all
and with
$ unset USE_PRIVATE_LIBGCC $ make mrproper $ make ..._config $ make all
And for an excercise, try to understand why USE_PRIVATE_LIBGCC=no is bogus and cannot work.
I'll send an updated version of the patch, but it can't go in until mach-types.h has been updated at least. It's very similar to sheevaplug though, but uses 64-bit vsnprintf since it needs UBIFS support. I guess the nand_bbt problem is a similar issue.
Again, guesses are simply not good enough to spend any efforts. We need clear, reliable facts.
Best regards,
Wolfgang Denk
On Mon, 24 Aug 2009 14:01:20 +0200 Wolfgang Denk wd@denx.de wrote:
Please re-run the tests with
$ USE_PRIVATE_LIBGCC=yes $ export USE_PRIVATE_LIBGCC $ make mrproper $ make ..._config $ make all
and with
$ unset USE_PRIVATE_LIBGCC $ make mrproper $ make ..._config $ make all
Same result both ways.
I'll send an updated version of the patch, but it can't go in until mach-types.h has been updated at least. It's very similar to sheevaplug though, but uses 64-bit vsnprintf since it needs UBIFS support. I guess the nand_bbt problem is a similar issue.
Again, guesses are simply not good enough to spend any efforts. We need clear, reliable facts.
Well, since I can't say what's causing the problem, it's a guess.
The hard facts are that the printf issue goes away if I compile without CONFIG_SYS_64BIT_VSPRINTF, but the nand_bbt problem is always there. I've tried looking at the disassembled source code, in particular of the number() function and the calls of it in vsprintf.c, but I can't easily spot where it goes wrong.
// Simon
On Mon, 24 Aug 2009 12:01:54 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Simon Kagstrom,
In message 20090824105935.038bd229@marrow.netinsight.se you wrote:
I updated my git tree today and got this patch (among other things). It does not work very well for me, unfortunately. I've tried three toolchains (4.3.3, 4.3.4, 4.4.1) built with crosstool-ng, and all of them build an image which doesn't run correct.
Hm... aren't there known issues with these compiler versions on ARM?
Small update: I've tried with the ELDK toolchains 4.1 and 4.2 (2007-01-21 and 2008-11-24). Both these fail as well, albeit in a slightly different way. The printfs are correct, but 4.2 still has the nand_bbt issue:
U-Boot 2009.08-rc3-00013-g853ae64 (Aug 25 2009 - 08:28:05) Marvell-OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 512 MB NAND: 512 MiB nand_bbt: Can't scan flash and build the RAM-based BBT Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>>
The 4.1 version just hangs on the NAND printout. I've tested both with USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and get the same results.
// Simon
Dear Simon Kagstrom,
In message 20090825091256.0fc009d2@marrow.netinsight.se you wrote:
Small update: I've tried with the ELDK toolchains 4.1 and 4.2 (2007-01-21 and 2008-11-24). Both these fail as well, albeit in a slightly different way. The printfs are correct, but 4.2 still has the nand_bbt issue:
U-Boot 2009.08-rc3-00013-g853ae64 (Aug 25 2009 - 08:28:05) Marvell-OpenRD_base
SoC: Kirkwood 88F6281_A0 DRAM: 512 MB NAND: 512 MiB nand_bbt: Can't scan flash and build the RAM-based BBT Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>>
The 4.1 version just hangs on the NAND printout. I've tested both with USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and get the same results.
Did you make any progress an analyzing the cause of the issue?
Best regards,
Wolfgang Denk
On Fri, 04 Sep 2009 22:05:45 +0200 Wolfgang Denk wd@denx.de wrote:
nand_bbt: Can't scan flash and build the RAM-based BBT Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>>
The 4.1 version just hangs on the NAND printout. I've tested both with USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and get the same results.
Did you make any progress an analyzing the cause of the issue?
Well, I sent a patch "[PATCH, RFC] Make arm926ejs use -march=armv5t to avoid problems with EABI", which corrects this for me, although I'd like some input on if it really makes any sense.
The main difference I see between the two binaries is the use of ldrd/strd instructions, which comes with the "e"-version of armv5t. Obviously, that shouldn't by itself produce broken binaries, so something is still fishy here.
// Simon
-----Original Message----- From: Simon Kagstrom [mailto:simon.kagstrom@netinsight.net] Sent: Monday, September 07, 2009 11:54 AM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Prafulla Wadaskar; Jean-Christophe PLAGNIOL-VILLARD Subject: Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Fri, 04 Sep 2009 22:05:45 +0200 Wolfgang Denk wd@denx.de wrote:
nand_bbt: Can't scan flash and build the RAM-based BBT Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>>
The 4.1 version just hangs on the NAND printout. I've
tested both with
USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and
get the same
results.
Did you make any progress an analyzing the cause of the issue?
Well, I sent a patch "[PATCH, RFC] Make arm926ejs use -march=armv5t to avoid problems with EABI", which corrects this for me, although I'd like some input on if it really makes any sense.
I have tested this with Sheevaplug, this patch even works well for me too. The Kirkwood specification says that the core is armv5te compliant But this change is global, applicable for all arm926ejs based SoC which isn't relevant too. Do anybody have similar test results with other processors?
Since this is very specific NAND How about looking into NAND code?
Regards.. Prafulla . .
The main difference I see between the two binaries is the use of ldrd/strd instructions, which comes with the "e"-version of armv5t. Obviously, that shouldn't by itself produce broken binaries, so something is still fishy here.
// Simon
On Mon, 7 Sep 2009 01:59:13 -0700 Prafulla Wadaskar prafulla@marvell.com wrote:
Well, I sent a patch "[PATCH, RFC] Make arm926ejs use -march=armv5t to avoid problems with EABI", which corrects this for me, although I'd like some input on if it really makes any sense.
I have tested this with Sheevaplug, this patch even works well for me too. The Kirkwood specification says that the core is armv5te compliant But this change is global, applicable for all arm926ejs based SoC which isn't relevant too. Do anybody have similar test results with other processors?
Since this is very specific NAND How about looking into NAND code?
I did look at it, and indeed some of the ldrd/strd's are in the NAND code. I can't really see anything obviously wrong with the generated code.
However, it's not NAND-specific. Depending on GCC version, I get issues with vsprintf or complete lockups as well.
// Simon
participants (9)
-
Andrzej Wolski -
Dirk Behme -
Gaye Abdoulaye Walsimou -
ksi＠koi8.net -
Magnus Lilja -
Prafulla Wadaskar -
Simon Kagstrom -
Tom -
Wolfgang Denk