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.