On Jan 2, 2016, at 4:39 AM, Mark Cave-Ayland wrote: > 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.
Wow, you figure out stuff fast! Will be waiting for your patches.