[PATCH 3/4 v2] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree
QEMU emulates two of the three PCI buses found on real hardware because some clients seem to need both and fail with only one present, but OpenBIOS only handles a single PCI bus and initialises and puts in the device tree only one of these: the second one which is where devices are connected and also marks it bus 0. However, clients getting info from the device tree may not know about this and thinking there is only one PCI bus they erroneously use the address of the first bus to access PCI config registers for devices on the second bus which silently fails as these requests will go to the other empty bus emulated and return invalid values. Devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this.
Until support for multiple PCI buses is implemented add an empty node in the device tree for the uninitialised bus to let clients know about it. This is still not entirely correct as bus-range property does not match real hardware but this fixes detecting PCI devices (such as USB) under MorphOS and may also fix enabling the bus master bit needed with some network cards and allow the workaround for this to be reverted.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu --- arch/ppc/qemu/init.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
v2: Move to init.c from tree.fs and only add it for mac99 Patches 1 and 2 from original series https://www.coreboot.org/pipermail/openbios/2016-November/009825.html https://www.coreboot.org/pipermail/openbios/2016-November/009824.html are still valid and needed, patch 4 was already applied so only this one (3/4) is resent but 1 and 2 should be applied as well with this.
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index ffbf08d..629d71b 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -755,6 +755,44 @@ arch_of_init(void) openbios_init(); modules_init(); setup_timers(); + if (machine_id == ARCH_MAC99) { + /* Add empty node for first pci bus */ + /* Remove this when pci driver is fixed to handle multiple buses */ + activate_device("/"); + 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"); + device_end(); + } #ifdef CONFIG_DRIVER_PCI ob_pci_init(); #endif
On 11/01/17 23:08, BALATON Zoltan wrote:
QEMU emulates two of the three PCI buses found on real hardware because some clients seem to need both and fail with only one present, but OpenBIOS only handles a single PCI bus and initialises and puts in the device tree only one of these: the second one which is where devices are connected and also marks it bus 0. However, clients getting info from the device tree may not know about this and thinking there is only one PCI bus they erroneously use the address of the first bus to access PCI config registers for devices on the second bus which silently fails as these requests will go to the other empty bus emulated and return invalid values. Devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this.
Until support for multiple PCI buses is implemented add an empty node in the device tree for the uninitialised bus to let clients know about it. This is still not entirely correct as bus-range property does not match real hardware but this fixes detecting PCI devices (such as USB) under MorphOS and may also fix enabling the bus master bit needed with some network cards and allow the workaround for this to be reverted.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
arch/ppc/qemu/init.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
v2: Move to init.c from tree.fs and only add it for mac99 Patches 1 and 2 from original series https://www.coreboot.org/pipermail/openbios/2016-November/009825.html https://www.coreboot.org/pipermail/openbios/2016-November/009824.html are still valid and needed, patch 4 was already applied so only this one (3/4) is resent but 1 and 2 should be applied as well with this.
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index ffbf08d..629d71b 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -755,6 +755,44 @@ arch_of_init(void) openbios_init(); modules_init(); setup_timers();
- if (machine_id == ARCH_MAC99) {
/* Add empty node for first pci bus *//* Remove this when pci driver is fixed to handle multiple buses */activate_device("/");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");device_end();- }
#ifdef CONFIG_DRIVER_PCI ob_pci_init(); #endif
I'd say this is quite invasive for a hack - any chance that it can moved into a separate static function with an NEWWORLD(...) wrapper so it's easier to pull out when multi-bus PCI can be implemented?
Also does this do anything to address the extra warnings I noticed under openSUSE or is it still the same patch but converted to C?
ATB,
Mark.
On Fri, 27 Jan 2017, Mark Cave-Ayland wrote:
On 11/01/17 23:08, BALATON Zoltan wrote:>
QEMU emulates two of the three PCI buses found on real hardware because some clients seem to need both and fail with only one present, but OpenBIOS only handles a single PCI bus and initialises and puts in the device tree only one of these: the second one which is where devices are connected and also marks it bus 0. However, clients getting info from the device tree may not know about this and thinking there is only one PCI bus they erroneously use the address of the first bus to access PCI config registers for devices on the second bus which silently fails as these requests will go to the other empty bus emulated and return invalid values. Devices mapped via MMIO still appear to work but they may not be correctly initialised and some cards are not detected because of this.
Until support for multiple PCI buses is implemented add an empty node in the device tree for the uninitialised bus to let clients know about it. This is still not entirely correct as bus-range property does not match real hardware but this fixes detecting PCI devices (such as USB) under MorphOS and may also fix enabling the bus master bit needed with some network cards and allow the workaround for this to be reverted.
Signed-off-by: BALATON Zoltan balaton@eik.bme.hu
arch/ppc/qemu/init.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
v2: Move to init.c from tree.fs and only add it for mac99 Patches 1 and 2 from original series https://www.coreboot.org/pipermail/openbios/2016-November/009825.html https://www.coreboot.org/pipermail/openbios/2016-November/009824.html are still valid and needed, patch 4 was already applied so only this one (3/4) is resent but 1 and 2 should be applied as well with this.
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index ffbf08d..629d71b 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -755,6 +755,44 @@ arch_of_init(void) openbios_init(); modules_init(); setup_timers();
- if (machine_id == ARCH_MAC99) {
/* Add empty node for first pci bus *//* Remove this when pci driver is fixed to handle multiple buses */activate_device("/");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");device_end();- }
#ifdef CONFIG_DRIVER_PCI ob_pci_init(); #endif
I'd say this is quite invasive for a hack - any chance that it can moved
I think the whole device tree consruction currently in OpenBIOS is a hack which should mostly be moved to QEMU eventually but I don't have time for that now or in the near future. This does not make it much worse as whole of init.c is already full of patching up the device tree anyway.
into a separate static function with an NEWWORLD(...) wrapper so it's easier to pull out when multi-bus PCI can be implemented?
If you think that's better I can send a version which moves it to a separate function but NEWWORLD() also includes U3 based G5 emulated by qemu-system-ppc64 so it has to be (machine_id == ARCH_MAC99) to ensure it only affects ppc mac99. It also has to be before ob_pci_init() which sets up the other pci bus and the order of the entries seems to be significant that's why it's put where it is.
Also does this do anything to address the extra warnings I noticed under openSUSE or is it still the same patch but converted to C?
No, it's the same as the previous version just restricting the change to mac99 to not affect g3beige and ppc64 machines and looks longer in C than it was in Forth.
To find what's the problem with openSUSE the sources would need to be dug up but I didn't bother. The new warning may be caused by that now the code actually tries to init the OHCI controller and can talk to it whereas previously these went to the empty bus and were failing to get a reply from the card so the driver gave up before these warnings. Does it make it any worse than before? If not then it may be an improvement even if not a full fix but I'd leave that to someone else interested in this old SUSE version. This patch (with the other two) makes MorphOS one step closer to working though as OHCI and USB keyboard and mouse start working there. Also the RTL8139 bus master patch can be reverted.
Regards, BALATON Zoltan
-
BALATON Zoltan -
Mark Cave-Ayland