[U-Boot] Relocation issue - need help!

[Joakim Tjernlund <joakim.tjernlund@transmode.se>]

On Thu, 2015-10-01 at 08:57 +0000, Joakim Tjernlund wrote:
> On Wed, 2015-09-30 at 21:35 +0200, Marek Vasut wrote:
> > On Wednesday, September 30, 2015 at 08:24:10 PM, Andy Fleming wrote:
> > 
> > Hi!
> > 
> > > On Thu, Oct 23, 2014 at 8:10 AM, Wolfgang Denk <wd@denx.de> wrote:
> > > > Dear Joakim, dear Dirk,
> > > > 
> > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC-
> > C1257D7A.0024DEC4 at transmode.se> you wrote:
> > > > > Ouch, that was a nasty surprise.
> > > > 
> > > > Indeed.
> > > > 
> > > > > > In my original mail I referenced this potential solution, at least it
> > > > > > worked for me:
> > > > > > https://gcc.gnu.org/ml/gcc-help/2014-02/msg00054.html
> > > > > 
> > > > > That looks like the correct fix but I presume both .data.rel.ro and
> > > > > data.rel.ro.local should be added?
> > > > 
> > > > I can confirm:
> > > > 
> > > > 1) The problem was observed with gcc 4.8.1 [as in Yocto 1.5.x / ELDK
> > > > 
> > > >    5.5.x].
> > > > 
> > > > 2) Switching back to gcc 4.7.2 [as in Yocto 1.4 / ELDK 5.4] makes the
> > > > 
> > > >    problem go away.
> > > > 
> > > > 3) Switching forward to gcc 4.9.1 [as in Yocto 1.7 / ELDK 5.7] makes
> > > > 
> > > >    the problem go away.
> > > > 
> > > > 4) For the problemativ 4.8.x versions of GCC, the following patch
> > > > 
> > > >    apparently solves the problem for my (MPC5200 based) board - guess
> > > >    this would have to be applied to all .lds files...
> > > > 
> > > > diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..82c86d7 100644
> > > > --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
> > > > @@ -27,6 +27,8 @@ SECTIONS
> > > > 
> > > >    {
> > > >    
> > > >      _GOT2_TABLE_ = .;
> > > >      KEEP(*(.got2))
> > > > 
> > > > +    KEEP(*(.data.rel.ro))
> > > > +    KEEP(*(.data.rel.ro.local))
> > > > 
> > > >      KEEP(*(.got))
> > > >      PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
> > > >      _FIXUP_TABLE_ = .;
> > > > 
> > > > Given that GCC 4.9.1 apparently solves this issue I wonder which
> > > > approach we should take?
> > > > 
> > > > Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> > > > doing [1] ?
> > > > 
> > > > [1] https://lkml.org/lkml/2014/10/10/272
> > > 
> > > Was there a resolution to this thread? I just spent a bunch of time
> > > trying to figure out why u-boot was crashing, and eventually
> > > determined that switching from 4.9.0 to 4.6.3 solved the problem.
> > > Should I submit a patch to do what was suggested above? Or add the
> > > "blacklist" patch? If so, it should be noted that 4.9.0 is the current
> > > default installed when you ask buildman to install a powerpc cross
> > > compiler...
> > 
> > Blacklist patch please, thank you!
> 
> Yes, but all gcc 4.8.x versions?
> 
> There is a fix here 
>   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01679.html
> but I don't know if it got committed or not or which version.
> 
> I am using gcc 4.8.4 and it works but I have one problem, if I erase uboot
> after relocation, u-boot misbehavex or crashes so there is something off still.
> 
> Does it work for all but me to erase u-boot after relocation?
> Using T1040(mpc85xx family)

Here is a better URL:
http://patchwork.ozlabs.org/patch/342888/

From what I can tell the above bug has been fixed in gcc 4.8.5(4.8.4 has the error)
and 4.9.3 (by looking at varasm.c).

Adding KEEP(*(.data.rel.ro.local)) i u-boot.lds does not seem to be the
correct fix as it is not an .fixup entry?

 Jocke