Re: mac99 SMP

[BALATON Zoltan]

On Sun, 23 Feb 2025, BALATON Zoltan wrote:
> Hello,

Forgot to cc Andrew in case he remembers something more from last year and 
could add that.

> To help to at least solve the CPU reset problem and to understand better 
> what's going on I've collected the patches that are needed at a minimum. This 
> won't allow SMP to work yet but hopefully at least help bring everybody 
> interested in this on the same page and show what I was trying to explain in 
> the past few days to at least get past that.
>
> Attached is a patch to openbios that adds device nodes for multiple CPUs but 
> I did not check if this is correct. Maybe the properties need to be adjusted 
> to match the real machine. I think we would need a PowerMac3,3 device tree 
> which is the closest dual CPU machine to the PowerMac3,1 that we currently 
> emulate but up to PowerMac3,6 may be similar enough. There are some device 
> tree dumps in the previous thread from last year for PowerMac3,6 but those 
> are not easy to read. Could somebody with a real machine get a text dump from 
> OpenFirmware, something like this:
> http://nandra.segv.jp/NetBSD/G4.dump-device-tree.txt
> but for PowerMac3,3 or similar with two G4 CPUs. Then compare what you get in 
> OpenBIOS with this patch to that and correct the CPU nodes.
>
> The other patch is for QEMU that hacks the gpio register Linux writes to 
> reset the CPU to change the corresponding irq and connects that to the CPU 
> reset. (I've sent two clean up patches separately that are useful 
> regardless.) I don't know if this IRQ should connect to HRESET or SRESET on 
> the CPU but neither seems to work and Linux still says the CPU is stuck even 
> if the CPU now gets the reset interrupt. This can be verified by adding 
> -trace enable="macio*" -trace enable="ppc_irq*" (or you may want to tune the 
> latter as one of these is very verbose). The second CPU seems to start 
> stopped but then gets an IRQ on pin 5 (see /* 6xx bus input pins */ in 
> qemu/target/ppc/cpu.h line 2552, 5 is PPC6xx_INPUT_INT) before it's reset so

Actually looking at that again the pin 5 is of CPU0 so that's OK. CPU1 
only seems to get the reset interrupt so maybe it does not start at that 
point as it should. I don't know how the start-powered-off property and 
putting the CPU in HLT exception on reset is supposed to work, those wore 
only copied from other machines so maybe not correct for mac99. Anybody 
has some explanation on how to do this properly? From the linux source it 
seems that Linux expects the cpu to start executing at the reset vector 
when this GPIO is poked.

> maybe the interrupt connections are wrong or the openpic emulation is not set 
> up correctly. I also don't know if it would start on reset at the right 
> vector and if the ppc_core99_reset_sec() is needed when we have 
> object_property_set_bool(OBJECT(cpus[i]), "start-powered-off" for the 
> secondary CPU. It seems whatever I do with these it won't be detected as 
> running by Linux so there's some other issue somewhere else but at least it 
> still boots with the first CPU. It's likely IRQ connections are wrong so 
> maybe that could be checked. Sources for the correct values would be the 
> device tree from real machine and maybe 
> linux/arch/powerpc/platforms/powermac/smp.c and 
> linux/arch/powerpc/sysdev/mpic.c but I don't know this and I'm not interested 
> in it enough to try to understand those and dig for more information unless 
> somebody can give some clues or explain it so I don't have to find the 
> missing info. Otherwise that's all I could help with it now.
>
> Regards,
> BALATON Zoltan