[OpenBIOS] [PATCH 3/4] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree

[BALATON Zoltan]

On Sat, 31 Dec 2016, Mark Cave-Ayland wrote:
> I've given this a spin around my PPC images and I don't see any
> regressions so I think this is going in the right direction - I think it

Good to hear. Have you also tested if it makes a difference with irq-s on 
mac99? I've found that USB irq-s did not work correctly without this patch 
so it may help with problems with that (e.g. sound and mouse problems) and 
likely makes the patch in OpenBIOS to set the bus master for RTL8139 
unnecessary as well but I haven't tested these.

> may need a couple of minor tweaks though.
>
> Firstly, I now see the following PCI BAR warnings on boot for my old
> openSUSE 11 boot ISO (openSUSE-11.1-NET-ppc.iso):
[...]
> I/O resource not set for host bridge 0
> Memory resource not set for host bridge 0
> pci 0001:10:0e.0: BAR 0: can't allocate mem resource [0x0-0xffffff]
> pci 0001:10:0c.0: BAR 0: can't allocate mem resource [0x0-0x7ffff]
> pci 0001:10:0f.0: BAR 6: can't allocate mem resource [0x82040000-0x8207ffff]
> pci 0001:10:0e.0: BAR 6: can't allocate mem resource [0x82010000-0x8201ffff]
> pci 0001:10:0e.0: BAR 2: can't allocate mem resource [0x0-0xfff]
> pci 0001:10:0d.0: BAR 0: can't allocate mem resource [0x0-0xff]
> ohci_hcd 0001:10:0d.0: init 0001:10:0d.0 fail, -16

Maybe these were silently failing before but I'm not sure what it is. It's 
hard to see these messages on normal boot as it seems to be printing dark 
gray text on black. Is there some way to get output on serial and enable 
more detailed logs? I'm not familiar with openSUSE on PPC or yaboot.

I've also noticed this color problem with Finnix and wonder how this shows 
up on real Macs. I thought Macs have a light background by default but 
this happens after the boot loader has cleared the screen and set up its 
own colors so maybe it's not the default background but there's a problem 
somewhere later. (After all the OpenBIOS background is also light but 
it's cleared black before the text is printed.)

> So perhaps you might need to fake up a few extra properties to get rid
> of the warnings on boot?

I'm not sure. Maybe only the first two warnings for bridge 0 could be 
eliminated by that but the other warnings refer to cards on the second bus 
and not the one my patch touches. Maybe the patch just uncovers problems 
with the other bus that was hidden so far because these requests were 
previously sent to the first bus and got empty replies earlier before it 
could get to the place where the warnings are issued. These warnings may 
show that the cards are actually tried to be initialised now but there are 
some problems. These may need to be fixed somewhere else on the other bus 
not in the empty PCI bus my patch adds as that does not have these cards 
at all.

> Secondly while the address of the extra PCI node looks fine for -M mac99
> in the device tree, I'm not sure it is correct for -M g3beige:
[...]
> Perhaps the extra /pci node needs to be wrapped in an [IFDEF] block or
> similar so that it only appears for -M mac99?

It's likely wrong for g3beige but not sure an [IFDEF] would be enough to 
make it only appear on mac99. [IFDEF]s seem to test CONFIG_* options but 
mac99 is a runtime parameter so we would need a way to detect if we're 
running on mac99 or g3beige (the same openbios-elf.ppc compiled with the 
same CONFIG_* options can run on both so I can't use [IFDEF] for that). We 
would need to test the value of machine_id from arch/ppc/qemu/init.c for 
this but I'm not sure how to do that from Forth. Maybe moving the patch 
from Forth to C would be easier.

But instead of that we could also aim for a more complete solution and 
consider doing it similar to spapr and SLOF and generate an fdt in QEMU 
and pass it to OpenBIOS and patch/amend it as needed after converting to a 
usual device tree (we could use the code from SLOF for this). I've checked 
how it's done with spapr and there a call to the hypervisor is used to get 
the fdt. We don't have that but we already use FWCFG so we could use 
FW_CFG_SETUP_* to pass the fdt. I think this is doable but I'm still 
missing some details and haven't tried to implement it. What do you think 
about such a solution? Basiacally we would need to add creating the fdt 
and making it available via FWCFG to the mac machines in QEMU, then 
implement getting it and using it in OpenBIOS. This way we could also 
solve the problem of keeping OpenBIOS and QEMU in sync because a change in 
the fdt could be made entirely in QEMU without needing a corresponding 
change in OpenBIOS. Also adding new machines could be easier. This is a 
bigger task but maybe worth doing if it could make the current code 
cleaner.

Regards,
BALATON Zoltan