From: Joakim Tjernlund <joakim.tjernlund@transmode.se>
To: u-boot@lists.denx.de
Subject: [U-Boot] relocation problem on powerpc
Date: Tue, 9 Sep 2014 11:05:27 +0200 [thread overview]
Message-ID: <OF3B16B156.FBE577FB-ONC1257D4E.002B79D7-C1257D4E.0031F04C@transmode.se> (raw)
In-Reply-To: <CAFOYHZCJbx4FTOZLr90z6PjuepZyfS0h2X1Rc_z8+TJ+_+0DBg@mail.gmail.com>
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
next prev parent reply other threads:[~2014-09-09 9:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
[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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OF3B16B156.FBE577FB-ONC1257D4E.002B79D7-C1257D4E.0031F04C@transmode.se \
--to=joakim.tjernlund@transmode.se \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.