On Mon, Sep 8, 2014 at 9:04 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
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:
I can turn this into a proper patch. As you say below all powerpc implementations have this -1. I can test MPC85xx but I don't have access to any of the others. Also by "test" all I can really do is printf("%p\n", &NetArpWaitTimerStart); is there something better I should be doing?
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,-41: 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
I had actually seen this kind of error before with some usb routines[1]. Again the symbol happened to be something that was at the end of .sbss. In this particular case something else changed and the problem went away so I didn't pursue it but I think this problem may have been around for a while probably since 337f5f50 (PowerPC: Add relocation support for -fpic).
-- [1] - http://lists.denx.de/pipermail/u-boot/2013-June/156435.html