Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Fri, 04 Sep 2009 22:05:45 +0200 Wolfgang Denk w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
-Original Message- From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] Sent: Monday, September 07, 2009 11:54 AM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Prafulla Wadaskar; Jean-Christophe PLAGNIOL-VILLARD Subject: Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support On Fri, 04 Sep 2009 22:05:45 +0200 Wolfgang Denk w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Mon, 7 Sep 2009 01:59:13 -0700 Prafulla Wadaskar prafu...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Simon Kagstrom, In message 20090825091256.0fc00...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Mon, 24 Aug 2009 12:01:54 +0200 Wolfgang Denk w...@denx.de wrote: Dear Simon Kagstrom, In message 20090824105935.038bd...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Hi, On Fri, 21 Aug 2009 23:12:45 +0200 Wolfgang Denk w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Simon Kagstrom, In message 20090824105935.038bd...@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: w...@denx.de You don't need a weatherman to know which way the wind blows. - Bob Dylan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, August 24, 2009 3:32 PM To: Simon Kagstrom Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support Dear Simon Kagstrom, In message 20090824105935.038bd...@marrow.netinsight.se you wrote: I updated my git tree today and got this patch (among other things). It does not work very well for me, unfortunately. I've tried three toolchains (4.3.3, 4.3.4, 4.4.1) built with crosstool-ng, and all of them build an image which doesn't run correct. Hm... aren't there known issues with these compiler versions on ARM? I don't think so, I observed same behavior with sheevaplug, i.e. nand_bbt: Can't scan flash and build the RAM-based BBT message in nand init which was okay before this git pull It appears to be 64-bit issue: U-Boot 2009.08-rc3-00014-gcea1f2a (Aug 24 2009 - 10:31:57) Marvell-OpenRD_base SoC: Kirkwood 88F6281_A0 DRAM: 27507994220560384 MB NAND: 27510416582115328 MiB Is this with or without USE_PRIVATE_LIBGCC=yes ? Yes, the build might be with this defined yes, without this build throws error message Do you see any compiler warnings? I didn't see any warning on sheevaplug And - which board / configuration name is this? This is openrd board, not yet mainlined, it is derived from sheevaplug, (nand is similar) Alternately you can refer sheevaplug.h since problem is on sheevaplug too. I tried removing this patch and things are normal on sheevaplug Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Mon, 24 Aug 2009 12:01:54 +0200 Wolfgang Denk w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202e3915...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Simon Kagstrom, In message 20090824133829.6657f...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, August 24, 2009 5:27 PM To: Prafulla Wadaskar Cc: Simon Kagstrom; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202e3915...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Mon, 24 Aug 2009 14:01:20 +0200 Wolfgang Denk w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Mon, 24 Aug 2009 05:41:59 -0700 Prafulla Wadaskar prafu...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202e3915...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
In message 1250507849-31660-1-git-send-email...@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 w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@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
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
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 awol...@poczta.fm Regards -- Wygraj telefon dla swojego dziecka. 20 sztuk czeka! Sprawdz http://link.interia.pl/f22d8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Gaye Abdoulaye Walsimou, In message 4a8a8b27.7080...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
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 w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@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 walsi...@walsimou.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Wolfgang, 2009/8/17 Wolfgang Denk w...@denx.de: Dear Magnus Lilja, In message 59b21cf20908171317s10d7fdb5t631c37f06707e...@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.mag...@gmail.com Run-time tested on i.MX31 PDK board using the above toolchains. Regards, Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
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 w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@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@windriver.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Magnus Lilja, In message 59b21cf20908181008t75a981d8g512c10687c0b8...@mail.gmail.com you wrote: Tested-by: Magnus Lilja lilja.mag...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Tom, In message 4a8af7d9.7070...@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@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: w...@denx.de Wenn das dann in die Hose geht, nehme ich es auf meine Kappe. -- Rudi Völler, 15. Nov 2003 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier: - Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead. - So far, we only checked if -mapcs-32 was supported by the tool chain; if yes, this was used, if not, -mabi=apcs-gnu was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic: 1) If the tool chain supports -mabi=aapcs-linux -mno-thumb-interwork we use these options (EABI conformant tool chain). 2) Otherwise, we check first if -mapcs-32 is supported, and then check for -mabi=apcs-gnu If one test succeeds, we use the first found option. 3) In case 2), we also test if -mno-thumb-interwork, and use this if the test succeeds. [For -mabi=aapcs-linux we set -mno-thumb-interwork mandatorily.] This way we use a similar logic for the compile options as the Linux kenrel does. - Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@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#
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Tom, In message 4a895462.1020...@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Mon, 17 Aug 2009, Wolfgang Denk wrote: Ack-by: Sergey Kubushyn k...@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 w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@marvell.com --- --- ** * k...@homeKOI8 Net The impossible we do immediately. * * Las Vegas NV, USA Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Hi Wolfgang, 2009/8/17 Wolfgang Denk w...@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 w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Magnus Lilja, In message 59b21cf20908171317s10d7fdb5t631c37f06707e...@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: w...@denx.de Time is an illusion perpetrated by the manufacturers of space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
