Re: OpenMPIC controller emulation in qemu ?

[Andrew Randrianasulu]

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?

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?

>
> (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