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.packham@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