Making some progress with spm as far as getting some useful debug info.

I seem to be raising an exception state when Mac OS X 10.4.11 Kernel loads and tries to reset and wake the additional cores 

qemu-system-ppc64-unsigned: info: Core0: openpic_update_irq: IRQ 255 is disabled

qemu-system-ppc64-unsigned: info: Core0: openpic_update_irq: IRQ 255 is already inactive

qemu-system-ppc64-unsigned: info: Core0: Set IVPR 255 to 0x80000000 -> 0x80000000

qemu-system-ppc64-unsigned: info: Core0: openpic_gbl_write: addr 0x10e0 <= 000000ff

qemu-system-ppc64-unsigned: info: Core0: openpic_gbl_write: addr 0x1020 <= 20000000

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: cpu 0 addr 0x80 <= 0x00000000

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: set CPU 0 ctpr to 0, raised 0 servicing 0

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: Lower OpenPIC INT output cpu 0 due to ctpr

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: cpu 1 addr 0x1080 <= 0x00000000

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: set CPU 1 ctpr to 0, raised 0 servicing 0

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: Lower OpenPIC INT output cpu 1 due to ctpr

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: cpu 2 addr 0x2080 <= 0x00000000

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: set CPU 2 ctpr to 0, raised 0 servicing 0

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: Lower OpenPIC INT output cpu 2 due to ctpr

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: cpu 3 addr 0x3080 <= 0x00000000

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: set CPU 3 ctpr to 0, raised 0 servicing 0

qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: Lower OpenPIC INT output cpu 3 due to ctpr<—exception state starts here and terminal output ends after the kernel tries to enable the additional cores but accesses the non-existent L2 CR( SPR 1012 )



Raise exception at 00000000fff10698 => DSI (2) error=00

Raise exception at 00000000fff17098 => ISI (3) error=40000000

Raise exception at 00000000fff0ad08 => DSI (2) error=00

Raise exception at 00000000fff171f4 => DSI (2) error=00

Trying to read invalid spr 1012 (0x3f4) at 0000000000092884 <———————Here from the qemu log that we raise an exception state when the kernel tries to read the L2 cache cr








Raise exception at 00000000000af72c => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000000000 r5=0000000000000000 r6=0000000000000000 r7=0000000000000000 r8=0000000072696e67 nip=00000000000af72c

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000000000 r5=0000000000959000 r6=0000000000000000 r7=ffffffffff77d000 r8=0000000000000883 nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000883c80 r5=0000000000000000 r6=0000000000000006 r7=0000000000000000 r8=0000000000000884 nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000884c80 r5=0000000000000000 r6=000000000000000c r7=0000000000883000 r8=0000000000000885 nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000885c80 r5=0000000000000000 r6=0000000000000012 r7=0000000000884000 r8=0000000000000886 nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000886c80 r5=0000000000000000 r6=0000000000000018 r7=0000000000885000 r8=0000000000000887 nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000887c80 r5=0000000000000000 r6=000000000000001e r7=0000000000886000 r8=0000000000000888 nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000888c80 r5=0000000000000000 r6=0000000000000024 r7=0000000000887000 r8=0000000000000889 nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000889c80 r5=0000000000000000 r6=000000000000002a r7=0000000000888000 r8=000000000000088a nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00

syscall r0=0000000000007ff4 r3=0000000000000000 r4=00000000003d91c0 r5=00000000ffffffe8 r6=0000000000005140 r7=0000000000000000 r8=000000000000088b nip=000000000009cefc

Raise exception at 000000000009cefc => SYSCALL (8) error=00



On Feb 20, 2025, at 8:41 AM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:



On Feb 19, 2025, at 7:38 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:

On Thu, 20 Feb 2025, BALATON Zoltan wrote:
Maybe you just need to change the code that connects OPENPIC_OUTPUT_RESET with PPC6xx_INPUT_HRESET in qemu/hw/ppc/mac_newworld.c to connect PPC6xx_INPUT_HRESET to some gpio line of the macio gpio part instead. That

Searching for OPENPIC_OUTPUT_RESET shows it's related to OpenPIC PIR register:

qemu/hw/intc/openpic.c::openpic_gbl_write()
  case 0x1090: /* PIR */
      for (idx = 0; idx < opp->nb_cpus; idx++) {
          if ((val & (1 << idx)) && !(opp->pir & (1 << idx))) {
              DPRINTF("Raise OpenPIC RESET output for CPU %d", idx);
              dst = &opp->dst[idx];
              qemu_irq_raise(dst->irqs[OPENPIC_OUTPUT_RESET]);
          } else if (!(val & (1 << idx)) && (opp->pir & (1 << idx))) {
              DPRINTF("Lower OpenPIC RESET output for CPU %d", idx);
              dst = &opp->dst[idx];
              qemu_irq_lower(dst->irqs[OPENPIC_OUTPUT_RESET]);
          }
      }

so you can uncomment /* #define DEBUG_OPENPIC */ in this file and look for logs from above DPRINTFs when you run your SMP Linux kernel. If you don't see any of these in the log then this means this register is not used and the Mac likely does not use this but does the CPU resets through the GPIOs of the macio chip. I don't know if those are directly connected to the CPUs on the real machine or somehow cause the openpic PIR to be changed but connecting the CPU resets to the GPIO lines seems to be more likely and probably easier to do in QEMU as well. Maybe this PIR thing is what Motorola SoCs do to reset the cores within the SoC as comments on top of openpic.c says it was based on that. You could also check the openpic docs referenced in the comments to see how this should work or what PIR means at all. Maybe that would help understanding it. I don't know so I also don't understand but I'm too lazy to look up docs so I just keep guessing instead.

Or I can check Linux source to see if this is different on e500. It seems linux/arch/powerpc/platforms/85xx/smp.c calls mpic_reset_core() to do the same that the Mac does with GPIOs and and in linux/arch/powerpc/sysdev/mpic.c it seems mpic_reset_core() is poking the PIR which now I guess means Processor Init Register maybe. So I think my guess is correct, currently QEMU is wired for e500 but that's not correct for the Mac which does this with GPIOs in macio instead so that should be fixed. The Linux sources is the proof for this theory.

Regards,
BALATON Zoltan

Thanks Balaton, I’m working on the PIR code in the Openpic.c to see if I can resolve some of the issues with resets of the additional cpus. The limit for qemu ppc seems to be 32 cores but Openbios only seems to read 20 of them. At any rate, if I can get 2 or 4 cores working things will be that much faster, I just like to see all those cores in the device tree. I’m just toying around with more than 2 cores because that is all a PowerMac G4 ever had anyway.

On a side note, not unrelated I looked at my Dual CPU MDD PowerMac and found the GPIO has several nodes in the device tree, like 8 or 9 of them, I did not count. Anyways, it looks like only the top device pci/Mac-io/@50 is the GPIO for the CPUs and maybe some other stuff, and it has an extended gpio that looks like it may handle the other CPU or just some other system stuff, all the other GPIO entries in the deice tree below it on the Mac-io/ node say they are for audio.

A rather complex setup for builtin audio if you ask me, but if I have too I’ll probe the main gpio@50 and see if I can find how the cpus are brought out of reset.

Likely the code you pointed to is all we need to property reset the second cpu in qemu so that linux, OS 9, and OS X can bring it up and use it.



_______________________________________________
OpenBIOS mailing list -- openbios@openbios.org
To unsubscribe send an email to openbios-leave@openbios.org