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:

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.

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.

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

Cc Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

Cc Dirk Behme <[email protected]>

Cc Magnus Lilja <[email protected]>

Cc Tom Rix <[email protected]>

Cc Prafulla Wadaskar <[email protected]>

---

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

Cc Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

Cc Dirk Behme <[email protected]>

Cc Magnus Lilja <[email protected]>

Cc Tom Rix <[email protected]>

Cc Prafulla Wadaskar <[email protected]>

---

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

Quoted 3 lines

This way we use a similar logic for the compile options as the Linux kenrel does.

"kenrel" => "kernel" :-)

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.

Dear Magnus Lilja,

Quoted 5 lines · In message <[email protected]> you…

Quoted 3 lines

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

Quoted 5 lines

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.

Quoted 2 lines

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

Run-time tested on i.MX31 PDK board using the above toolchains.

I tested your patch against 7dedefdf749ff02c1086f7ddb8cb83a77b00d030

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

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

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

Cc Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

Cc Dirk Behme <[email protected]>

Cc Magnus Lilja <[email protected]>

Cc Tom Rix <[email protected]>

Cc Prafulla Wadaskar <[email protected]>

---

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.

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

Cc Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

Cc Dirk Behme <[email protected]>

Cc Magnus Lilja <[email protected]>

Cc Tom Rix <[email protected]>

Cc Prafulla Wadaskar <[email protected]>

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

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

Cc Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

Cc Dirk Behme <[email protected]>

Cc Magnus Lilja <[email protected]>

Cc Tom Rix <[email protected]>

Cc Prafulla Wadaskar <[email protected]>

---

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

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

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

Quoted 1 line · In message <[email protected]> you wrote:

Quoted 1 line

I updated my git tree today and got this patch (among other

things). It

Quoted 3 lines

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?

Quoted 9 lines

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?

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 2 lines

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

Quoted 1 line

Is this with or without USE_PRIVATE_LIBGCC=yes ?

Yes, the build might be with this defined "yes", without this build throws error message

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 tried removing this patch and things are normal on sheevaplug

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

Quoted 2 lines · com> you wrote:

Quoted 2 lines

Hm... aren't there known issues with these compiler

versions on ARM?

Quoted 1 line

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 ?

Quoted 1 line

i.e. "nand_bbt: Can't scan flash and build the RAM-based

BBT" message in nand init

Quoted 1 line

which was okay before this git pull

But this is a different error message, isn;t it?

Quoted 2 lines

Quoted 1 line

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?

Quoted 2 lines

This is openrd board, not yet mainlined, it is derived from

sheevaplug, (na> nd is similar)

Quoted 1 line

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.

Quoted 2 lines

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

Signature · 5 lines

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

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

Quoted 4 lines

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?

Quoted 8 lines

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?

Quoted 2 lines

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.

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.

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

Quoted 4 lines

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.

Dear Simon Kagstrom,

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

Quoted 9 lines

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?

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

Quoted 7 lines · On Fri, 04 Sep 2009 22:05:45 +0200 Wolfgang Denk <[email protected]> wrote:

Quoted 7 lines

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

Quoted 1 line

Quoted 1 line

USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and

get the same

Quoted 3 lines

Quoted 1 line

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

Quoted 3 lines

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?