* [U-Boot] relocation problem on powerpc @ 2014-09-08 4:32 Chris Packham 2014-09-08 5:18 ` Chris Packham 2014-09-08 5:51 ` Chris Packham 0 siblings, 2 replies; 21+ messages in thread From: Chris Packham @ 2014-09-08 4:32 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 4:32 [U-Boot] relocation problem on powerpc Chris Packham @ 2014-09-08 5:18 ` Chris Packham 2014-09-08 5:51 ` Chris Packham 1 sibling, 0 replies; 21+ messages in thread From: Chris Packham @ 2014-09-08 5:18 UTC (permalink / raw) To: u-boot 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 4:32 [U-Boot] relocation problem on powerpc Chris Packham 2014-09-08 5:18 ` Chris Packham @ 2014-09-08 5:51 ` Chris Packham 2014-09-08 9:04 ` Joakim Tjernlund 2014-09-08 20:21 ` [U-Boot] relocation problem on powerpc Wolfgang Denk 1 sibling, 2 replies; 21+ messages in thread From: Chris Packham @ 2014-09-08 5:51 UTC (permalink / raw) To: u-boot 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 : ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 5:51 ` Chris Packham @ 2014-09-08 9:04 ` Joakim Tjernlund 2014-09-08 12:22 ` Joakim Tjernlund 2014-09-08 22:07 ` [U-Boot] relocation problem on powerpc Chris Packham 2014-09-08 20:21 ` [U-Boot] relocation problem on powerpc Wolfgang Denk 1 sibling, 2 replies; 21+ messages in thread From: Joakim Tjernlund @ 2014-09-08 9:04 UTC (permalink / raw) To: u-boot > > 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 at 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 9:04 ` Joakim Tjernlund @ 2014-09-08 12:22 ` Joakim Tjernlund 2014-09-08 23:07 ` Chris Packham 2014-09-08 22:07 ` [U-Boot] relocation problem on powerpc Chris Packham 1 sibling, 1 reply; 21+ messages in thread From: Joakim Tjernlund @ 2014-09-08 12:22 UTC (permalink / raw) To: u-boot > > > > > 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 at 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. 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 12:22 ` Joakim Tjernlund @ 2014-09-08 23:07 ` Chris Packham 2014-09-09 9:05 ` Joakim Tjernlund [not found] ` <OF3B16B156.FBE577FB-ONC1257D4E.002B79D7-C1257D4E.0031F02B@LocalDomain> 0 siblings, 2 replies; 21+ messages in thread From: Chris Packham @ 2014-09-08 23:07 UTC (permalink / raw) To: u-boot 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 > <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 at 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. > > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 23:07 ` Chris Packham @ 2014-09-09 9:05 ` Joakim Tjernlund [not found] ` <OF3B16B156.FBE577FB-ONC1257D4E.002B79D7-C1257D4E.0031F02B@LocalDomain> 1 sibling, 0 replies; 21+ messages in thread From: Joakim Tjernlund @ 2014-09-09 9:05 UTC (permalink / raw) To: u-boot 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 > > <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 at 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. > > > > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <OF3B16B156.FBE577FB-ONC1257D4E.002B79D7-C1257D4E.0031F02B@LocalDomain>]
* [U-Boot] relocation problem on powerpc [not found] ` <OF3B16B156.FBE577FB-ONC1257D4E.002B79D7-C1257D4E.0031F02B@LocalDomain> @ 2014-09-09 12:30 ` Joakim Tjernlund [not found] ` <OF76BFAD6D.627B6C04-ONC1257D4E.00438406-C1257D4E.0044AF3E@LocalDomain> 1 sibling, 0 replies; 21+ messages in thread From: Joakim Tjernlund @ 2014-09-09 12:30 UTC (permalink / raw) To: u-boot > > 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 So I did a quick test too with my copy of u-boot: (gdb) disass /r 0x00000000effa0a48,0x00000000effa0a68 Dump of assembler code from 0xeffa0a48 to 0xeffa0a68: 0xeffa0a48 <_GOT2_TABLE_+9800>: f0 00 00 dc .long 0xf00000dc 0xeffa0a4c <_GOT2_TABLE_+9804>: ef f6 29 48 .long 0xeff62948 0xeffa0a50 <_GOT2_TABLE_+9808>: f0 00 00 e0 .long 0xf00000e0 0xeffa0a54 <_GOT2_TABLE_+9812>: 4e 80 00 21 blrl ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xeffa0a58 <_GLOBAL_OFFSET_TABLE_+0>: 00 00 00 00 .long 0x0 0xeffa0a5c <_GLOBAL_OFFSET_TABLE_+4>: 00 00 00 00 .long 0x0 0xeffa0a60 <_GLOBAL_OFFSET_TABLE_+8>: 00 00 00 00 .long 0x0 0xeffa0a64 <_FIXUP_TABLE_+0>: ef fa 23 1c .long 0xeffa231c $ powerpc-softfloat_4.5.3-linux-gnu-ld --version GNU ld (GNU Binutils) 2.21.1 I don't know it this is tool(ld) problem or if something in u-boot's build env. Try dropping --gc-sections, see if that changes anything, or add --bss-plt or similar ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <OF76BFAD6D.627B6C04-ONC1257D4E.00438406-C1257D4E.0044AF3E@LocalDomain>]
* [U-Boot] relocation problem on powerpc [not found] ` <OF76BFAD6D.627B6C04-ONC1257D4E.00438406-C1257D4E.0044AF3E@LocalDomain> @ 2014-09-09 13:20 ` Joakim Tjernlund 2014-09-10 3:48 ` Chris Packham 0 siblings, 1 reply; 21+ messages in thread From: Joakim Tjernlund @ 2014-09-09 13:20 UTC (permalink / raw) To: u-boot Joakim Tjernlund/Transmode wrote on 2014/09/09 14:30:13: > From: Joakim Tjernlund/Transmode > To: > Cc: Chris Packham <judge.packham@gmail.com>, u-boot <u-boot@lists.denx.de> > Date: 2014/09/09 14:30 > Subject: Re: [U-Boot] relocation problem on powerpc > > > > > 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 > > So I did a quick test too with my copy of u-boot: > (gdb) disass /r 0x00000000effa0a48,0x00000000effa0a68 > Dump of assembler code from 0xeffa0a48 to 0xeffa0a68: > 0xeffa0a48 <_GOT2_TABLE_+9800>: f0 00 00 dc .long 0xf00000dc > 0xeffa0a4c <_GOT2_TABLE_+9804>: ef f6 29 48 .long 0xeff62948 > 0xeffa0a50 <_GOT2_TABLE_+9808>: f0 00 00 e0 .long 0xf00000e0 > 0xeffa0a54 <_GOT2_TABLE_+9812>: 4e 80 00 21 blrl > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 0xeffa0a58 <_GLOBAL_OFFSET_TABLE_+0>: 00 00 00 00 .long 0x0 > 0xeffa0a5c <_GLOBAL_OFFSET_TABLE_+4>: 00 00 00 00 .long 0x0 > 0xeffa0a60 <_GLOBAL_OFFSET_TABLE_+8>: 00 00 00 00 .long 0x0 > 0xeffa0a64 <_FIXUP_TABLE_+0>: ef fa 23 1c .long 0xeffa231c > $ powerpc-softfloat_4.5.3-linux-gnu-ld --version > GNU ld (GNU Binutils) 2.21.1 > > I don't know it this is tool(ld) problem or if something in u-boot's build env. Try dropping > --gc-sections, see if that changes anything, or add --bss-plt or similar --bss-plt seems to be the answer: http://lists.denx.de/pipermail/u-boot/2014-February/173134.html Jocke ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-09 13:20 ` Joakim Tjernlund @ 2014-09-10 3:48 ` Chris Packham 2014-09-10 4:03 ` [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS Chris Packham 0 siblings, 1 reply; 21+ messages in thread From: Chris Packham @ 2014-09-10 3:48 UTC (permalink / raw) To: u-boot Hi Jocke On Wed, Sep 10, 2014 at 1:20 AM, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote: > Joakim Tjernlund/Transmode wrote on 2014/09/09 14:30:13: > >> From: Joakim Tjernlund/Transmode >> To: >> Cc: Chris Packham <judge.packham@gmail.com>, u-boot > <u-boot@lists.denx.de> >> Date: 2014/09/09 14:30 >> Subject: Re: [U-Boot] relocation problem on powerpc >> >> >> > > 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 Yep that's pretty unambiguous "The word at _GLOBAL_OFFSET_TABLE_[-1] shall contain a blrl instruction". No "should", "may" or "can" in sight. >> >> So I did a quick test too with my copy of u-boot: >> (gdb) disass /r 0x00000000effa0a48,0x00000000effa0a68 >> Dump of assembler code from 0xeffa0a48 to 0xeffa0a68: >> 0xeffa0a48 <_GOT2_TABLE_+9800>: f0 00 00 dc .long 0xf00000dc >> 0xeffa0a4c <_GOT2_TABLE_+9804>: ef f6 29 48 .long 0xeff62948 >> 0xeffa0a50 <_GOT2_TABLE_+9808>: f0 00 00 e0 .long 0xf00000e0 >> 0xeffa0a54 <_GOT2_TABLE_+9812>: 4e 80 00 21 blrl >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> 0xeffa0a58 <_GLOBAL_OFFSET_TABLE_+0>: 00 00 00 00 .long 0x0 >> 0xeffa0a5c <_GLOBAL_OFFSET_TABLE_+4>: 00 00 00 00 .long 0x0 >> 0xeffa0a60 <_GLOBAL_OFFSET_TABLE_+8>: 00 00 00 00 .long 0x0 >> 0xeffa0a64 <_FIXUP_TABLE_+0>: ef fa 23 1c .long 0xeffa231c > >> $ powerpc-softfloat_4.5.3-linux-gnu-ld --version >> GNU ld (GNU Binutils) 2.21.1 >> >> I don't know it this is tool(ld) problem or if something in u-boot's > build env. Try dropping >> --gc-sections, see if that changes anything, or add --bss-plt or similar > > --bss-plt seems to be the answer: > http://lists.denx.de/pipermail/u-boot/2014-February/173134.html > > Jocke > Same question as that original thread '--bss-plt' or '-mbss-plt'? The former works (I'll send a patch through) but I can only find documentation for the latter. ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS 2014-09-10 3:48 ` Chris Packham @ 2014-09-10 4:03 ` Chris Packham 2014-09-10 10:47 ` Joakim Tjernlund ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Chris Packham @ 2014-09-10 4:03 UTC (permalink / raw) To: u-boot With some versions of gcc (that we know of 4.6.3 and 4.8.2 are affected) it is necessary to specify --bss-plt to get the final blrl in the _GOT2_TABLE_. Without this the last symbol does not get it's address relocated. For the P2041RDB board this ended up being NetArpWaitTimerStart which caused the ARP packets to timeout immediately. Helped-by: Joakim Tjernlund <joakim.tjernlund@transmode.se> Signed-off-by: Chris Packham <judge.packham@gmail.com> --- Technically this is v2 of http://lists.denx.de/pipermail/u-boot/2014-September/188365.html but the solution is so different that I'm treating it as a new patch series. arch/powerpc/config.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk index 6329b6c..fec02f2 100644 --- a/arch/powerpc/config.mk +++ b/arch/powerpc/config.mk @@ -11,6 +11,7 @@ endif CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000 LDFLAGS_FINAL += --gc-sections +LDFLAGS_FINAL += --bss-plt PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections -fdata-sections \ -meabi PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS 2014-09-10 4:03 ` [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS Chris Packham @ 2014-09-10 10:47 ` Joakim Tjernlund 2014-09-24 22:14 ` York Sun 2014-09-25 16:49 ` York Sun 2 siblings, 0 replies; 21+ messages in thread From: Joakim Tjernlund @ 2014-09-10 10:47 UTC (permalink / raw) To: u-boot Chris Packham <judge.packham@gmail.com> wrote on 2014/09/10 06:03:10: > > With some versions of gcc (that we know of 4.6.3 and 4.8.2 are affected) > it is necessary to specify --bss-plt to get the final blrl in the > _GOT2_TABLE_. Without this the last symbol does not get it's address > relocated. For the P2041RDB board this ended up being > NetArpWaitTimerStart which caused the ARP packets to timeout > immediately. > > Helped-by: Joakim Tjernlund <joakim.tjernlund@transmode.se> > Signed-off-by: Chris Packham <judge.packham@gmail.com> The commit text is a bit misleading, it is binutils(ld) which has changed default so now one have to specify --bss-plt to get what u-boot needs. Works fine with binutils 2.21.1 Acked-by: Joakim Tjernlund <joakim.tjernlund@transmode.se> One could possibly argue that --secure-plt should have a NULL word there like the other 3 reserved words around _GLOBAL_OFFSET_TABLE_ to preserve compatibility. PS. -mbss-plt is the gcc option while --bss-plt is the ld option. u-boot invokes ld directly so --bss-plt is appropriate > --- > Technically this is v2 of > http://lists.denx.de/pipermail/u-boot/2014-September/188365.html but the > solution is so different that I'm treating it as a new patch series. > > arch/powerpc/config.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk > index 6329b6c..fec02f2 100644 > --- a/arch/powerpc/config.mk > +++ b/arch/powerpc/config.mk > @@ -11,6 +11,7 @@ endif > > CONFIG_STANDALONE_LOAD_ADDR ?= 0x40000 > LDFLAGS_FINAL += --gc-sections > +LDFLAGS_FINAL += --bss-plt > PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections -fdata-sections \ > -meabi > PLATFORM_CPPFLAGS += -D__powerpc__ -ffixed-r2 > -- > 1.7.9.5 > ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS 2014-09-10 4:03 ` [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS Chris Packham 2014-09-10 10:47 ` Joakim Tjernlund @ 2014-09-24 22:14 ` York Sun 2014-09-25 7:26 ` Joakim Tjernlund 2014-09-25 16:49 ` York Sun 2 siblings, 1 reply; 21+ messages in thread From: York Sun @ 2014-09-24 22:14 UTC (permalink / raw) To: u-boot On 09/09/2014 09:03 PM, Chris Packham wrote: > With some versions of gcc (that we know of 4.6.3 and 4.8.2 are affected) > it is necessary to specify --bss-plt to get the final blrl in the > _GOT2_TABLE_. Without this the last symbol does not get it's address > relocated. For the P2041RDB board this ended up being > NetArpWaitTimerStart which caused the ARP packets to timeout > immediately. > > Helped-by: Joakim Tjernlund <joakim.tjernlund@transmode.se> > Signed-off-by: Chris Packham <judge.packham@gmail.com> > --- Dear Wolfgang, I am trying to apply this patch. Shall I drop the "Helped-by:" line. I understand Chris is giving credit to Joakim. But "Helped-by:" is not a standard signature. York ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS 2014-09-24 22:14 ` York Sun @ 2014-09-25 7:26 ` Joakim Tjernlund 0 siblings, 0 replies; 21+ messages in thread From: Joakim Tjernlund @ 2014-09-25 7:26 UTC (permalink / raw) To: u-boot > > On 09/09/2014 09:03 PM, Chris Packham wrote: > > With some versions of gcc (that we know of 4.6.3 and 4.8.2 are affected) > > it is necessary to specify --bss-plt to get the final blrl in the > > _GOT2_TABLE_. Without this the last symbol does not get it's address > > relocated. For the P2041RDB board this ended up being > > NetArpWaitTimerStart which caused the ARP packets to timeout > > immediately. > > > > Helped-by: Joakim Tjernlund <joakim.tjernlund@transmode.se> > > Signed-off-by: Chris Packham <judge.packham@gmail.com> > > --- > > Dear Wolfgang, > > I am trying to apply this patch. Shall I drop the "Helped-by:" line. I > understand Chris is giving credit to Joakim. But "Helped-by:" is not a standard > signature. I am happy with Acked-by or Sign-off-by, you choose. Jocke ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS 2014-09-10 4:03 ` [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS Chris Packham 2014-09-10 10:47 ` Joakim Tjernlund 2014-09-24 22:14 ` York Sun @ 2014-09-25 16:49 ` York Sun 2 siblings, 0 replies; 21+ messages in thread From: York Sun @ 2014-09-25 16:49 UTC (permalink / raw) To: u-boot On 09/09/2014 09:03 PM, Chris Packham wrote: > With some versions of gcc (that we know of 4.6.3 and 4.8.2 are affected) > it is necessary to specify --bss-plt to get the final blrl in the > _GOT2_TABLE_. Without this the last symbol does not get it's address > relocated. For the P2041RDB board this ended up being > NetArpWaitTimerStart which caused the ARP packets to timeout > immediately. > > Helped-by: Joakim Tjernlund <joakim.tjernlund@transmode.se> > Signed-off-by: Chris Packham <judge.packham@gmail.com> > --- Applied to u-boot-mpc85xx, awaiting upstream. York ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 9:04 ` Joakim Tjernlund 2014-09-08 12:22 ` Joakim Tjernlund @ 2014-09-08 22:07 ` Chris Packham 2014-09-09 0:22 ` [U-Boot] [RFC PATCH v1] powerpc: Fix off-by-one error in relocation Chris Packham 1 sibling, 1 reply; 21+ messages in thread From: Chris Packham @ 2014-09-08 22:07 UTC (permalink / raw) To: u-boot 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 at 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 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] [RFC PATCH v1] powerpc: Fix off-by-one error in relocation 2014-09-08 22:07 ` [U-Boot] relocation problem on powerpc Chris Packham @ 2014-09-09 0:22 ` Chris Packham 2014-09-10 3:54 ` Chris Packham 0 siblings, 1 reply; 21+ messages in thread From: Chris Packham @ 2014-09-09 0:22 UTC (permalink / raw) To: u-boot 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 at 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. 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 : -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [U-Boot] [RFC PATCH v1] powerpc: Fix off-by-one error in relocation 2014-09-09 0:22 ` [U-Boot] [RFC PATCH v1] powerpc: Fix off-by-one error in relocation Chris Packham @ 2014-09-10 3:54 ` Chris Packham 0 siblings, 0 replies; 21+ messages in thread From: Chris Packham @ 2014-09-10 3:54 UTC (permalink / raw) To: u-boot 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 at 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. > > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 5:51 ` Chris Packham 2014-09-08 9:04 ` Joakim Tjernlund @ 2014-09-08 20:21 ` Wolfgang Denk 2014-09-08 22:10 ` Chris Packham 1 sibling, 1 reply; 21+ messages in thread From: Wolfgang Denk @ 2014-09-08 20:21 UTC (permalink / raw) To: u-boot 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 -- 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 at denx.de You can only live once, but if you do it right, once is enough. ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 20:21 ` [U-Boot] relocation problem on powerpc Wolfgang Denk @ 2014-09-08 22:10 ` Chris Packham 2014-09-09 6:37 ` Wolfgang Denk 0 siblings, 1 reply; 21+ messages in thread From: Chris Packham @ 2014-09-08 22:10 UTC (permalink / raw) To: u-boot 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 at denx.de > You can only live once, but if you do it right, once is enough. ^ permalink raw reply [flat|nested] 21+ messages in thread
* [U-Boot] relocation problem on powerpc 2014-09-08 22:10 ` Chris Packham @ 2014-09-09 6:37 ` Wolfgang Denk 0 siblings, 0 replies; 21+ messages in thread From: Wolfgang Denk @ 2014-09-09 6:37 UTC (permalink / raw) To: u-boot 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 -- 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 at denx.de Hindsight is an exact science. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2014-09-25 16:49 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-08 4:32 [U-Boot] relocation problem on powerpc Chris Packham 2014-09-08 5:18 ` Chris Packham 2014-09-08 5:51 ` Chris Packham 2014-09-08 9:04 ` Joakim Tjernlund 2014-09-08 12:22 ` Joakim Tjernlund 2014-09-08 23:07 ` Chris Packham 2014-09-09 9:05 ` Joakim Tjernlund [not found] ` <OF3B16B156.FBE577FB-ONC1257D4E.002B79D7-C1257D4E.0031F02B@LocalDomain> 2014-09-09 12:30 ` Joakim Tjernlund [not found] ` <OF76BFAD6D.627B6C04-ONC1257D4E.00438406-C1257D4E.0044AF3E@LocalDomain> 2014-09-09 13:20 ` Joakim Tjernlund 2014-09-10 3:48 ` Chris Packham 2014-09-10 4:03 ` [U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS Chris Packham 2014-09-10 10:47 ` Joakim Tjernlund 2014-09-24 22:14 ` York Sun 2014-09-25 7:26 ` Joakim Tjernlund 2014-09-25 16:49 ` York Sun 2014-09-08 22:07 ` [U-Boot] relocation problem on powerpc Chris Packham 2014-09-09 0:22 ` [U-Boot] [RFC PATCH v1] powerpc: Fix off-by-one error in relocation Chris Packham 2014-09-10 3:54 ` Chris Packham 2014-09-08 20:21 ` [U-Boot] relocation problem on powerpc Wolfgang Denk 2014-09-08 22:10 ` Chris Packham 2014-09-09 6:37 ` Wolfgang Denk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.