Re: OpenMPIC controller emulation in qemu ?

[BALATON Zoltan]

On Sun, 19 May 2024, Andrew Randrianasulu wrote:
> On Sun, May 19, 2024 at 4:41 PM Andrew Randrianasulu <randrianasulu@gmail.com> 
> wrote:
> > > You can just add fprintf(stderr, ...) for debugging wherever you want but
> > > in the same file there are already traces
> >
> >
> >
> > well, I see timer traces, but for example if I want to look at writings to
> > register not yet defined there - should I look at adding new static const
> > MemoryRegionOps { } with my (trace only) implementation ?

Macio is a bit messy but in 
qemu/hw/misc/macio/macio.c::macio_newworld_realize() you can see what 
memory regions are used (or check info mtree in QEMU monitor which also 
shows which memory regions appear at what addresses). The gpio region is 
added at offset 0x50 but only if via=pmu. If a write goes to this gpio 
region which is 0x30 bytes long as seen in 
(qemu/hw/misc/macio/gpio.c::macio_gpio_init() where it is created, i.e. 
between 0x80000050-0x8000007f then the callbacks for the gpio memory 
region defined in macio_gpio_ops are called, that is 
macio_gpio_{read|write}. These have a trace_macio_gpio_write() trace 
(interestingly read too so you'll get write traces for reads as well) so 
you should see if the guest accessed this region. If it accessses regions 
where no memory region is defined -d unimp,guest_errors should catch that 
ans you should see Invalid read/write logs. If they go to some other 
device then you may not see logs but you can also try enabling openpic 
traces besides macio and -d unimp,guest_errors and that should cover most 
aread around this device. (There are also some docs on MemoryRegions in 
QEMU documentation but it's mostly self explanatory.)


> > 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.
> >
> >
> > well, this version of finnix was apparently  compiled for non-smp? But I
> > also have debian 8 ppc  ....

Find a distro that's known to work on real PowerMac3,3 with two CPUs. 
Debian should also work as long as it's a version that you can confirm 
somewhere that it booted on real machine. There may be Adelie as well 
which should still support PPC but I don't know if it works on Macs or on 
QEMU. If you first need to fix OpenBIOS just to boot it with a single CPU 
then that's just distracting from getting multiple CPUs work so better to 
find something which already boots and also confirmed to work on real 
machine so that it should bring less unrelated problems. Is there anybody 
with a real Dual G4 PowerMac who can test which images work on that?

> > 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).
> >
> >
> > I noticed code for dealing with caches in Linux's smp.c ...

As QEMU does not have caches it probably won't matter unless these are 
also used for syncing between CPUs but we can worry about that later when 
the second CPU starts executing something at all.

> > I also tried to remove "powered-off" we just added  property while leaving
> > secondary cpu reset and this hanged at very beginning before openfirmware
> > start. This leaves me with question may be Linux do not know how to
> > power-on secondary cpus on Powermacs

I don't know how these work. It's possible that on real machine secondary 
CPUs aren't halted but the firmware detects secondary CPUs and put them in 
a loop but a reset should get the CPU back to the reset vector either way, 
so even if it's in HALTED which the start-powered-off property sets or the 
HALT exception in the secondary reset function does should be the same 
for getting them start at the reset vector at reset. The problem is the 
reset signal does not reach the CPU as the Keylargo GPIO this should be 
connected to is not emulated and not connected.

> > . But yeah, hopefully it just missing
> > gpio lines ... right now in gpio.c it only says about handling gpio 1/9 (9
> > being NMI)
> >
> > Also it has this comment:
> >
> > * Note that we probably need to get access to the MPIC config to
> >      * decode polarity since qemu always use "raise" regardless.
> >      *
> >      * For now, we hard wire known GPIOs
> >      */

This only matters if a signal is active low but this reset routine in 
Linux will raise then lower the gpio line so I think it would work if it 
invoked the reset line of the appropriate CPU.

> > but I hope for testing just adding more cases like already there will be
> > enough.

Probably not as this is in macio_set_gpio() which is not called from 
macio_gpio_write() which is what runs when the register is written. Unless 
I'm missing something macio_gpio_write() should also call macio_set_gpio() 
when the values are changed. I think macio_gpio_{read|write} amulates the 
Keylargo gpio lines while macio_set_gpio() emulates the connections in the 
PowerMac so this macio_set_gpio() is probably not at the right place but 
that's a clean up I would not worry about now.

> > > 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).
> >
> >
> > yeah, right now while finnix-110 cd starts up without openfirmware

There's also finnix-111, ppc was dropped afterwards. Is 111 also without 
SMP?

> > crashing it can't find itself and keyboard not working so I can't type cat
> > /proc/interrupts :)

What if you add -device usb-keyboard? I think it should be the default 
with mac99,via=pmu but who knows.

> Just for experience I tried netbsd-10 macppc ISO

If these don't boot on unmodified QEMU then it probably does not help as 
you're debugging problems unrelated to SMP support so I'd go with 
something that already works with one CPU and known to work with two on 
real machine.

> Invalid read at addr 0x80000038, size 4, region '(null)', reason: rejected
> Invalid read at addr 0x38, size 4, region '(null)', reason: rejected
> Invalid write at addr 0x80000038, size 4, region '(null)', reason: rejected
> Invalid write at addr 0x38, size 4, region '(null)', reason: rejected
>
> I think 0x38 is KEYLARGO_FCR0 0x38 from Linux's Keylargo.h

This register seems to be used for enabling different chip functions 
(Keylargo is like a superio chip with embedded functions called cells, 
there are serial, usb, etc. parts) QEMU does not emulate this and all 
emulated parts are always enabled so this likely won't matter.

Regards,
BALATON Zoltan