Re: [U-Boot] PowerPC -mrelocatable

2009-09-11 Thread Peter Tyser
Hi Wolfgang,

  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.
 
 Do you have an up-to-date patch that can be used for such testing?

I just sent an example patch (ppc: Relocation test patch) that others
can use (or quickly adapt) to test their board using relocation proper.
It'd be great if others could give any feedback on what impact this
patch has on their board.

  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.
 
 Agreed.
 
  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.
 
 I think there would be not  much  lost  if  we  dropped  support  for
 versions before gcc-4.x

I agree.  I believe 3.4.5 or 3.4.6 and later should work, but haven't
tested this hypothesis to any great degree.

I can generate a proper patch if the example patch doesn't break things
badly.

Best,
Peter

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


Re: [U-Boot] PowerPC -mrelocatable

2009-09-09 Thread Joakim Tjernlund

 Dear Peter,

 In message 1252426573.6005.253.ca...@localhost.localdomain you wrote:
 
  Going over the emails and my own testing, it looks the following
  versions worked:
 ...

 Thanks for the detailed analysis.

 I remember that gcc-3.4.x has always been marked as suspicious in
 our tests, so for example we avoided basing an ELDK release on it.

  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.

 Do you have an up-to-date patch that can be used for such testing?

  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.

 Agreed.

  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.

 I think there would be not  much  lost  if  we  dropped  support  for
 versions before gcc-4.x

Please don't. I still use gcc 3.4.6 and it has no issues. I suggest
dropping support for gcc  3.4.6 instead.

 Jocke

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


Re: [U-Boot] PowerPC -mrelocatable

2009-09-08 Thread Peter Tyser
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


Re: [U-Boot] PowerPC -mrelocatable

2009-09-08 Thread Mike Frysinger
On Tuesday 08 September 2009 12:16:13 Peter Tyser wrote:
 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
 
 ...
 
 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.

or run readelf on the objects that are known to not generate fixup stuff and 
error out if they're missing in the objects ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] PowerPC -mrelocatable

2009-09-08 Thread Wolfgang Denk
Dear Peter,

In message 1252426573.6005.253.ca...@localhost.localdomain you wrote:

 Going over the emails and my own testing, it looks the following
 versions worked:
...

Thanks for the detailed analysis.

I remember that gcc-3.4.x has always been marked as suspicious in
our tests, so for example we avoided basing an ELDK release on it.

 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.

Do you have an up-to-date patch that can be used for such testing?

 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.

Agreed.

 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.

I think there would be not  much  lost  if  we  dropped  support  for
versions before gcc-4.x

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
A Perl script is correct if it's halfway readable and  gets  the  job
done before your boss fires you.
   - L. Wall  R. L. Schwartz, _Programming Perl_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] PowerPC -mrelocatable

2009-08-27 Thread Scott Wood
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.

If we're now at the point where current GCC works, and has for several 
releases, we should probably consider revisiting those patches.

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot