[U-Boot] Relocation issue - need help!

[Tom Rini <trini@konsulko.com>]

On Tue, Oct 20, 2015 at 04:06:51PM -0500, Andy Fleming wrote:
> On Fri, Oct 16, 2015 at 8:14 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> > On Fri, 2015-10-16 at 07:47 -0400, Tom Rini wrote:
> >> 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@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).
> >
> > I had gcc 4.8.4(before I upgraded) and it was broken. 4.8.2 is also broken.
> >
> > I don't think this bug is present on older(<4.8) gcc's, the author to the patch
> > claims that bug is not present in gcc 4.7.3
> >
> > My old gcc 4.5.3 works fine also
> 
> My 4.6.3 has the issue (but it shows up in a different place than with
> my 4.8.3).

Then we need a different flag there :(  Does what Joakim found maybe
provide a hint?

-- 
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/20151020/e94b9a7c/attachment.sig>