[U-Boot] relocation problem on powerpc
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
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
Actually could this be a compiler problem? I tried a different toolchain and got some different results. Any suggestions for diagnosing it?
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;
.data :
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
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
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,-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.
Looking at u-boot.lds: .reloc : { _GOT2_TABLE_ = .; KEEP(*(.got2)) KEEP(*(.got)) PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4); _FIXUP_TABLE_ = .; KEEP(*(.fixup)) } __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1; __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
There is something more to this error. Since _GLOBAL_OFFSET_TABLE_ is defined to _GLOBAL_OFFSET_TABLE_ = . + 4 there is one extra entry added( for brlr insn inserted by the linker) so something is amiss here, is there a brlr insns at _GLOBAL_OFFSET_TABLE_-4 in your u-boot?
Jocke
Hi Jocke,
On Tue, Sep 9, 2014 at 12:22 AM, 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
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,-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.
Looking at u-boot.lds: .reloc : { _GOT2_TABLE_ = .; KEEP(*(.got2)) KEEP(*(.got)) PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4); _FIXUP_TABLE_ = .; KEEP(*(.fixup)) } __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1; __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
There is something more to this error. Since _GLOBAL_OFFSET_TABLE_ is defined to _GLOBAL_OFFSET_TABLE_ = . + 4 there is one extra entry added( for brlr insn inserted by the linker) so something is amiss here, is there a brlr insns at _GLOBAL_OFFSET_TABLE_-4 in your u-boot?
Jocke
Here's some more info from a build without any of my modifications.
$ git describe v2014.10-rc2-12-g0b703db
$ powerpc-e500-linux-gnu-gcc --version powerpc-e500-linux-gnu-gcc (Gentoo 4.6.3-r1 p1.9, pie-0.5.2) 4.6.3
$ grep '_GOT2_TABLE_|_GLOBAL_OFFSET_TABLE_|__got2_entries' u-boot.map 0x00000000effb5100 _GOT2_TABLE_ = . 0x00000000effb7d38 _GLOBAL_OFFSET_TABLE_ 0x00000000effb7d48 PROVIDE (_GLOBAL_OFFSET_TABLE_, (. + 0x4)) 0x0000000000000b0d __got2_entries = (((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 0x2) - 0x1)
$ gdb-multiarch u-boot (gdb) disassemble /r 0xeffb5100,0xeffb7d48 Dump of assembler code from 0xeffb5100 to 0xeffb7d48: 0xeffb5100 <_GOT2_TABLE_+0>: ef fb 51 00 .long 0xeffb5100 0xeffb5104 <_GOT2_TABLE_+4>: ef fb 7d 44 dtstsf cr7,f27,f15 0xeffb5108 <_GOT2_TABLE_+8>: ef f4 00 00 .long 0xeff40000 0xeffb510c <_GOT2_TABLE_+12>: ef f4 01 00 .long 0xeff40100 <snip> 0xeffb7d30 <_GOT2_TABLE_+11312>: ef f6 6e 74 .long 0xeff66e74 0xeffb7d34 <_GOT2_TABLE_+11316>: f0 00 00 d0 psq_st f0,208(r0),0,0 0xeffb7d38 <_GLOBAL_OFFSET_TABLE_+0>: 00 00 00 00 .long 0x0 0xeffb7d3c <_GLOBAL_OFFSET_TABLE_+4>: 00 00 00 00 .long 0x0 0xeffb7d40 <_GLOBAL_OFFSET_TABLE_+8>: 00 00 00 00 .long 0x0 0xeffb7d44 <_FIXUP_TABLE_+0>: ef fb 99 d4 .long 0xeffb99d4
So no there is no brlr at the end of the table.
Also I think the __got2_entries calculation does not take into account the +0x4, ((0xeffb7d38-0xeffb5100)>>2)-1) = 0xb0d
Chris Packham judge.packham@gmail.com wrote on 2014/09/09 01:07:51:
From: Chris Packham judge.packham@gmail.com To: Joakim Tjernlund joakim.tjernlund@transmode.se, Cc: u-boot u-boot@lists.denx.de Date: 2014/09/09 01:08 Subject: Re: [U-Boot] relocation problem on powerpc
Hi Jocke,
On Tue, Sep 9, 2014 at 12:22 AM, 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
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,-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.
Looking at u-boot.lds: .reloc : { _GOT2_TABLE_ = .; KEEP(*(.got2)) KEEP(*(.got)) PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4); _FIXUP_TABLE_ = .; KEEP(*(.fixup)) } __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1; __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
There is something more to this error. Since _GLOBAL_OFFSET_TABLE_ is defined to _GLOBAL_OFFSET_TABLE_ = . + 4 there is one extra entry added( for brlr insn inserted by the linker)
so
something is amiss here, is there a brlr insns at _GLOBAL_OFFSET_TABLE_-4 in your u-boot?
Jocke
Here's some more info from a build without any of my modifications.
$ git describe v2014.10-rc2-12-g0b703db
$ powerpc-e500-linux-gnu-gcc --version powerpc-e500-linux-gnu-gcc (Gentoo 4.6.3-r1 p1.9, pie-0.5.2) 4.6.3
$ grep '_GOT2_TABLE_|_GLOBAL_OFFSET_TABLE_|__got2_entries'
u-boot.map
0x00000000effb5100 _GOT2_TABLE_ = . 0x00000000effb7d38 _GLOBAL_OFFSET_TABLE_ 0x00000000effb7d48 PROVIDE (_GLOBAL_OFFSET_TABLE_, (. +
0x4))
0x0000000000000b0d __got2_entries = (((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 0x2) - 0x1)
$ gdb-multiarch u-boot (gdb) disassemble /r 0xeffb5100,0xeffb7d48 Dump of assembler code from 0xeffb5100 to 0xeffb7d48: 0xeffb5100 <_GOT2_TABLE_+0>: ef fb 51 00 .long 0xeffb5100 0xeffb5104 <_GOT2_TABLE_+4>: ef fb 7d 44 dtstsf cr7,f27,f15 0xeffb5108 <_GOT2_TABLE_+8>: ef f4 00 00 .long 0xeff40000 0xeffb510c <_GOT2_TABLE_+12>: ef f4 01 00 .long
0xeff40100
<snip> 0xeffb7d30 <_GOT2_TABLE_+11312>: ef f6 6e 74 .long
0xeff66e74
0xeffb7d34 <_GOT2_TABLE_+11316>: f0 00 00 d0 psq_st
f0,208(r0),0,0
0xeffb7d38 <_GLOBAL_OFFSET_TABLE_+0>: 00 00 00 00 .long
0x0
0xeffb7d3c <_GLOBAL_OFFSET_TABLE_+4>: 00 00 00 00 .long
0x0
0xeffb7d40 <_GLOBAL_OFFSET_TABLE_+8>: 00 00 00 00 .long
0x0
0xeffb7d44 <_FIXUP_TABLE_+0>: ef fb 99 d4 .long
0xeffb99d4
So no there is no brlr at the end of the table.
There should be, see http://www.freescale.com/files/32bit/doc/ref_manual/E500ABIUG.pdf, chap 4.3.2
Also I think the __got2_entries calculation does not take into account the +0x4, ((0xeffb7d38-0xeffb5100)>>2)-1) = 0xb0d
Yes, there is something fishy here but I don't think it is the -1 that is the problem. It is the lack of brlr, I am not sure why this happens.
Jocke
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
When the got2 pointers were adjusted after relocation the last entry was missed. For most builds was something innocuous and there was no observable problem but at least for the P2041RDB board this ended up being NetArpWaitTimerStart which caused the ARP packets to timeout immediately.
On Mon, Sep 8, 2014 at 9:04 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
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,-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.
But __got2_entries is 1 less than it should be. Fix this by removing the -1 from the __got2_entries calculation.
Cc: Joakim Tjernlund joakim.tjernlund@transmode.se Signed-off-by: Chris Packham judge.packham@gmail.com --- So here's a patch that addresses the issue. I've tested it on a P2041RDB (mpc85xx/QorIq). I am aware that I'm touching a lot of platforms so I need some help testing.
I've deliberately left off the following board specific files which at a glance have the same off-by-one error:
board/LEOX/elpt860/u-boot.lds board/RRvision/u-boot.lds board/cogent/u-boot.lds board/eltec/mhpc/u-boot.lds board/emk/top860/u-boot.lds board/esteem192e/u-boot.lds board/evb64260/u-boot.lds board/hermes/u-boot.lds board/hymod/u-boot.lds board/icu862/u-boot.lds board/ip860/u-boot.lds board/ivm/u-boot.lds board/kup/kup4k/u-boot.lds board/kup/kup4x/u-boot.lds board/lwmon/u-boot.lds board/manroland/uc100/u-boot.lds board/matrix_vision/mvsmr/u-boot.lds board/mvblue/u-boot.lds board/netvia/u-boot.lds board/r360mpi/u-boot.lds board/sandpoint/u-boot.lds board/spd8xx/u-boot.lds board/tqc/tqm8xx/u-boot.lds
Thanks, Chris
arch/powerpc/cpu/74xx_7xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc512x/u-boot.lds | 2 +- arch/powerpc/cpu/mpc5xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc5xxx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc824x/u-boot.lds | 2 +- arch/powerpc/cpu/mpc8260/u-boot.lds | 2 +- arch/powerpc/cpu/mpc83xx/u-boot-spl.lds | 2 +- arch/powerpc/cpu/mpc83xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 2 +- arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds | 2 +- arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 2 +- arch/powerpc/cpu/mpc85xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc86xx/u-boot.lds | 2 +- arch/powerpc/cpu/ppc4xx/u-boot.lds | 2 +- 14 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/cpu/74xx_7xx/u-boot.lds b/arch/powerpc/cpu/74xx_7xx/u-boot.lds index c099849..2fd39c8 100644 --- a/arch/powerpc/cpu/74xx_7xx/u-boot.lds +++ b/arch/powerpc/cpu/74xx_7xx/u-boot.lds @@ -34,7 +34,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;
.data : diff --git a/arch/powerpc/cpu/mpc512x/u-boot.lds b/arch/powerpc/cpu/mpc512x/u-boot.lds index 9658b21..2ca492b 100644 --- a/arch/powerpc/cpu/mpc512x/u-boot.lds +++ b/arch/powerpc/cpu/mpc512x/u-boot.lds @@ -29,7 +29,7 @@ SECTIONS KEEP(*(.fixup)) *(.fixup) } - __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1; + __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2); __fixup_entries = (. - _FIXUP_TABLE_) >> 2;
.data : diff --git a/arch/powerpc/cpu/mpc5xx/u-boot.lds b/arch/powerpc/cpu/mpc5xx/u-boot.lds index 7198465..c8dbff8 100644 --- a/arch/powerpc/cpu/mpc5xx/u-boot.lds +++ b/arch/powerpc/cpu/mpc5xx/u-boot.lds @@ -37,7 +37,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;
.data : diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds b/arch/powerpc/cpu/mpc5xxx/u-boot.lds index cd9e23f..9f6288a 100644 --- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds +++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds @@ -32,7 +32,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;
.data : diff --git a/arch/powerpc/cpu/mpc824x/u-boot.lds b/arch/powerpc/cpu/mpc824x/u-boot.lds index 04aba84..b3ffbfc 100644 --- a/arch/powerpc/cpu/mpc824x/u-boot.lds +++ b/arch/powerpc/cpu/mpc824x/u-boot.lds @@ -32,7 +32,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;
.data : diff --git a/arch/powerpc/cpu/mpc8260/u-boot.lds b/arch/powerpc/cpu/mpc8260/u-boot.lds index 50cbf85..423f0ae 100644 --- a/arch/powerpc/cpu/mpc8260/u-boot.lds +++ b/arch/powerpc/cpu/mpc8260/u-boot.lds @@ -31,7 +31,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;
.data : diff --git a/arch/powerpc/cpu/mpc83xx/u-boot-spl.lds b/arch/powerpc/cpu/mpc83xx/u-boot-spl.lds index 774772b..9b513ed 100644 --- a/arch/powerpc/cpu/mpc83xx/u-boot-spl.lds +++ b/arch/powerpc/cpu/mpc83xx/u-boot-spl.lds @@ -26,7 +26,7 @@ SECTIONS KEEP(*(.got)) PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4); } - __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2) - 1; + __got2_entries = ((_GLOBAL_OFFSET_TABLE_ - _GOT2_TABLE_) >> 2);
. = ALIGN(8); __bss_start = .; diff --git a/arch/powerpc/cpu/mpc83xx/u-boot.lds b/arch/powerpc/cpu/mpc83xx/u-boot.lds index 3c177fa..7370a3d 100644 --- a/arch/powerpc/cpu/mpc83xx/u-boot.lds +++ b/arch/powerpc/cpu/mpc83xx/u-boot.lds @@ -30,7 +30,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;
.data : diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds b/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds index f933b21..9b69cf3 100644 --- a/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds +++ b/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds @@ -48,7 +48,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;
.data : diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds b/arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds index b83c553..215f254 100644 --- a/arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds +++ b/arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds @@ -26,7 +26,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;
. = ALIGN(8); diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds index 5ae7b3e..4b00bec 100644 --- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds +++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds @@ -33,7 +33,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;
. = ALIGN(8); 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;
.data : diff --git a/arch/powerpc/cpu/mpc86xx/u-boot.lds b/arch/powerpc/cpu/mpc86xx/u-boot.lds index 58467c2..f6f52e3 100644 --- a/arch/powerpc/cpu/mpc86xx/u-boot.lds +++ b/arch/powerpc/cpu/mpc86xx/u-boot.lds @@ -36,7 +36,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;
.data : diff --git a/arch/powerpc/cpu/ppc4xx/u-boot.lds b/arch/powerpc/cpu/ppc4xx/u-boot.lds index 8773178..22a5ec4 100644 --- a/arch/powerpc/cpu/ppc4xx/u-boot.lds +++ b/arch/powerpc/cpu/ppc4xx/u-boot.lds @@ -50,7 +50,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;
.data :
Hi All,
On Tue, Sep 9, 2014 at 12:22 PM, Chris Packham judge.packham@gmail.com wrote:
When the got2 pointers were adjusted after relocation the last entry was missed. For most builds was something innocuous and there was no observable problem but at least for the P2041RDB board this ended up being NetArpWaitTimerStart which caused the ARP packets to timeout immediately.
On Mon, Sep 8, 2014 at 9:04 PM, Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
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,-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.
But __got2_entries is 1 less than it should be. Fix this by removing the -1 from the __got2_entries calculation.
Cc: Joakim Tjernlund joakim.tjernlund@transmode.se Signed-off-by: Chris Packham judge.packham@gmail.com
So here's a patch that addresses the issue. I've tested it on a P2041RDB (mpc85xx/QorIq). I am aware that I'm touching a lot of platforms so I need some help testing.
I've deliberately left off the following board specific files which at a glance have the same off-by-one error:
Sorry for the noise but Jocke has pointed me in the direction of a better fix. I'll submit that as a new patch. This one can be abandoned.
Dear Chris,
In message CAFOYHZASBbTctq4fRJNX2e8=r_ocWosODnQ5R80wGa1GFzGyqg@mail.gmail.com you wrote:
...
Which yields the following output
NetArpWaitTimerStart = 0 &NetArpWaitTimerStart = f00000d0 NetArpWaitTry = 1 &NetArpWaitTry = 7ffb0058 NetArpWaitTxPacketSize = 42 &NetArpWaitTxPacketSize = 7ffb0078
--------------------------------^^^^^^^^
This also looks fishy!
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);
Well, in your list above the _two_ entries at the end are wrong, so adding _one_ entry here is probably wrong, too.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Tue, Sep 9, 2014 at 8:21 AM, Wolfgang Denk wd@denx.de wrote:
Dear Chris,
In message CAFOYHZASBbTctq4fRJNX2e8=r_ocWosODnQ5R80wGa1GFzGyqg@mail.gmail.com you wrote:
...
Which yields the following output
NetArpWaitTimerStart = 0 &NetArpWaitTimerStart = f00000d0 NetArpWaitTry = 1 &NetArpWaitTry = 7ffb0058 NetArpWaitTxPacketSize = 42 &NetArpWaitTxPacketSize = 7ffb0078
--------------------------------^^^^^^^^
This also looks fishy!
Do you mean the address or the value? FYI the 77fb0000 addresses are what I believe to be the correct relocated address. It's the f00000d0 address for NetArpWaitTimerStart that I believe is causing the problem I am seeing.
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);
Well, in your list above the _two_ entries at the end are wrong, so adding _one_ entry here is probably wrong, too.
I think there's only one entry that is wrong.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de You can only live once, but if you do it right, once is enough.
Dear Chris,
In message CAFOYHZCtPSJRvL8asB9O6dUPtNHZSE_gUd=N8+6HYqsnyhDneg@mail.gmail.com you wrote:
Do you mean the address or the value? FYI the 77fb0000 addresses are what I believe to be the correct relocated address. It's the f00000d0 address for NetArpWaitTimerStart that I believe is causing the problem I am seeing.
Of course you are right. Silly me.
Best regards,
Wolfgang Denk
participants (3)
-
Chris Packham -
Joakim Tjernlund -
Wolfgang Denk