[prev in list] [next in list] [prev in thread] [next in thread]
List: openbsd-ppc
Subject: Re: back at it, some question regarding PowerPC / ELF
From: "Peter J. Philipp" <pjp () centroid ! eu>
Date: 2019-06-04 6:00:37
Message-ID: 20190604060037.GA98509 () omega ! virgostar ! net
[Download RAW message or body]
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
> >
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic