[U-Boot] Relocation issue - need help!

Fri Oct 16 13:47:29 CEST 2015

On Fri, Oct 16, 2015 at 06:55:58AM +0000, Joakim Tjernlund wrote:
> On Thu, 2015-10-15 at 17:58 -0400, Tom Rini wrote:
> > On Thu, Oct 15, 2015 at 03:56:09PM +0000, Joakim Tjernlund wrote:
> > > On Tue, 2015-10-06 at 11:17 +0000, Joakim Tjernlund wrote:
> > > > 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 at 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?
> > > 
> > > After upgrading to gcc 4.9.3 I still see this bug(there is no .fixup entry)
> > > The bug can be avoided with -fno-ira-hoist-pressure and while you are it,
> > > throw in -mbss-plt to reduce size
> > 
> > Would something like this fix it then?  Or at least work-around in-field
> > toolchains?
> > 
> > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
> > index 83b49b5..2be5b46 100644
> > --- a/arch/powerpc/config.mk
> > +++ b/arch/powerpc/config.mk
> > @@ -13,7 +13,7 @@ CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000
> >  LDFLAGS_FINAL += --gc-sections
> >  LDFLAGS_FINAL += --bss-plt
> >  PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections \
> > --fdata-sections -mcall-linux
> > +-fdata-sections -mcall-linux $(call cc-option,-fno-ira-hoist-pressure,)
> >  
> >  PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -m32
> >  PLATFORM_LDFLAGS  += -m32 -melf32ppclinux
> > 
> 
> In theory yes, that is what the above URLs claim and what my small compile tests supports.
> In addition, this works for me now:
> => printenv tftpflash 
> tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && erase $ubootaddr +$filesize && cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr $filesize
> 
> 
> => run tftpflash 
> Using FM1 at DTSEC1 device
> TFTP from server 172.20.4.10; our IP address is 172.20.4.13
> Filename 'u-boot.bin'.
> Load address: 0x1000000
> Loading: ######################################################
> 	 7.4 MiB/s
> done
> Bytes transferred = 786432 (c0000 hex)
> ...... done
> Un-Protected 6 sectors
> 
> ...... done
> Erased 6 sectors
> Copy to Flash... 9....8....7....6....5....4....3....2....1....done
> ...... done
> Protected 6 sectors
> Total of 786432 byte(s) were the same

OK.  Do you have some of the broken older toolchains as well?  I think
this will at least correct 4.9 and maybe 4.8, but older toolchains don't
have that option (but if there's another option for making older still
toolchains work, we can do that too on the other side of the cc-option).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151016/d17be53c/attachment.sig>