[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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;
+}
-- 
1.6.0.6

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Tom]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human race is a race of cowards; and I am not  only  marching  in
that procession but carrying a banner.                   - Mark Twain

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Dirk Behme]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[ksi at koi8.net]

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

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Magnus Lilja]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Time is an illusion perpetrated by the manufacturers of space.

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Gaye Abdoulaye Walsimou]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I think there's a world market for about five computers.
         -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Gaye Abdoulaye Walsimou]

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:
>
>   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.
>
>  
Tested-by: Gaye Abdoulaye Walsimou <walsimou@walsimou.com>

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Magnus Lilja]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Tom]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
About the use of language: it is impossible to sharpen a pencil  with
a  blunt  ax.  It is equally vain to try to do it with ten blunt axes
instead.                                           -- Edsger Dijkstra

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Wenn das dann in die Hose geht, nehme ich es auf meine Kappe.
                                         -- Rudi V?ller, 15. Nov 2003

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Andrzej Wolski]

> 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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[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:
> 
>   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

Applied.

Thanks to everybody who helped testing.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Simon Kagstrom]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You don't need a weatherman to know which way the wind blows.
                                                          - Bob Dylan

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Prafulla Wadaskar]

 

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de 
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Wolfgang Denk
> Sent: Monday, August 24, 2009 3:32 PM
> To: Simon Kagstrom
> Cc: u-boot at 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Simon Kagstrom]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"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?"

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Logic and practical information do not seem to apply here."
"You admit that?"
"To deny the facts would be illogical, Doctor"
	-- Spock and McCoy, "A Piece of the Action", stardate unknown

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Prafulla Wadaskar]

 

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de] 
> Sent: Monday, August 24, 2009 5:27 PM
> To: Prafulla Wadaskar
> Cc: Simon Kagstrom; u-boot at 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 at 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?"
> 

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Simon Kagstrom]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Simon Kagstrom]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He only drinks when he gets depressed." "Why does he get depressed?"
"Sometimes it's because he hasn't had a drink."
                                     - Terry Pratchett, _Men at Arms_

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Simon Kagstrom]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"They that can give up essential liberty to obtain a little temporary
saftey deserve neither liberty not saftey." - Benjamin Franklin, 1759

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Simon Kagstrom]

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

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Prafulla Wadaskar]

 

> -----Original Message-----
> From: Simon Kagstrom [mailto:simon.kagstrom at netinsight.net] 
> Sent: Monday, September 07, 2009 11:54 AM
> To: Wolfgang Denk
> Cc: u-boot at 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
> 
> 

[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Simon Kagstrom]

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