Re: OpenMPIC controller emulation in qemu ?

[BALATON Zoltan]

On Sun, 19 May 2024, BALATON Zoltan wrote:
> On Sun, 19 May 2024, BALATON Zoltan wrote:
> > On Sun, 19 May 2024, Andrew Randrianasulu wrote:
> > > сб, 18 мая 2024 г., 23:33 BALATON Zoltan <balaton@eik.bme.hu>:
> > >
> > > > On Sat, 18 May 2024, Andrew Randrianasulu wrote:
> > > > > On Sat, May 18, 2024 at 11:14 PM BALATON Zoltan <balaton@eik.bme.hu>
> > > > wrote:
> > > > > > On Sat, 18 May 2024, Andrew Randrianasulu wrote:
> > > > > > > On Sat, May 18, 2024 at 10:24 PM BALATON Zoltan <balaton@eik.bme.hu>
> > > > > > wrote:
> > > > > > > > On Sat, 18 May 2024, Andrew Randrianasulu wrote:
> > > > > > > > > Using attached patch I get this  new dmesg:
> > > > > > > > >
> > > > > > > > > Quiescing Open Firmware ...
> > > > > > > > > > > of_client_interface: quiesce
> > > > > > > > > > > of_client_interface return:
> > > > > > > > > Booting Linux via __start() @ 0x01000000 ...
> > > > > > > > > Hello World !
> > > > > > > > > [    0.000000] Total memory = 512MB; using 1024kB for hash table
> > > > > > > > > [    0.000000] Activating Kernel Userspace Execution Prevention
> > > > > > > > > [    0.000000] Activating Kernel Userspace Access Protection
> > > > > > > > > [    0.000000] Linux version 5.13.12_1 (voidlinux@voidlinux) (gcc
> > > > > > (GCC)
> > > > > > > > 10.2.1 20201203, GNU ld (GNU Binutils) 2.35.1) #1 SMP Thu Aug 19
> > > > > > 14:12:26
> > > > > > > > UTC 2021
> > > > > > > > > [    0.000000] ioremap() called early from
> > > > > > pmac_feature_init+0xd4/0xad4.
> > > > > > > > Use early_ioremap() instead
> > > > > > > > > [    0.000000] Found UniNorth memory controller & host bridge @
> > > > > > > > 0xf8000000 revision: 0x07
> > > > > > > > > [    0.000000] Mapped at 0xf73c0000
> > > > > > > > > [    0.000000] ioremap() called early from
> > > > probe_one_macio+0x17c/0x2b4.
> > > > > > > > Use early_ioremap() instead
> > > > > > > > > [    0.000000] Found a Keylargo mac-io controller, rev: 0, mapped at
> > > > > > > > 0x(ptrval)
>
> So the MACIO_OUT8 macro pokes macio->base and it's not listed here unlike in 
> the log from real machine so not sure it's writing the right address. You can 
> check witn info mtree in QEMU monitor where things appear but may need 
> another kernel which logs thinks similar to the log you got from real 
> machine. Does the finnix kernel work better with -append debuglevel=<some 
> number here but I don't know what's a good number". Maybe can also enable 
> openpic and macio traces to see if their regs are accessed. Something like 
> QEMU option -trace enable="macio*" maybe?

The finnix kernel prints an address here which seems to match where mac-io 
is mapped at. I believe the writes from smp_core99_kick_cpu() should end 
up in QEMU's macio/gpio emulation in qemu/hw/misc/macio/gpio.c. You could 
verify that with -trace eneable="macio*". I think the GPIO lines to reset 
the CPU should be implemented here but I don't know if this should be the 
default 3,4,15,16 from KL_GPIO_RESET_CPU0-3 that is used without 
soft-reset property or the 33,34 that is implied by the device tree dump 
you've found. For Linux the defaults probably will do know then no need to 
hack OpenBIOS for that. For Mac OS X we may need to match real machine 
later. I also don't know if these gpios should poke the openpic where the 
CPU reset lines seem to be connected or the reset lines should instead be 
connected to these gpio lines.

I've also found this document which describes the hardware:
http://cdn.preterhuman.net/texts/computing/apple_hardware_devnotes/PowerMac%20G4%20(summer%2700).pdf
but it does not have much dettails, only high level overview.

One more thing that could be confusing. QEMU has qemu_*_gpio_* functions 
that are described here: 
https://www.qemu.org/docs/master/devel/qdev-api.html and are really 
related to qemu_irqs that is QEMU's model of an interrupt or gpio line. 
This is not the same as gpio lines of a chip (but a chip's gpio lines can 
be modelled with QEMU gpios) so make sure you understand what is referred 
to when you see gpio as it could be a QEMU gpio/qemu_irq or a chip gpio 
that could be confusing at first.

Regards,
BALATON Zoltan