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
