[U-Boot] relocation problem on powerpc

[U-Boot] relocation problem on powerpc

[Chris Packham]

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

[U-Boot] relocation problem on powerpc

[Chris Packham]

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?

[U-Boot] relocation problem on powerpc

[Chris Packham]

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    :

[U-Boot] relocation problem on powerpc

[Joakim Tjernlund]

> 
> 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

[U-Boot] relocation problem on powerpc

[Joakim Tjernlund]

> 
> > 
> > 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

[U-Boot] relocation problem on powerpc

[Wolfgang Denk]

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.

[U-Boot] relocation problem on powerpc

[Chris Packham]

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

[U-Boot] relocation problem on powerpc

[Chris Packham]

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.

[U-Boot] relocation problem on powerpc

[Chris Packham]

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

[U-Boot] [RFC PATCH v1] powerpc: Fix off-by-one error in relocation

[Chris Packham]

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

[U-Boot] relocation problem on powerpc

[Wolfgang Denk]

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.

[U-Boot] relocation problem on powerpc

[Joakim Tjernlund]

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

[U-Boot] relocation problem on powerpc

[Joakim Tjernlund]

> > 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

[U-Boot] relocation problem on powerpc

[Joakim Tjernlund]

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

[U-Boot] relocation problem on powerpc

[Chris Packham]

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.

[U-Boot] [RFC PATCH v1] powerpc: Fix off-by-one error in relocation

[Chris Packham]

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.

[U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS

[Chris Packham]

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

[U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS

[Joakim Tjernlund]

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
> 

[U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS

[York Sun]

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

[U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS

[Joakim Tjernlund]

> 
> 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

[U-Boot] [RFC PATCH v1] powerpc: add --bss-plt to LDFLAGS

[York Sun]

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