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
