Re: OpenMPIC controller emulation in qemu ?

[BALATON Zoltan]

On Mon, 20 May 2024, Andrew Randrianasulu wrote:
> > Add -d unimp,guest_errors -trace enable="macio*"
>
> /dev/shm/qemu-9.0.0/build/qemu-system-ppc -m 256  -M mac99,via=pmu
> -smp 2  -kernel /mnt/tmp/boot/vmlinux  -vga none -device ati-vga
> -bios /dev/shm/openbios-qemu.elf -d unimp,guest_errors -trace
> enable="macio*" -nographic
>
> =====
>
> a bit long due to nvram debug ...

You could have cut that.

> smp_core99_probe
> [    0.149749] PowerMac SMP probe found 2 cpus
> [    0.152131] PMU i2c /pci@f2000000/mac-io@c/via-pmu@16000
> [    0.153243]  channel 1 bus <multibus>
> [    0.153610]  channel 2 bus <multibus>
> [    0.154660] Processor timebase sync using GPIO 0x73
> [    0.155199] mpic: requesting IPIs...
> [    0.159006] CPU0: L2CR is 0
> [    0.175673] rcu: Hierarchical SRCU implementation.
> [    0.198787] smp: Bringing up secondary CPUs ...
> smp_core99_kick_cpu
> macio_gpio_write addr: 0xc value: 0x4
> macio_gpio_write addr: 0x4 value: 0x4
> macio_gpio_write addr: 0xc value: 0x0
> macio_gpio_write addr: 0x4 value: 0x0
> smp_core99_kick_cpu done
> macio_set_gpio setting GPIO 1 to 0
> macio_set_gpio setting GPIO 1 to 0
> macio_set_gpio setting GPIO 1 to 0
> macio_set_gpio setting GPIO 1 to 0
> macio_set_gpio setting GPIO 1 to 0
> [    5.244500] Processor 1 is stuck.
> [    5.253569] smp: Brought up 1 node, 1 CPU

There you go, it reaches the gpio registers. Now you can compare with the 
Linux source code and emulation in qemu/hw/misc/macio/gpio.c and find what 
GPIO lines are these. (One of the writes may actually be read but the same 
trace event is used; you can fix that or add more debug logs if needed.) 
It seems to do a write to set the direction to ouput and another that 
should raise the line. Finally it clears it to reset to 0. It does reads 
inbetween which may be to ensure that previous writes have an effect. If 
you find out what the bits should mean then you'd understand when to reset 
the CPU. When the 1 bit is written to the ouput reg while the GPIO line is 
set to output it should change the state of the appropriate 
s->gpio_extirqs line and that should raise the CPU reset interrupt. But 
that is currently connected to one of the openpic lines. So either the 
reset line of the CPU should be connected to this GPIO line and 
macio_gpio_write should actually call macio_set_gpio to raise/lower that 
line or this should somehow poke that openpic line. I don't know how real 
machine does it so you could try to hack something up then test it to see 
if that at least makes it detect the second CPU. As you only have 
MacIOGPIOState in macio_gpio_write() maybe easiest to change the CPU reset 
line to connect to the appropriate GPIO line (and fix gpio.c to not only 
store the reg value but also change the s->gpio_extirqs or you may need to 
add a reference to the openpic in MacIOGPIOState so you can access that. 
I'll let you or anybody else interested in making this work figure this 
out, I don't want to attempt fixing it. It may help if Mark who is the 
maintainer of these parts would share his thoughts maybe.

(Once this fixed I'd expect more problems ahead but at least we already 
had two CPUs running and then likely crash due to some missing 
synchronisation or IRQ handling which may be more difficult to find out 
without documentation but maybe we're lucky and it would do something if 
the reset line is fixed. Just so you know this is likely not everything 
that needs to be fixed and there's more work ahead.)

Regards,
BALATON Zoltan