back at it, some question regarding PowerPC / ELF

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

back at it, some question regarding PowerPC / ELF

Peter J. Philipp-3
Hi all,

I'm back at looking why my powerpc64 work didn't work out, and I think I made
some progress (I think).  For one I determined that there was no problem
jumping to compiled code from the asm, which I thought before was a problem.

I compiled the kernel with gcc crosscompiler in the old aimee vm that I had
set up, I feel more comfortable with this, but I don't know why exactly.
aimee now runs on my MBP in vmware, that's another change I did.  This way
I can poke at it on weekends.  The OS is still 6.4-current from last year.

Instead of using my G5 I'm using qemu with its built-in monitor to debug
the registers, this works faster and quieter IMO, I'm using the
floating-point registers as an indicator how far I got in the code (instruction
I use is (lis %21, 1; lfsux %fX, %r21, %r21;  <-- I know life sucks, the
console is not initialized at this point so I can't printf).  And right now
I'm still on ofwreal.S, which anyone would agree with me is hard ASM
code.  I started last week not knowing a lot about PowerPC asm, I try though.

I reworked ofwreal.S in that I pulled out the macppc version and had it run
through, and it worked and got me further into pmap.c in execution but the
openfirmware stuff was so mangled it couldn't even figure out how much
physmem it had, big stopper there.  So I went back to redo ofwreal.S, it
dawned on me yesterday that fwcall is supposed to be .long size as it's an
instruction holder.  I made a little progress from then on but am stuck on
a big thing (I think).

When I executed the bsd kernel, last,  it gets stuck trying to store to some
location offset from register 2 (a book I recently got says this is the TOC
pointer, an ELF thing).  And here is my question about this TOC (table of
contents), how would I best define an area for it?  Or how is this done?  As
far as the FreeBSD code is concerned they set up a __tocbase area at
locore64.S but then they do relocations, which I am unable to do in the short
term.  I'M pretty much confused by now.   I'll show you where in the qemu
emulator the execution flow stops:

00000000001b7a2c <OF_finddevice>:
  1b7a2c:       3c 40 00 84     lis     r2,132
  1b7a30:       38 42 73 00     addi    r2,r2,29440
  1b7a34:       7c 08 02 a6     mflr    r0
  1b7a38:       fb e1 ff f8     std     r31,-8(r1)
  1b7a3c:       7c 7f 1b 78     mr      r31,r3
  1b7a40:       f8 01 00 10     std     r0,16(r1)
  1b7a44:       f8 21 ff d1     stdu    r1,-48(r1)
  1b7a48:       48 34 25 59     bl      4f9fa0 <ofw_stack>
  1b7a4c:       60 00 00 00     nop
  1b7a50:       60 00 00 00     nop
  1b7a54:       60 00 00 00     nop
  1b7a58:       38 62 fd 60     addi    r3,r2,-672
  1b7a5c:       fb e2 fd 70     std     r31,-656(r2) <---- here
  1b7a60:       48 34 25 11     bl      4f9f70 <openfirmware>
  1b7a64:       60 00 00 00     nop
  1b7a68:       2f 83 ff ff     cmpwi   cr7,r3,-1
  1b7a6c:       41 9e 00 0c     beq-    cr7,1b7a78 <OF_finddevice+0x4c>
  1b7a70:       60 00 00 00     nop
  1b7a74:       e8 62 fd 7a     lwa     r3,-648(r2)
  1b7a78:       38 21 00 30     addi    r1,r1,48


I think I got ofw_stack right (but not sure) at least it went through it.
But now it tries to access register r2 which is not defined in this.  Here
is a register dump:

---->
(qemu) info registers                  
NIP 00000000fff096bc   LR 00000000fff096bc CTR 00000000fff0e7e4 XER 000000000000
0000 CPU#0
MSR 0000000000001000 HID0 0000000060000000  HF 0000000000000000 iidx 3 didx 3
TB 00000000 2549640032 DECR 1745327192
GPR00 00000000fff096bc 0000000000000ff0 0000000000000000 0000000000000029 <- r2
GPR04 0000000000000003 0000000000000000 0000000000000034 0000000000000020
GPR08 0000000000000000 0000000000000000 0000000000000001 0000000000000ff0
GPR12 0000000048800402 00000000fffbcce0 0000000000000000 0000000000030000
GPR16 0000000000000001 0000000000030000 0000000000000000 0000000000030000
GPR20 0000000000003030 0000000000000002 0000000000031f1f 00000000fffbcf08
GPR24 0000000000035be0 0000000000031f68 00000000000351e0 00000000fffbcd0f
GPR28 000000000000002f 0000000000100a50 00000000fffbcce0 00000000ffddabe0
CR 28800402  [ E  L  L  -  -  G  -  E  ]             RES ffffffffffffffff
FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 37e00a5000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 3b83000200000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR 0000000000000000
 SRR0 00000000001b7a5c  SRR1 8000000000003030    PVR 00000000003c0301 VRSAVE 000
0000000000000
SPRG0 000000007fe00000 SPRG1 00000000fffffc70  SPRG2 0000000044482004  SPRG3 000
0000000000000
SPRG4 0000000000000000 SPRG5 0000000000000000  SPRG6 0000000000000000  SPRG7 000
0000000000000
 SDR1 000000007fe00000   DAR fffffffffffffd70  DSISR 0000000042000000
(qemu) quit        
<-------

SRR0 shows the address I dumped above in the objdump, SRR1 shows the MSR at the
time of execution (I think).

Now, I'm poking away at this thing, I can't say it will ever boot and I see
the pretty OpenBSD dmesg before a panic, but I'm drawn back at this work and
it's 6 months later from when I left it off.  I think using qemu is a good
decision as it's faster, uses less power until the work can be put on the
real machine.

I'm looking for guidance I think.

As a tid-bit I would say take a look at ofwreal.S in maccpc  I'll dump you the
code snippet (in function ofw_stack):

--->
        addi    %r3,%r1,%r8
        addi    %r1,%r4,-16
        subi    %r5,%r5,%r8
        subi    %r4,%r4,%r8
<----

I think that's wrong, register 8 is mtmsr'ed at the top of that and not
modified.  What has register 4 and 5 have to do with MSR?  Shouldn't this
mean just 8 and not %r8?

This is also an area I struggled with in 64-bit mode.

Best regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: back at it, some question regarding PowerPC / ELF

Karel Gardas

Peter,

seeing you writing about openfirmware, pmap.c etc. Have you investigated
NetBSD's PS3 files? Tsubai Masanari was kind to my ask and made them
available again on http://nandra.segv.jp/NetBSD/ps3/

Certainly some low level files like atomic.S, setjmp.S, pmap.c are there
and may be at least interesting for reading if not for direct inclusion.

Cheers,
Karel

On 5/9/19 8:25 AM, Peter J. Philipp wrote:

> Hi all,
>
> I'm back at looking why my powerpc64 work didn't work out, and I think I made
> some progress (I think).  For one I determined that there was no problem
> jumping to compiled code from the asm, which I thought before was a problem.
>
> I compiled the kernel with gcc crosscompiler in the old aimee vm that I had
> set up, I feel more comfortable with this, but I don't know why exactly.
> aimee now runs on my MBP in vmware, that's another change I did.  This way
> I can poke at it on weekends.  The OS is still 6.4-current from last year.
>
> Instead of using my G5 I'm using qemu with its built-in monitor to debug
> the registers, this works faster and quieter IMO, I'm using the
> floating-point registers as an indicator how far I got in the code (instruction
> I use is (lis %21, 1; lfsux %fX, %r21, %r21;  <-- I know life sucks, the
> console is not initialized at this point so I can't printf).  And right now
> I'm still on ofwreal.S, which anyone would agree with me is hard ASM
> code.  I started last week not knowing a lot about PowerPC asm, I try though.
>
> I reworked ofwreal.S in that I pulled out the macppc version and had it run
> through, and it worked and got me further into pmap.c in execution but the
> openfirmware stuff was so mangled it couldn't even figure out how much
> physmem it had, big stopper there.  So I went back to redo ofwreal.S, it
> dawned on me yesterday that fwcall is supposed to be .long size as it's an
> instruction holder.  I made a little progress from then on but am stuck on
> a big thing (I think).
>
> When I executed the bsd kernel, last,  it gets stuck trying to store to some
> location offset from register 2 (a book I recently got says this is the TOC
> pointer, an ELF thing).  And here is my question about this TOC (table of
> contents), how would I best define an area for it?  Or how is this done?  As
> far as the FreeBSD code is concerned they set up a __tocbase area at
> locore64.S but then they do relocations, which I am unable to do in the short
> term.  I'M pretty much confused by now.   I'll show you where in the qemu
> emulator the execution flow stops:
>
> 00000000001b7a2c <OF_finddevice>:
>    1b7a2c:       3c 40 00 84     lis     r2,132
>    1b7a30:       38 42 73 00     addi    r2,r2,29440
>    1b7a34:       7c 08 02 a6     mflr    r0
>    1b7a38:       fb e1 ff f8     std     r31,-8(r1)
>    1b7a3c:       7c 7f 1b 78     mr      r31,r3
>    1b7a40:       f8 01 00 10     std     r0,16(r1)
>    1b7a44:       f8 21 ff d1     stdu    r1,-48(r1)
>    1b7a48:       48 34 25 59     bl      4f9fa0 <ofw_stack>
>    1b7a4c:       60 00 00 00     nop
>    1b7a50:       60 00 00 00     nop
>    1b7a54:       60 00 00 00     nop
>    1b7a58:       38 62 fd 60     addi    r3,r2,-672
>    1b7a5c:       fb e2 fd 70     std     r31,-656(r2) <---- here
>    1b7a60:       48 34 25 11     bl      4f9f70 <openfirmware>
>    1b7a64:       60 00 00 00     nop
>    1b7a68:       2f 83 ff ff     cmpwi   cr7,r3,-1
>    1b7a6c:       41 9e 00 0c     beq-    cr7,1b7a78 <OF_finddevice+0x4c>
>    1b7a70:       60 00 00 00     nop
>    1b7a74:       e8 62 fd 7a     lwa     r3,-648(r2)
>    1b7a78:       38 21 00 30     addi    r1,r1,48
>
>
> I think I got ofw_stack right (but not sure) at least it went through it.
> But now it tries to access register r2 which is not defined in this.  Here
> is a register dump:
>
> ---->
> (qemu) info registers
> NIP 00000000fff096bc   LR 00000000fff096bc CTR 00000000fff0e7e4 XER 000000000000
> 0000 CPU#0
> MSR 0000000000001000 HID0 0000000060000000  HF 0000000000000000 iidx 3 didx 3
> TB 00000000 2549640032 DECR 1745327192
> GPR00 00000000fff096bc 0000000000000ff0 0000000000000000 0000000000000029 <- r2
> GPR04 0000000000000003 0000000000000000 0000000000000034 0000000000000020
> GPR08 0000000000000000 0000000000000000 0000000000000001 0000000000000ff0
> GPR12 0000000048800402 00000000fffbcce0 0000000000000000 0000000000030000
> GPR16 0000000000000001 0000000000030000 0000000000000000 0000000000030000
> GPR20 0000000000003030 0000000000000002 0000000000031f1f 00000000fffbcf08
> GPR24 0000000000035be0 0000000000031f68 00000000000351e0 00000000fffbcd0f
> GPR28 000000000000002f 0000000000100a50 00000000fffbcce0 00000000ffddabe0
> CR 28800402  [ E  L  L  -  -  G  -  E  ]             RES ffffffffffffffff
> FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPR20 37e00a5000000000 0000000000000000 0000000000000000 0000000000000000
> FPR24 3b83000200000000 0000000000000000 0000000000000000 0000000000000000
> FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> FPSCR 0000000000000000
>   SRR0 00000000001b7a5c  SRR1 8000000000003030    PVR 00000000003c0301 VRSAVE 000
> 0000000000000
> SPRG0 000000007fe00000 SPRG1 00000000fffffc70  SPRG2 0000000044482004  SPRG3 000
> 0000000000000
> SPRG4 0000000000000000 SPRG5 0000000000000000  SPRG6 0000000000000000  SPRG7 000
> 0000000000000
>   SDR1 000000007fe00000   DAR fffffffffffffd70  DSISR 0000000042000000
> (qemu) quit
> <-------
>
> SRR0 shows the address I dumped above in the objdump, SRR1 shows the MSR at the
> time of execution (I think).
>
> Now, I'm poking away at this thing, I can't say it will ever boot and I see
> the pretty OpenBSD dmesg before a panic, but I'm drawn back at this work and
> it's 6 months later from when I left it off.  I think using qemu is a good
> decision as it's faster, uses less power until the work can be put on the
> real machine.
>
> I'm looking for guidance I think.
>
> As a tid-bit I would say take a look at ofwreal.S in maccpc  I'll dump you the
> code snippet (in function ofw_stack):
>
> --->
>          addi    %r3,%r1,%r8
>          addi    %r1,%r4,-16
>          subi    %r5,%r5,%r8
>          subi    %r4,%r4,%r8
> <----
>
> I think that's wrong, register 8 is mtmsr'ed at the top of that and not
> modified.  What has register 4 and 5 have to do with MSR?  Shouldn't this
> mean just 8 and not %r8?
>
> This is also an area I struggled with in 64-bit mode.
>
> Best regards,
> -peter
>

Reply | Threaded
Open this post in threaded view
|

Re: back at it, some question regarding PowerPC / ELF

Peter J. Philipp-3
Hi Karel,

I'm not sure if I have.  I'll take a look, when I have time.  Currently, I'm
moving a mail server that will take up the day or so.  It's a very busy time
I don't know if I can even boot aimee vm this week.  

Thank you for the hint.

Best Regards,
-peter

On Mon, Jun 03, 2019 at 08:22:39PM +0200, Karel Gardas wrote:

>
> Peter,
>
> seeing you writing about openfirmware, pmap.c etc. Have you investigated
> NetBSD's PS3 files? Tsubai Masanari was kind to my ask and made them
> available again on http://nandra.segv.jp/NetBSD/ps3/
>
> Certainly some low level files like atomic.S, setjmp.S, pmap.c are there and
> may be at least interesting for reading if not for direct inclusion.
>
> Cheers,
> Karel
>
> On 5/9/19 8:25 AM, Peter J. Philipp wrote:
> > Hi all,
> >
> > I'm back at looking why my powerpc64 work didn't work out, and I think I made
> > some progress (I think).  For one I determined that there was no problem
> > jumping to compiled code from the asm, which I thought before was a problem.
> >
> > I compiled the kernel with gcc crosscompiler in the old aimee vm that I had
> > set up, I feel more comfortable with this, but I don't know why exactly.
> > aimee now runs on my MBP in vmware, that's another change I did.  This way
> > I can poke at it on weekends.  The OS is still 6.4-current from last year.
> >
> > Instead of using my G5 I'm using qemu with its built-in monitor to debug
> > the registers, this works faster and quieter IMO, I'm using the
> > floating-point registers as an indicator how far I got in the code (instruction
> > I use is (lis %21, 1; lfsux %fX, %r21, %r21;  <-- I know life sucks, the
> > console is not initialized at this point so I can't printf).  And right now
> > I'm still on ofwreal.S, which anyone would agree with me is hard ASM
> > code.  I started last week not knowing a lot about PowerPC asm, I try though.
> >
> > I reworked ofwreal.S in that I pulled out the macppc version and had it run
> > through, and it worked and got me further into pmap.c in execution but the
> > openfirmware stuff was so mangled it couldn't even figure out how much
> > physmem it had, big stopper there.  So I went back to redo ofwreal.S, it
> > dawned on me yesterday that fwcall is supposed to be .long size as it's an
> > instruction holder.  I made a little progress from then on but am stuck on
> > a big thing (I think).
> >
> > When I executed the bsd kernel, last,  it gets stuck trying to store to some
> > location offset from register 2 (a book I recently got says this is the TOC
> > pointer, an ELF thing).  And here is my question about this TOC (table of
> > contents), how would I best define an area for it?  Or how is this done?  As
> > far as the FreeBSD code is concerned they set up a __tocbase area at
> > locore64.S but then they do relocations, which I am unable to do in the short
> > term.  I'M pretty much confused by now.   I'll show you where in the qemu
> > emulator the execution flow stops:
> >
> > 00000000001b7a2c <OF_finddevice>:
> >    1b7a2c:       3c 40 00 84     lis     r2,132
> >    1b7a30:       38 42 73 00     addi    r2,r2,29440
> >    1b7a34:       7c 08 02 a6     mflr    r0
> >    1b7a38:       fb e1 ff f8     std     r31,-8(r1)
> >    1b7a3c:       7c 7f 1b 78     mr      r31,r3
> >    1b7a40:       f8 01 00 10     std     r0,16(r1)
> >    1b7a44:       f8 21 ff d1     stdu    r1,-48(r1)
> >    1b7a48:       48 34 25 59     bl      4f9fa0 <ofw_stack>
> >    1b7a4c:       60 00 00 00     nop
> >    1b7a50:       60 00 00 00     nop
> >    1b7a54:       60 00 00 00     nop
> >    1b7a58:       38 62 fd 60     addi    r3,r2,-672
> >    1b7a5c:       fb e2 fd 70     std     r31,-656(r2) <---- here
> >    1b7a60:       48 34 25 11     bl      4f9f70 <openfirmware>
> >    1b7a64:       60 00 00 00     nop
> >    1b7a68:       2f 83 ff ff     cmpwi   cr7,r3,-1
> >    1b7a6c:       41 9e 00 0c     beq-    cr7,1b7a78 <OF_finddevice+0x4c>
> >    1b7a70:       60 00 00 00     nop
> >    1b7a74:       e8 62 fd 7a     lwa     r3,-648(r2)
> >    1b7a78:       38 21 00 30     addi    r1,r1,48
> >
> >
> > I think I got ofw_stack right (but not sure) at least it went through it.
> > But now it tries to access register r2 which is not defined in this.  Here
> > is a register dump:
> >
> > ---->
> > (qemu) info registers
> > NIP 00000000fff096bc   LR 00000000fff096bc CTR 00000000fff0e7e4 XER 000000000000
> > 0000 CPU#0
> > MSR 0000000000001000 HID0 0000000060000000  HF 0000000000000000 iidx 3 didx 3
> > TB 00000000 2549640032 DECR 1745327192
> > GPR00 00000000fff096bc 0000000000000ff0 0000000000000000 0000000000000029 <- r2
> > GPR04 0000000000000003 0000000000000000 0000000000000034 0000000000000020
> > GPR08 0000000000000000 0000000000000000 0000000000000001 0000000000000ff0
> > GPR12 0000000048800402 00000000fffbcce0 0000000000000000 0000000000030000
> > GPR16 0000000000000001 0000000000030000 0000000000000000 0000000000030000
> > GPR20 0000000000003030 0000000000000002 0000000000031f1f 00000000fffbcf08
> > GPR24 0000000000035be0 0000000000031f68 00000000000351e0 00000000fffbcd0f
> > GPR28 000000000000002f 0000000000100a50 00000000fffbcce0 00000000ffddabe0
> > CR 28800402  [ E  L  L  -  -  G  -  E  ]             RES ffffffffffffffff
> > FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > FPR20 37e00a5000000000 0000000000000000 0000000000000000 0000000000000000
> > FPR24 3b83000200000000 0000000000000000 0000000000000000 0000000000000000
> > FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > FPSCR 0000000000000000
> >   SRR0 00000000001b7a5c  SRR1 8000000000003030    PVR 00000000003c0301 VRSAVE 000
> > 0000000000000
> > SPRG0 000000007fe00000 SPRG1 00000000fffffc70  SPRG2 0000000044482004  SPRG3 000
> > 0000000000000
> > SPRG4 0000000000000000 SPRG5 0000000000000000  SPRG6 0000000000000000  SPRG7 000
> > 0000000000000
> >   SDR1 000000007fe00000   DAR fffffffffffffd70  DSISR 0000000042000000
> > (qemu) quit
> > <-------
> >
> > SRR0 shows the address I dumped above in the objdump, SRR1 shows the MSR at the
> > time of execution (I think).
> >
> > Now, I'm poking away at this thing, I can't say it will ever boot and I see
> > the pretty OpenBSD dmesg before a panic, but I'm drawn back at this work and
> > it's 6 months later from when I left it off.  I think using qemu is a good
> > decision as it's faster, uses less power until the work can be put on the
> > real machine.
> >
> > I'm looking for guidance I think.
> >
> > As a tid-bit I would say take a look at ofwreal.S in maccpc  I'll dump you the
> > code snippet (in function ofw_stack):
> >
> > --->
> >          addi    %r3,%r1,%r8
> >          addi    %r1,%r4,-16
> >          subi    %r5,%r5,%r8
> >          subi    %r4,%r4,%r8
> > <----
> >
> > I think that's wrong, register 8 is mtmsr'ed at the top of that and not
> > modified.  What has register 4 and 5 have to do with MSR?  Shouldn't this
> > mean just 8 and not %r8?
> >
> > This is also an area I struggled with in 64-bit mode.
> >
> > Best regards,
> > -peter
> >