On Sat, 2 Oct 2021, Mark Cave-Ayland wrote:
On 02/10/2021 15:52, BALATON Zoltan wrote:
Hello,
This is still the same patch I'm draggging around for more than 3 years rebased to curent version and is still needed to boot MorphOS on QEMU mac99. People doing that so far used my patched version from 3 years ago (see http://zero.eik.bme.hu/~balaton/qemu/amiga/#morphos ) but it has stopped working with the recent escc reset changes so now MorphOS cannot be booted on QEMU mac99. It would be nice if QEMU 6.2 would come with an OpenBIOS that can boot MorphOS as that would avoid confusion and inconvenience for users with the upcoming QEMU 6.2 version to either having to get another patched OpenBIOS binary or change their scripts to use pegasos2 instead (which may nave other yet undiscovered problems when they've already learned to live with the mac99 version). So unless correct handling of both PCI busses can be fixed in OpenBIOS for QEMU 6.2, please consider this work around until that finally happens. If this breaks any of your test cases I'd try to look at that and fix it but I don't have time to make large changes in OpenBIOS such as trying to implement multiple PCI buses (tried that before and it was beyond the effort I could invest in this; we could dig up the details in the list archives but I think calling ob_pci_init with anything than bus == 0 does not work).
IIRC the last time you posted the patch my comment was that I would be happy to take the patch as-is, as long as the extra PCI bus is added to the QEMU mac99 machine beforehand. Device trees shouldn't be advertising devices that don't exist within the machine, since the existence of a device node will indicate that guest OSs should try to probe for it and the behaviour when the device doesn't exist is undefined.
It already exists (in fact there's even a third one too but that's the AGP bus we don't care about):
$ qemu-system-ppc -M mac99,via=pmu -S -monitor stdio QEMU 6.1.50 monitor - type 'help' for more information (qemu) info qtree [...] dev: uni-north-pci-pcihost, id "" gpio-out "" 4 ofw-addr = 4060086272 (0xf2000000) x-config-reg-migration-enabled = true bypass-iommu = false mmio 00000000f2800000/0000000000001000 mmio 00000000f2c00000/0000000000001000 mmio ffffffffffffffff/0000000010000000 mmio ffffffffffffffff/0000000000800000 bus: pci.2 type PCI dev: sungem, id "" dev: VGA, id "" dev: pci-ohci, id "" dev: macio-newworld, id "" dev: uni-north-pci, id "" [...] dev: uni-north-internal-pci-pcihost, id "" gpio-out "" 4 x-config-reg-migration-enabled = true bypass-iommu = false mmio 00000000f4800000/0000000000001000 mmio 00000000f4c00000/0000000000001000 bus: pci.1 type PCI dev: uni-north-internal-pci, id "" addr = 0e.0 romfile = "" romsize = 4294967295 (0xffffffff) rombar = 1 (0x1) multifunction = false x-pcie-lnksta-dllla = true x-pcie-extcap-init = true failover_pair_id = "" acpi-index = 0 (0x0) class Host bridge, addr 00:0e.0, pci id 106b:001e (sub 1af4:1100) dev: uni-north-agp-pcihost, id "" gpio-out "" 4 x-config-reg-migration-enabled = true bypass-iommu = false mmio 00000000f0800000/0000000000001000 mmio 00000000f0c00000/0000000000001000 bus: pci.0 type PCI dev: uni-north-agp, id ""
MorphOS seemingly probes the buses in order it founds them in the device tree but disregarding the addresses in the device tree and if it only finds one bus then it happily uses that for all PCI devices (but with addresses corresponding to the first bus) whereas devices are on the second PCI bus (AGP may be handled separately, or would come after the PCI busses so does not cause a problem.I don't really know).
Since the requests sent to the first bus don't fail completely as there is a PCI bus at that address it won't crash but the requests don't reach the devices so most PCI devices won't work, such as USB keyboard and mouse won't be found and while network card is found vis MMIO it won't set bus master bit in PCI config (it tries but sends it to the wrong PCI bus). This is why we added this in OpenBIOS but may not be needed after PCI busses are represented in the device tree. If there are two PCI buses in the device tree then MorphOS finds both and if the order is right (the empty one comes first and the one with the devices next) then it also works. Maybe it has the addresses hardcoded and assigns them to PCI bus numbers in order it finds PCI buses in the device tree? But if there's only one PCI bus in the device tree, no matter if addresses are correct it will detect a bus but use addresses corresponding the other empty bus. It will only send requests to correct address if it's the second bus it finds. Likely it expects two buses and has some asumptions which break if the device tree is not quite like on real machine.
On Sat, 2 Oct 2021, Mark Cave-Ayland wrote:
And also while I remember: this is assuming that the bus numbers are correct according to a reference device tree (I can't remember the exact outcome of the discussion as to whether each bus number is unique beneath the host bridge or throughout the entire device tree).
I don't remember either but looking back the previous thread about it, I've tried numbering the buses differently and it did not work with other combinations.
Is there any guest OS in your test cases that this patch would break? If not then we could postpone the question about what's the right numbering as that could always be fixed later.
Regards, BALATON Zoltan