Re: OpenMPIC controller emulation in qemu ?

[BALATON Zoltan]

On Sun, 19 May 2024, Andrew Randrianasulu wrote:
> On Sun, May 19, 2024 at 1:46 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > 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*".
>
>
> It prints something like
>
> macio_nvram_read read addr=0x099e val=0x00
> macio_nvram_read read addr=0x099f val=0x00
> macio_nvram_read read addr=0x099f val=0x00
> macio_nvram_read read addr=0x09a0 val=0x00
> macio_nvram_read read addr=0x09a0 val=0x00
> macio_nvram_read read addr=0x09a1 val=0x00
> macio_nvram_read read addr=0x09a1 val=0x00
> macio_nvram_read read addr=0x09a2 val=0x00
> macio_nvram_read read addr=0x09a2 val=0x00
> macio_nvram_read read addr=0x09a3 val=0x00
> macio_nvram_read read addr=0x09a3 val=0x00
> macio_nvram_read read addr=0x09a4 val=0x00
> macio_nvram_read read addr=0x09a4 val=0x00
> macio_nvram_read read addr=0x09a5 val=0x00[    0.000000] nvram: OF
> partition at 0xffffffff
> [    0.000000] nvram: XP partition at 0xffffffff
> [    0.000000] nvram: NR partition at 0xffffffff
>
> but I can't see it poking around smp init?
>
> [    0.144619] PowerMac SMP probe found 2 cpus
> [    0.147225] Processor timebase sync using GPIO 0x73
> [    0.147847] mpic: requesting IPIs...
> [    0.153859] CPU0: L2CR is 0
> [    0.169098] rcu: Hierarchical SRCU implementation.
> [    0.188753] smp: Bringing up secondary CPUs ...
> smp_core99_kick_cpu
> smp_core99_kick_cpu done
> [    5.230919] Processor 1 is stuck.
> [    5.238874] smp: Brought up 1 node, 1 CPU
>
> probably more tracing need to be added to macio.c ?
>
> Any ideas where to look for examples?

You can just add fprintf(stderr, ...) for debugging wherever you want but 
in the same file there are already traces so it should log if the gpio 
region is accessed but maybe it does not have the right macio base for 
some reason. If this is still the void Linux kernel, try with the Finnix 
one, at least that seemed to find the macio base correctly. Also add -d 
unimp,guest_errors then if it accesses wrong address you may see logs 
about that. (Yes, this may be a lot of logs, redirect to file so you can 
analyse it afterwards.) If you need more traces look in trace-events in 
the dir where the source is for a list of available trace events. See 
also: https://www.qemu.org/docs/master/devel/tracing.html

> I also noticed that L2CR reg is 0 - shouldn't it represent some enabled L2
> cache on specifically PowerMacs ?

As QEMU does not emulate caches it probably does not matter (unless Linux 
wants this non-0, but if it does not care this should not be a problem). 
What's missing now is the Keylargo macio gpio lines to reset CPUs (after 
that it probably will be interrupt routings that may need to be figured 
out and fixed).

Regards,
BALATON Zoltan