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