> > There are some disadvantages to living in a weird timezone, mostly > that you end up having conversations with yourself. > > On Mon, Sep 8, 2014 at 4:32 PM, Chris Packham <judge.pack...@gmail.com> wrote: > > Hi All, > > > > I have come across what I think is a relocation problem for powerpc. > > > > I've added the following to ArpTimeoutCheck > > > > + printf("NetArpWaitTimerStart = %ld\n", NetArpWaitTimerStart); > > + printf("&NetArpWaitTimerStart = %p\n", &NetArpWaitTimerStart); > > + printf("NetArpWaitTry = %d\n", NetArpWaitTry); > > + printf("&NetArpWaitTry = %p\n", &NetArpWaitTry); > > + printf("NetArpWaitTxPacketSize = %d\n", NetArpWaitTxPacketSize); > > + printf("&NetArpWaitTxPacketSize = %p\n", &NetArpWaitTxPacketSize); > > > > Which yields the following output > > > > NetArpWaitTimerStart = 0 > > &NetArpWaitTimerStart = f00000d0 > > NetArpWaitTry = 1 > > &NetArpWaitTry = 7ffb0058 > > NetArpWaitTxPacketSize = 42 > > &NetArpWaitTxPacketSize = 7ffb0078 > > > > That looks to me like NetArpWaitTimerStart hasn't been relocated for > > some reason. Looking at my u-boot.map NetArpWaitTimerStart is the last > > item in the .sbss section > > > > Here's the relevant snippets for the variables I'm displaying > > > > 0x00000000f0000058 NetArpWaitTry > > 0x00000000f0000078 NetArpWaitTxPacketSize > > 0x00000000f00000d0 NetArpWaitTimerStart > > > > The actual problem for me is that ARPs timeout and various network > > things fail. Has anyone got any clues as to why this one particular > > variable isn't getting relocated. > > > > Thanks, > > Chris > > > > More info: > > I'm building P2041RDB_config > > > > $ git describe > > v2014.10-rc2-15-g2ec8915 > > > > => version > > U-Boot 2014.10-rc2-00015-g2ec8915-dirty (Sep 08 2014 - 16:18:42) > > powerpc-e500-linux-gnu-gcc (Gentoo 4.6.3-r1 p1.9, pie-0.5.2) 4.6.3 > > GNU ld (GNU Binutils) 2.21 > > I'm not confident enough to say it's a fix but the following seems to > solve the relocation problem for NetArpWaitTimerStart. > > diff --git a/arch/powerpc/cpu/mpc85xx/u-boot.lds > b/arch/powerpc/cpu/mpc85xx/u-boot.lds > index 2cf0b25..36711b0 100644 > --- a/arch/powerpc/cpu/mpc85xx/u-boot.lds > +++ b/arch/powerpc/cpu/mpc85xx/u-boot.lds > @@ -54,7 +54,7 @@ SECTIONS > _FIXUP_TABLE_ = .; > KEEP(*(.fixup)) > } > - __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1; > + __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2); > __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
This looks like the correct fix, The relevant code that uses __got2_entries is in start.S: in_ram: /* * Relocation Function, r12 point to got2+0x8000 * * Adjust got2 pointers, no need to check for 0, this code * already puts a few entries in the table. */ li r0,__got2_entries@sectoff@l la r3,GOT(_GOT2_TABLE_) lwz r11,GOT(_GOT2_TABLE_) mtctr r0 sub r11,r3,r11 addi r3,r3,-4 1: lwzu r0,4(r3) cmpwi r0,0 beq- 2f add r0,r0,r11 stw r0,0(r3) 2: bdnz 1b bdnz does decrement then test for zero so __got2_entries should hold the number of entries to relocate. Seems like most(all?) ppc cpu has this error. Jocke _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot