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

[BALATON Zoltan]

On Mon, 2 Jan 2017, Mark Cave-Ayland wrote:
> As USB hasn't previously been working that well on mac99, I must confess
> that it's not something I routinely test. If you think that adding a USB
> mouse/keyboard is enough then I can include that as part of my tests?

I'm not sure USB is completely fixed yet (as the error about init-ing 
ohci_hcd in your SUSE test suggests) but the goal of my patch was to make 
USB mouse work and found that previously the USB hardware was not 
initialised correctly because it was trying to poke PCI config registers 
on the other empty bus address and failing as these did not get to the 
emulated card. Adding both bus to the device tree made the driver find the 
card and USB keyboard and mouse started working in MorphOS. Linux may be 
missing some more and MacOS seemed to work even without this patch.

> Yes you could be right here. The one thing I did think was strange was
> that both the original and new /pci nodes have a bus range of 0 which
> could lead to some confusion?

Maybe but I don't know how these properties are really used. Also the 
first bus may not be completely emulated by QEMU so I've only added enough 
of the device tree node so that the OS knows there is a (possibly 
non-working) bus there and then goes on to the second bus with the 
devices. (Otherwise it might try to set up AGP at the first bus and I'm 
not sure that is emulated by QEMU yet.)

> Probably the simplest option here is to hook is_newworld() into Forth
> using bind_func() as "is-newworld"?

That looks ugly just for using it at one place. It looks better to me to 
move the patch to C instead. Ideally we should have less Forth-C bindings 
not more I think.

> There was a recent thread about this with Thomas and my takeaway from
> this was that since the DT binds many functions (and not just
> properties) into the DT that it's not clear this would be much of a win.
> Feel free to pick up the thread at
> https://www.coreboot.org/pipermail/openbios/2016-November/009846.html if
> you have any further thoughts.

I have saved that message for replying it later, I'll try to summarise my 
thoughts on this. Of course the idea is only to provide a skeleton fdt 
from QEMU describing the devices emulated, then OpenBIOS would convert it 
to its own format and add funtions, nodes or other details as needed. The 
win would be that this tree would always be in sync with what QEMU 
emulates without needing to change OpenBIOS whenever something in QEMU is 
changed. (Eventually we could also get rid of the several FW_CFG and hard 
coded values in OpenBIOS as these could be added by QEMU matching what's 
emulated so it also simplifies OpenBIOS.)

Regards,
BALATON Zoltan