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


ATB,

Mark.