[OpenBIOS] [PATCH 3/4 v2] arch/ppc/qemu: Add a node for the other (empty) PCI bus to the device tree

[BALATON Zoltan]

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 at 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