qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Make rtl8139 network interface card compatible


From: Programmingkid
Subject: Re: [Qemu-devel] [PATCH] Make rtl8139 network interface card compatible with Mac OS 10.4
Date: Fri, 1 Jan 2016 23:00:25 -0500

On Dec 31, 2015, at 1:56 PM, Mark Cave-Ayland wrote:

> On 31/12/15 18:26, Programmingkid wrote:
> 
>>> Yeah, I see that too. Given that you have the source to the Apple
>>> RTL8139 driver at hand, can you try with a patched OpenBIOS using the
>>> bus master patchset on the mailing list and also add some debugging to
>>> your copy of
>>> http://www.opensource.apple.com/source/AppleRTL8139Ethernet/AppleRTL8139Ethernet-141/RTL8139.cpp
>>> or similar like this to display the csrMap and csrBase variables:
>>> 
>>> 
>>> // Get the virtual address mapping of CSR registers located at
>>> // Base Address Range 0 (0x10).
>>> 
>>> csrMap = pciNub->mapDeviceMemoryWithRegister( kIOPCIConfigBaseAddress1 );
>>> 
>>> DEBUG_LOG("csrMap: %x\n", csrMap);
>>> 
>>> if ( 0 == csrMap )
>>>   break;
>>> 
>>> csrBase = (volatile void*)csrMap->getVirtualAddress();
>>> 
>>> DEBUG_LOG("csrBase: %x\n", csrBase);
>>> 
>>> 
>>> At the very least these should give the addresses that the driver is
>>> trying to use in order to access the chip. If you can try this both
>>> before and after swapping the BARs over in QEMU that would be great.
>> 
>> Here are the results.
>> 
>> Values with my patch fully applied (with pci_dma_read() change):
>> csrMap: 0x270b3c0
>> csrBase: 0x20f8e000
>> 
>> I then kextunload'ed the kernel extension and loaded it again. Here are the 
>> values:
>> csrMap: 0x270ffc0
>> csrBase: 0x20f8c000
>> 
>> 
>> Values with only the RTL8139.c changes applied (no pci_dma_read() change):
>> csrMap: 0x1177740
>> csrBase: 0x1f5bf000
>> 
>> After unloading and loading the kernel extension:
>> csrMap: 0x11776c0
>> csrBase: 0x1f5d6000
> 
> 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. 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]