Re: [Qemu-devel] [PATCH] Make rtl8139 network interface card compatible with Mac OS 10.4

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 02/01/16 04:00, Programmingkid wrote:

>> Well they are returning non-zero values, so that's good. After a bit
>> more poking, something doesn't make sense - in that same file
>> RTL8139::initPCIConfigSpace() claims to set the bus master bit, but if I
>> add tracing to hw/pci/pci-host.c then I don't see any writes to the PCI
>> command register outside of OpenBIOS? Any chance you can add debugging
>> to the before and after values for the reg16 variable which this
>> function claims to set?
>>
>> Also with similar tracing involved, apparently the writes to PCI I/O
>> space in order to access the chip registers are actually going through
>> pci_host_config_write(), i.e. configuration space rather than I/O space
>> which is why they aren't accessing the chip registers. So more digging
>> is required to figure out why this is happening.
>>
> 
> I added code to the initPCIConfigSpace() function that prints every register from 0 to 0x3e. All of the registers returned zero. My patch was fully applied when the driver printed all these values. I even had all the registers set to 0x99 then printed all the registers again. The registers all returned zero again. The driver was able to obtain the correct device, function, and bus numbers. PCI configuration space is not being accessed correctly by this driver. 

After some head scratching chasing this through for several hours
yesterday, I've worked out what is happening and have a patchset for
OpenBIOS which should fix the issue (will post later along with some
other PCI fixes for testing).

This is actually a bug in Darwin in that it doesn't parse the address
space part of the "ranges" property for the /pci node. OpenBIOS adds all
3 spaces to the "ranges" - configuration, I/O and memory compared to
real Macs which only add I/O and memory. Which is generally fine because
each entry contains a 2-bit indicator so that the OS knows which entry
represents each address space.

Except that Darwin evidently doesn't bother parsing the address space
from each "range" entry and blindly assumes that entry 0 is I/O space
and entry 1 is memory space as would be found in a real Mac device tree.
The result of this is that currently I/O accesses go to entry 0 (config
space) and memory accesses go to entry 1 (I/O space) which is why the
RTL8139 happens to work with your patch to force bus mastering.

AFAICT with basic testing here, forcing the /pci node to mimic that of a
real Mac by omitting the configuration space entry seems to fix all PCI
accesses (or at least they get routed to the correct address spaces), I
see an attempt to set the bus master bit in the command register, and I
don't get a reset timeout on startup for the RTL8139 anymore.


ATB,

Mark.