On Thu, 2009-08-27 at 12:49 -0500, Scott Wood wrote: > Peter Tyser wrote: > > On Thu, 2009-08-27 at 10:38 -0500, Scott Wood wrote: > >> Someone tried to get proper relocation working a while ago, but ran into > >> toolchain bugs. Maybe current toolchains are better... > > > > X-ES's board's in U-Boot fully relocate to SDRAM with the > > CONFIG_RELOC_FIXUP_WORKS define and -mrelocatable compiler flag. This > > feature has worked with gcc-4.3.1/binutils-2.18.90 and > > gcc-4.2.2/binutils-2.17.50. > > > > Does anyone have a specific example of a toolchain that doesn't work? > > It'd be great to get the issue figured out and get rid of all those > > gd->reloc_off references that currently litter the code... > > According to these e-mails: > http://lists.denx.de/pipermail/u-boot/2007-October/025937.html > http://lists.denx.de/pipermail/u-boot/2007-October/025941.html > > it worked in (at least some) 4.0, but not (at least some) 3.x or 4.1.
Going over the emails and my own testing, it looks the following versions worked: gcc 4.0.0 gcc 4.0.2 gcc 4.1.1, binutils 2.16 (I've verified this) gcc 4.2.2, binutils 2.17 (I've verified this) gcc 4.3.1, binutils 2.17 (I've verified this) And the following didn't: gcc 3.4.3, glibc 2.3.4, binutils 2.15.94 gcc 4.1.2, glibc 2.5, binutils 2.17 *** gcc 4.1.78 *** > If we're now at the point where current GCC works, and has for several > releases, we should probably consider revisiting those patches. I did some debug on gcc 3.4.3/binutils2.3.4/glibc2.15 which was a known non-working setup on an MPC8548-based board. I'm 98% sure the the reason it fails because it doesn't properly generate .fixup sections. No .fixup sections are present in any of the compiled objects or u-boot. This results in the link script variable '__fixup_entries' equalling 0, so no relocation fixups are performed on bootup (eg see line 943 in cpu/mpc85xx/start.S). It looks like this was a gcc bug that has been fixed: http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00057.html gcc 4.1.2 and 4.1.78 have the gcc relocation fix in it, so that isn't the issue for them. I tried gcc 4.1.2/binutils 2.17 from one of Freescale's BSPs (looks to be very similar to the one described here: http://www.freescale.com/files/soft_dev_tools/doc/support_info/BSPMPC5121EADSRN.txt?fsrch=1) and it actually worked! I'm guessing that the "broken" versions of gcc 4.1.2 and 4.1.78 are actually the same Freescale-provided compiler. The toolchain Freescale provided is really version 4.1.2, but the path of the compiler contains "gcc-4.1.78-eglibc-2.5.78-dp-1". gcc 4.1.78 doesn't exist, so I'm guessing someone in the threads above was using Freescale's gcc 4.1.2, but made the mistake of calling it 4.1.78 based on its misleading install path. So in summary, there appears to be a bug in gcc for version 3.4.3 which prevents relocation from working, and I was unable to find any issues with 4.1.2. The fact that all 4.0.0, 4.1.1, 4.2.2, 4.3.1 worked also would lead me to believe 4.1.2 should also work. Does anyone out there by chance have a failure case for gcc > 4.0.0, because I can't seem to reproduce the issues others had in the past. My vote would be to find out which version of gcc contains the relocation bug and spit out an error if gcc < than that version is used. We could also try and get fancy and dynamically turn on/off relocation support at compile time based on gcc's version if other's wanted to maintain support for older compilers. These changes would only be for ppc at this point btw. Let me know if others have any input. Best, Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
