On 02/07/2019 12:28, BALATON Zoltan wrote:
On Mon, 1 Jul 2019, BALATON Zoltan wrote:
On Mon, 1 Jul 2019, Mark Cave-Ayland wrote:
Errr... I did spend time making the OpenBIOS bridge code generic so that others could use it, so the theory says that all you have to do is feed in an initial value. If we need workarounds then I accept that these are necessary at times, but cases like this where the work is already done then there is no need for this.
If you think it's trivial to do then please come up with a patch or provide some detailed hints on what needs to be done because I was not able to find it. Where should I feed an inital value? The ob_pci_init() function has no parameter and adding one would require changing all callers that I can't test so I'd rather not do.
I've tried adding a bus_num field to arch struct and set bus from that in ob_pci_init() but then OpenBIOS hangs on startup.
That feels like the right approach, but there certainly shouldn't cause any change in behaviour. Can you push your code somewhere so I can take a look?
Also re-reading the patch I'm not sure that {0, 1} is correct under QEMU compared with a real Mac, since there is no PCI bridge present under /pci@f2000000?
I've also tried setting it to {1, 0} instead but same hang as above so I think OpenBIOS cannot handle anything but bus 0 so I gave up. I'm not going to try to debug this as my workaround works well and all this would be unnecessary when passing device tree from QEMU is implemented as suggested before (that would be needed to support Pegasos2 without too many new hacks and workarounds in OpenBIOS and clean up some of the current mess so would be needed eventually if we want to avoid having yet another open firmware implementation in QEMU). But until then having a workaround to be able to run MorphOS without extra effort would have been nice unless it breaks somthing else.
So just to clarify you're saying that with your v5 patch if you simply switch {0, 1} to {1,0} then that also hangs? Also as discussed before it's not that I'm completely against an FDT-based setup, but it's an awful lot of work...
ATB,
Mark.