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

[Mark Cave-Ayland]

On 30/12/15 17:50, Programmingkid wrote:

>> Okay. I've just posted a revised patchset to the OpenBIOS list which may
>> (or may not) help, so please test with that aswell to see if it makes a
>> difference.
> 
> I have test your patch set. First I disabled my change to the pci_dma_read() 
> function. Then I activated my change to the rtl8139.c file. The nic didn't 
> work. The driver detected the nic, but DHCP did not set it up. Disabling my 
> change to the rtl8139.c file causes a timeout message to be printed by the 
> driver. 
> 
> When I was doing my research, I did a test where I changed the call to 
> memory_region_set_enabled() in do_pci_register_device() to set everything to 
> true instead of false. The MemoryRegion's enabled property was false by the 
> time the RTL8139 tried using the pci_dma_read() function. I think something 
> might be setting the enabled variable to false for some reason.

I've managed to get something reasonably similar here with my Darwin
image, and with the new OpenBIOS patchset then I get chip reset errors
similar to you - but if I then just apply the BAR swap part of your
patch then the error seemingly goes away. So this seems to confirm that
the OpenBIOS patchset is doing the right thing and the call to
memory_region_set_enabled() isn't required.

>>>> It looks like we have to face up to the reality that Apple's OF
>>>> implementation likes to enable bus mastering for some cards and emulate
>>>> this behaviour in OpenBIOS, since because of this some drivers don't
>>>> explicitly enable bus mastering and so fail under emulation.
>>>>
>>>> I'll go back and revisit Zoltan's patches to see if we can come up with
>>>> something that works better for OpenBIOS upstream. In the meantime I
>>>> still can't quite work out why you still need to swap the BARs around as
>>>> AFAICT both the mmio and io BARs are mapped onto the chip registers -
>>>> any chance you could add some debugging to QEMU in order to figure out
>>>> what is going wrong without your patch?
>>>
>>> I have done a lot of debugging. With only the pci_dma_read() change applied 
>>> to QEMU, nothing the Mac OS X driver does ever accesses any of the 
>>> functions from the rtl8139.c file (as far as I can tell). I will add that 
>>> when this code "if ( csrRead8( RTL_CM ) & R_CM_RST )" is executed by the 
>>> driver, the value is 16. It appeared to be pretty consistent. The value 
>>> returned by just "csrRead8( RTL_CM )" is 24. 
>>
>> Right, so then the question to ask is what is the difference in
>> behaviours both before and after the BAR swap? It seems that you're
>> getting a value back but presumably it must be a different value with
>> your patch applied.
> 
> The difference is I see activity in the RTL8139.c file when I made the swap. 
> Without the change, none of the I/O functions in the RTL8139.c file are 
> called.
> 
> This is what I did. I added this code "printf("RTL8139: %s() called\n", 
> __FUNCTION__);" to these functions in the rtl8139.c file: 
> rtl8139_mmio_writeb()
> rtl8139_mmio_writew()
> rtl8139_mmio_writel()
> rtl8139_mmio_readb()
> rtl8139_mmio_readw()
> rtl8139_mmio_readl()
> rtl8139_ioport_write()
> rtl8139_ioport_read()
> 
> If a register read and write from the driver doesn't access one of these 
> functions, what else could it be accessing? 

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.


ATB,

Mark.