Re: [PATCH qemu v20] spapr: Implement Open Firmware client interface

[BALATON Zoltan]

On Sun, 23 May 2021, BALATON Zoltan wrote:
> On Sun, 23 May 2021, Alexey Kardashevskiy wrote:
> > One thing to note about PCI is that normally I think the client expects the 
> > firmware to do PCI probing and SLOF does it. But VOF does not and Linux 
> > scans PCI bus(es) itself. Might be a problem for you kernel.
>
> I'm not sure what info does MorphOS get from the device tree and what it 
> probes itself but I think it may at least need device ids and info about the 
> PCI bus to be able to access the config regs, after that it should set the 
> devices up hopefully. I could add these from the board code to device tree so 
> VOF does not need to do anything about it. However I'm not getting to that 
> point yet because it crashes on something that it's missing and couldn't yet 
> find out what is that.
>
> I'd like to get Linux working now as that would be enough to test this and 
> then if for MorphOS we still need a ROM it's not a problem if at least we can 
> boot Linux without the original firmware. But I can't make Linux open a 
> serial console and I don't know what it needs for that. Do you happen to 
> know? I've looked at the sources in Linux/arch/powerpc but not sure how it 
> would find and open a serial port on pegasos2. It seems to work with the 
> board firmware and now I can get it to boot with VOF but then it does not 
> open serial so it probably needs something in the device tree or expects the 
> firmware to set something up that we should add in pegasos2.c when using VOF.

I've now found that Linux uses rtas methods read-pci-config and 
write-pci-config for PCI access on pegasos2 so this means that we'll 
probably need rtas too (I hoped we could get away without it if it were 
only used for shutdown/reboot or so but seems Linux needs it for PCI as 
well and does not scan the bus and won't find some devices without it).

While VOF can do rtas, this causes a problem with the hypercall method 
using sc 1 that goes through vhyp but trips the assert in ppc_store_sdr1() 
so cannot work after guest is past quiesce. So the question is why is that 
assert there and would using sc 1 for hypercalls on pegasos2 cause other 
problems later even if the assert could be removed? Can somebody who knows 
more about it explain this please? If this cannot be resolved then we may 
need a different hypercall method on pegasos2 (I've considered MOL OSI or 
are there other options? I may use some advice from people who know it 
better, especially the possible interaction with KVM later as the long 
term goal with pegasos2 is to be able to run with KVM on PPC hardware 
eventually.) But this also means that if that assert cannot be dropped or 
there may be other problems with sc 1 hypercalls then we maybe cannot have 
the same vof.bin and we'll need a separate version that I would like to 
avoid if possible so if there's a simple way to keep it working or make 
vof.bin use alternate hypercall method without needing a separate binary 
that would be the direction I'd tend to go. Even if we need a seoarate 
version I'd like to keep as much common as possible.

I've tested that the missing rtas is not the reason for getting no output 
via serial though, as even when disabling rtas on pegasos2.rom it boots 
and I still get serial output just some PCI devices are not detected (such 
as USB, the video card and the not emulated ethernet port but these are 
not fatal so it might even work as a first try without rtas, just to boot 
a Linux kernel for testing it would be enough if I can fix the serial 
output). I still don't know why it's not finding serial but I think it may 
be some missing or wrong info in the device tree I generat. I'll try to 
focus on this for now and leave the above rtas question for later.

Regards,
BALATON Zoltan