On Wed, 2015-10-21 at 09:12 -0400, Tom Rini wrote: > On Wed, Oct 21, 2015 at 08:44:15AM +0000, Joakim Tjernlund wrote: > > On Tue, 2015-10-20 at 17:21 -0400, Tom Rini wrote: > > > 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.tjernl...@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 > > > > > > > > > > > > > <w...@denx.de> wrote: > > > > > > > > > > > > > > Dear Joakim, dear Dirk, > > > > > > > > > > > > > > > > > > > > > > > > > > > > In message <OF14C3D470.864842B6-ONC1257D7A.002471AC- > > > > > > > > > > > > c1257d7a.0024d...@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@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? > > > > > > > Different? Does not -fno-ira-hoist-pressure help for all gcc's ? > > -fno-ira-hoist-pressure is an optimization that u-boot can be without. > > I swear that I tried with my 4.7.2 toolchain (ELDK-5.3) and it didn't > know about that option. > Then it could be another bug perhaps? Are you sure the bug is in 4.7.2? I read test case as, if *.s has a:
.section .data.rel.ro.local,"aw",@progbits .align 2 .LC5: .4byte .LC0 Then there must be a fixup too. Jocke _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot