Re: SPR implementation request.

[BALATON Zoltan]

On Sun, 21 Jun 2020, Jd Lyons wrote:
> > On Jun 21, 2020, at 11:17 AM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >
> > On Sun, 21 Jun 2020, Jd Lyons wrote:
> > > Raise exception at 0000000000000008 => 00000060 (21)
> > > Raise exception at 00000000000b2960 => 00000042 (00)
> > > ----------------
> > > IN:
> > > 0x00000000:  55555555  rlwinm.  r21, r10, 0xa, 0x15, 0xa
> > > 0x00000004:  55555555  rlwinm.  r21, r10, 0xa, 0x15, 0xa
> > > 0x00000008:  00000000  .byte    0x00, 0x00, 0x00, 0x00
> > >
> > > Raise exception at 0000000000000008 => 00000060 (21)
> > > Raise exception at 00000000000b2960 => 00000042 (00)
> > > ----------------
> > >
> > > Anyone know what’s going on here?
> >
> > This is when it's already gone astray. You should go back to the last point 
> > when it still executed meaningful code and find out what it did that caused it 
> > to end up in the above repeating pattern.
> >
> > Regards,
> > BALATON Zoltan
>
> It’s all Greek to me:

That's what the CPU manual is for to learn about how all this works. I 
know it's huge but use it as a reference to look up things you don't know. 
Start by finding what the SPRs in your first supposed to do to understand 
if any of those could be needed.

It's not too useful to post random logs on this list, instead try to find 
the point where it starts going off the normal execution:

> qemu-system-ppc64 -M mac99 -m 1024 -hda ~/Leopard.img -serial stdio  -d 
> guest_errors  -d int,in_asm
> ----------------
> IN:
> 0xfff00100:  48002420  b        0xfff02520

It starts at the reset vector (see address in first column) and jumps into 
the ROM where it starts running the firmware (in this case OpenBIOS):

> ----------------
> IN:
> 0xfff02520:  38000000  li       r0, 0
> 0xfff02524:  3c608000  lis      r3, -0x8000
> 0xfff02528:  7c631a15  add.     r3, r3, r3
> 0xfff0252c:  4182000c  beq      0xfff02538
>
> ----------------
> IN:
> 0xfff02530:  7c000164  mtmsrd   r0
>
> ----------------
> IN:
> 0xfff02534:  48000008  b        0xfff0253c
>
> ----------------
> IN:
> 0xfff0253c:  3c60fff0  lis      r3, -0x10
> 0xfff02540:  38630000  addi     r3, r3, 0
> 0xfff02544:  38800000  li       r4, 0
> 0xfff02548:  38a02530  li       r5, 0x2530
> 0xfff0254c:  54a50038  rlwinm   r5, r5, 0, 0, 0x1c
> 0xfff02550:  80c30000  lwz      r6, 0(r3)

Things like the above are normal code that do something, we know from the 
address that this is OpenBIOS which you could look up the source to see 
where these come from but it should be OK until it stays in the ROM area 
so you can skip that.

> IN:
> 0xfff08cb8:  7d2000a6  mfmsr    r9
> 0xfff08cbc:  61290030  ori      r9, r9, 0x30
> 0xfff08cc0:  7d200124  mtmsr    r9
>
> Raise exception at 00000000fff08cc4 => 00000003 (40000000)
> ----------------
> IN:
> 0x00000400:  48002028  b        0x2428
>
> ----------------
> IN:
> 0x00002428:  7c3143a6  mtspr    0x111, r1

Here an exception is raised and jumps to the exception vector (see CPU 
manual) then calls the handler installed by OpenBIOS.


> 0x000024b4:  38638b9c  addi     r3, r3, -0x7464
> 0x000024b8:  7c6903a6  mtctr    r3
> 0x000024bc:  4e800421  bctrl
>
> ----------------
> IN:
> 0xfff08b9c:  9421ffe0  stwu     r1, -0x20(r1)
> 0xfff08ba0:  7c0802a6  mflr     r0

Here handler seems to call something in ROM.

> 0xfff08ba4:  90010024  stw      r0, 0x24(r1)
> 0xfff08ba8:  93e1001c  stw      r31, 0x1c(r1)
> 0xfff08bac:  7ffa02a6  mfspr    r31, 0x1a
> 0xfff08bb0:  7d3b02a6  mfspr    r9, 0x1b
> 0xfff08bb4:  38810008  addi     r4, r1, 8
> 0xfff08bb8:  7fe3fb78  mr       r3, r31
> 0xfff08bbc:  4bfffaf1  bl       0xfff086ac
>
> ----------------
> IN:
> 0xfff086ac:  3d20ffef  lis      r9, -0x11

Which calls more subroutines.

> 0xfff08bc8:  7fe3fb78  mr       r3, r31
> 0xfff08bcc:  4bfffbbd  bl       0xfff08788
>
> ----------------
> IN:
> 0xfff08788:  9421ffc0  stwu     r1, -0x40(r1)
> 0xfff0878c:  7c0802a6  mflr     r0
> 0xfff08790:  429f0005  bdnzl    0xfff080x000024c8:  80010034  lwz      r0, 
> 0x34(r1)
> 0x000024cc:  7c0803a6  mtlr     r0
> 0x000024d0:  80010038  lwz      r0, 0x38(r1)
> 0x000024d4:  7c0ff120  mtcrf    0xff, r0

And either eventually returns to handler or your log is mixed up.

> 0x000024d8:  8001003c  lwz      r0, 0x3c(r1)
> 0x000024dc:  7c0903a6  mtctr    r0
> 0x000024e0:  80010040  lwz      r0, 0x40(r1)
> 0x000024e4:  7c0103a6  mtxer    r0
> 0x000024e8:  80010000  lwz      r0, 0(r1)
> 0x000024ec:  80410008  lwz      r2, 8(r1)
> 0x000024f0:  8061000c  lwz      r3, 0xc(r1)
> 0x000024f4:  80810010  lwz      r4, 0x10(r1)
> 0x000024f8:  80a10014  lwz      r5, 0x14(r1)
> 0x000024fc:  80c10018  lwz      r6, 0x18(r1)
> 0x00002500:  80e1001c  lwz      r7, 0x1c(r1)
> 0x00002504:  81010020  lwz      r8, 0x20(r1)
> 0x00002508:  81210024  lwz      r9, 0x24(r1)
> 0x0000250c:  81410028  lwz      r10, 0x28(r1)
> 0x00002510:  8161002c  lwz      r11, 0x2c(r1)
> 0x00002514:  81810030  lwz      r12, 0x30(r1)
> 0x00002518:  80210004  lwz      r1, 4(r1)
> 0x0000251c:  4c000024  rfid
>
> ----------------
> IN:
> 0xfff08cc4:  39610020  addi     r11, r1, 0x20

Here handler "Returns From Interrupt" (not sure what d stands for but see 
CPU manual).

> 0xfff08cc8:  48027efc  b        0xfff30bc4
>
> Raise exception at 00000000fff30bc4 => 00000003 (40000000)
> ----------------
> IN:
> 0xfff30bc4:  83abfff4  lwz      r29, -0xc(r11)
> 0xfff30bc8:  83cbfff8  lwz      r30, -8(r11)

Another exception happens, same handler is called but does not appear in 
in_asm log again because it's already translated and runs from TB cache.

> 0xfff30bcc:  800b0004  lwz      r0, 4(r11)
> 0xfff30bd0:  83ebfffc  lwz      r31, -4(r11)
> 0xfff30bd4:  7c0803a6  mtlr     r0
> 0xfff30bd8:  7d615b78  mr       r1, r11
> 0xfff30bdc:  4e800020  blr
>
> Raise exception at 00000000fff30bc4 => 00000002 (00)
> ----------------
> IN:
> 0x00000300:  4800208c  b        0x238c
>
> ----------------
> IN:
> 0x0000238c:  7c3143a6  mtspr    0x111, r1
> 0x00002390:  7c200026  mfcr     r1

A different exception and its handler...

> Raise exception at 00000000fff2fa1c => 00000002 (00)
> Raise exception at 00000000fff2fa1c => 00000002 (00)
> ----------------
> IN:
> 0xfff0af14:  2f830000  cmpwi    cr7, r3, 0
> 0xfff0af18:  907d0004  stw      r3, 4(r29)
> 0xfff0af1c:  40be000c  bne      cr7, 0xfff0af28

It's still in the ROM here so it did not even start executing any MacOS X 
code yet.

> ----------------
> qemu-system-ppc64 -M mac99 -m 1024 -hda ~/Leopard.img -serial stdio  -d 
> guest_errors  -d int,in_asm
> ----------------
> IN:
> 0xfff00100:  48002420  b        0xfff02520
>
> ----------------
> IN:
> 0xfff02520:  38000000  li       r0, 0
> 0xfff02524:  3c608000  lis      r3, -0x8000

And your log just restarts here so you've missed the relevant part 
completely.

Instead you should save the log in a file (it will be big, especially if 
you leave it running after it repeats so try to stop quickly at that 
point). Then do not send it here but start reading from the end and go 
back until you have some code like above not random bytes executed as code 
like in the repeating part. Likely that's where it breaks, or a little 
before that. Try to understand what it wanted to do and what caused it to 
get into the wrong execution path to find out what needs to be fixed. This 
point will be somewhere before it jumped off from OpenBIOS (left area 
above 0xfff00000) and started executing OS code but before it got to 
address 0 as in the repating part.

Regards,
BALATON Zoltan