Re: OpenMPIC controller emulation in qemu ?

[BALATON Zoltan]

On Tue, 21 May 2024, Andrew Randrianasulu wrote:
> On Mon, May 20, 2024 at 10:53 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > 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.
>
>
> Wel, I have question at very beginning. in include/hw/misc/gpi.h I read
>
> PowerMac NewWorld MacIO GPIO emulation
>
> so this is ONLY for new world machines?

TYPE_MACIO_GPIO is only init in macio_newworld_init() and even then it's 
only ised if via=pmu, it is destroyed with the default via=cuda. So looks 
like this is only for PowerMac3,1 with PMU99. I don't know if that's 
correct but it's how it is in QEMU currently.

> because it says ..
>
> struct MacIOGPIOState {
>    /*< private >*/
>    SysBusDevice parent;
>    /*< public >*/
>
>    MemoryRegion gpiomem;
>    qemu_irq gpio_extirqs[10];
>    uint8_t gpio_levels[8];
>    uint8_t gpio_regs[36]; /* XXX Check count */
> };
>
> I think 10 a bit too small considering Linux saves
> KEYLARGO_GPIO_EXTINT_CNT of them
> in feature.c's core99_sleep(void)
>
> #define KEYLARGO_GPIO_EXTINT_CNT    18
>
> so, I guess we should extend this one?

I don't know undocumented Mac hardware but the writes we saw for CPU reset 
was 4 which may be GPIO 3 if this is a bit value so that should fit in 
this already.

Regards,
BALATON Zoltan