[U-Boot] PowerPC -mrelocatable

[Peter Tyser <ptyser@xes-inc.com>]

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@this point btw.

Let me know if others have any input.

Best,
Peter