QEMU mac99 emulates two of the three PCI buses found on real PowerMac3,1 but OpenBIOS currently only handles a single PCI bus and inits and puts info in the device tree of the second PCI bus only (which is where devices are connected). However, some clients (e.g. MorphOS) may have hardcoded assumptions and erroneously use the address of the first bus to access PCI config registers for devices on the second bus if the first bus is missing from the device tree, which silently fails as these requests will go to the other empty bus emulated and return invalid values as the device they address are not present there.
As a result devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this. One such case might be enabling bus master bit for network cards which the OS should do but OpenBIOS has workaround for it now. Once both PCI buses appear in device tree those workarounds may not be needed any more.
Until proper support for multiple PCI buses is implemented add an empty node in the device tree for the first bus on QEMU mac99 to let OSes know about it. This fixes detecting PCI devices (such as USB) under MorphOS and allows it to boot.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu --- arch/ppc/qemu/init.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 45cd77e..5e3959e 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -716,6 +716,44 @@ static void kvm_of_init(void) fword("finish-device"); }
+static void empty_pci_bus_init(void) +{ + if (machine_id == ARCH_MAC99) { + fword("new-device"); + push_str("pci"); + fword("device-name"); + push_str("pci"); + fword("device-type"); + PUSH(0xf0000000); + fword("encode-int"); + PUSH(0x02000000); + fword("encode-int"); + fword("encode+"); + push_str("reg"); + fword("property"); + PUSH(3); + fword("encode-int"); + push_str("#address-cells"); + fword("property"); + PUSH(2); + fword("encode-int"); + push_str("#size-cells"); + fword("property"); + PUSH(1); + fword("encode-int"); + push_str("#interrupt-cells"); + fword("property"); + PUSH(0); + fword("encode-int"); + PUSH(0); + fword("encode-int"); + fword("encode+"); + push_str("bus-range"); + fword("property"); + fword("finish-device"); + } +} + /* * filll ( addr bytes quad -- ) */ @@ -868,6 +906,8 @@ arch_of_init(void) case ARCH_MAC99_U3: /* The NewWorld NVRAM is not located in the MacIO device */ macio_nvram_init("/", 0); + /* We only handle 1 PCI bus but MorphOS needs info for both to boot */ + empty_pci_bus_init(); ob_pci_init(); ob_unin_init(); break;
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).
Regards, BALATON Zoltan
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.
ATB,
Mark.
On 02/10/2021 20:00, Mark Cave-Ayland wrote:
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.
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).
ATB,
Mark.
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
On Sat, 2 Oct 2021, BALATON Zoltan wrote:
Is there any guest OS in your test cases that this patch would break? If not
Ping? I know you're also busy with upstreaming q800 (great work by the way) but did you have a chance to test this? Or maybe I can help if you tell me what to test but I may bot have the same images you normally use.
Regards, BALATON Zoltan
On 14/10/2021 21:20, BALATON Zoltan wrote:
On Sat, 2 Oct 2021, BALATON Zoltan wrote:
Is there any guest OS in your test cases that this patch would break? If not
Ping? I know you're also busy with upstreaming q800 (great work by the way) but did you have a chance to test this? Or maybe I can help if you tell me what to test but I may bot have the same images you normally use.
I spent a few hours researching various device trees and testing the patch this morning. From what I can tell the bus numbers are scoped to the PCI host bridge (i.e. a single domain) and so the bus number 0 in the patch is valid: the bus numbers would only need to change if there were PCI-PCI bridges within the topology.
The main issue I found with the patch is that it causes some of my older Linux images to hang on boot :( The easiest way to reproduce this is booting QEMU with openSUSE-11.1-NET-ppc.iso like this:
./qemu-system-ppc -M mac99,via=pmu -cdrom openSUSE-11.1-NET-ppc.iso -serial stdio -boot d -m 512 -bios openbios-qemu.elf.nostrip -g 800x600x8
From the memory errors that get displayed with the patch applied my guess is that you need to come up with a suitable "ranges" property for your new PCI bus. Take a look at .host_ranges in arch/ppc/qemu/init.c and pci_host_set_ranges() in drivers/pci.c to see how this is created.
ATB,
Mark.
On Sat, 16 Oct 2021, Mark Cave-Ayland wrote:
On 14/10/2021 21:20, BALATON Zoltan wrote:
On Sat, 2 Oct 2021, BALATON Zoltan wrote:
Is there any guest OS in your test cases that this patch would break? If not
Ping? I know you're also busy with upstreaming q800 (great work by the way) but did you have a chance to test this? Or maybe I can help if you tell me what to test but I may bot have the same images you normally use.
I spent a few hours researching various device trees and testing the patch this morning. From what I can tell the bus numbers are scoped to the PCI host bridge (i.e. a single domain) and so the bus number 0 in the patch is valid: the bus numbers would only need to change if there were PCI-PCI bridges within the topology.
The main issue I found with the patch is that it causes some of my older Linux images to hang on boot :( The easiest way to reproduce this is booting QEMU with openSUSE-11.1-NET-ppc.iso like this:
./qemu-system-ppc -M mac99,via=pmu -cdrom openSUSE-11.1-NET-ppc.iso -serial stdio -boot d -m 512 -bios openbios-qemu.elf.nostrip -g 800x600x8
From the memory errors that get displayed with the patch applied my guess is that you need to come up with a suitable "ranges" property for your new PCI bus. Take a look at .host_ranges in arch/ppc/qemu/init.c and pci_host_set_ranges() in drivers/pci.c to see how this is created.
OK thanks I'll have a look if I can find the image.
Regards, BALATON Zoltan
On Sat, 16 Oct 2021, Mark Cave-Ayland wrote:
The main issue I found with the patch is that it causes some of my older Linux images to hang on boot :( The easiest way to reproduce this is booting QEMU with openSUSE-11.1-NET-ppc.iso like this:
./qemu-system-ppc -M mac99,via=pmu -cdrom openSUSE-11.1-NET-ppc.iso -serial stdio -boot d -m 512 -bios openbios-qemu.elf.nostrip -g 800x600x8
From the memory errors that get displayed with the patch applied my guess is that you need to come up with a suitable "ranges" property for your new PCI
I've sent a v8 that adds ranges property for the new device tree entry for the empty PCI bus. This fixes openSUSE boot and MorphOS still works too. I wonder if there are any other guests that have problems.
Regards, BALATON Zoltan
On Sat, 16 Oct 2021, BALATON Zoltan wrote:
On Sat, 16 Oct 2021, Mark Cave-Ayland wrote:
The main issue I found with the patch is that it causes some of my older Linux images to hang on boot :( The easiest way to reproduce this is booting QEMU with openSUSE-11.1-NET-ppc.iso like this:
./qemu-system-ppc -M mac99,via=pmu -cdrom openSUSE-11.1-NET-ppc.iso -serial stdio -boot d -m 512 -bios openbios-qemu.elf.nostrip -g 800x600x8
From the memory errors that get displayed with the patch applied my guess is that you need to come up with a suitable "ranges" property for your new PCI
I've sent a v8 that adds ranges property for the new device tree entry for the empty PCI bus. This fixes openSUSE boot and MorphOS still works too. I wonder if there are any other guests that have problems.
Ping? Freeze is coming and I'd like this to be resolved in QEMU 6.2.
Regards, BALATON Zoltan
On 22/10/2021 22:09, BALATON Zoltan wrote:
On Sat, 16 Oct 2021, BALATON Zoltan wrote:
On Sat, 16 Oct 2021, Mark Cave-Ayland wrote:
The main issue I found with the patch is that it causes some of my older Linux images to hang on boot :( The easiest way to reproduce this is booting QEMU with openSUSE-11.1-NET-ppc.iso like this:
./qemu-system-ppc -M mac99,via=pmu -cdrom openSUSE-11.1-NET-ppc.iso -serial stdio -boot d -m 512 -bios openbios-qemu.elf.nostrip -g 800x600x8
From the memory errors that get displayed with the patch applied my guess is that you need to come up with a suitable "ranges" property for your new PCI
I've sent a v8 that adds ranges property for the new device tree entry for the empty PCI bus. This fixes openSUSE boot and MorphOS still works too. I wonder if there are any other guests that have problems.
Ping? Freeze is coming and I'd like this to be resolved in QEMU 6.2.
I'm hoping to look at this later today, unfortunately it takes quite a bit of time to run a full test and this week has been fairly busy.
ATB,
Mark.
On Sat, 23 Oct 2021, Mark Cave-Ayland wrote:
On 22/10/2021 22:09, BALATON Zoltan wrote:
On Sat, 16 Oct 2021, BALATON Zoltan wrote:
On Sat, 16 Oct 2021, Mark Cave-Ayland wrote:
The main issue I found with the patch is that it causes some of my older Linux images to hang on boot :( The easiest way to reproduce this is booting QEMU with openSUSE-11.1-NET-ppc.iso like this:
./qemu-system-ppc -M mac99,via=pmu -cdrom openSUSE-11.1-NET-ppc.iso -serial stdio -boot d -m 512 -bios openbios-qemu.elf.nostrip -g 800x600x8
From the memory errors that get displayed with the patch applied my guess is that you need to come up with a suitable "ranges" property for your new PCI
I've sent a v8 that adds ranges property for the new device tree entry for the empty PCI bus. This fixes openSUSE boot and MorphOS still works too. I wonder if there are any other guests that have problems.
Ping? Freeze is coming and I'd like this to be resolved in QEMU 6.2.
I'm hoping to look at this later today, unfortunately it takes quite a bit of time to run a full test and this week has been fairly busy.
Thanks for you effort, let me know if there are any other guests that has a problem with this patch. Since the previous patched OpenBIOS to boot MorphOS does not work any more with current QEMU due to the escc changes I'd need to provide another patched version it this patch misses 6.2 which would be confusing for users to have two of these. So best would be if QEMU 6.2 would not need an out of tree patched OpenBIOS any more.
Regards, BALATON Zoltan
-
BALATON Zoltan -
Mark Cave-Ayland