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

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
>