On 02/01/16 17:08, Programmingkid wrote: >> 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.
I've just posted the OpenBIOS patches to the list (see http://www.openfirmware.info/pipermail/openbios/2016-January/008959.html). Please test and let me know if this solves your networking problems against a vanilla QEMU git master checkout - it looks good in the logs, but I can't quite figure out how to manually bring up a new en0 interface in Darwin from the command line. ATB, Mark.
