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

[Programmingkid]

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?

You are right! Good job catching this! The value before the write is 0. The 
value after the write is still 0. The value it should be after the write is 21. 

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


Which target are you using: mac99 or g3beige. I use the g3beige target. Mac OS 
10.4 is not suppose to be able to run on this machine, so I wonder if that has 
something to do with it. I did try to run Mac OS 10.4 in the mac99 target, but 
it just does not run very well there. It was unusable. The mouse didn't seem to 
work right. The console application didn't even load. I had to give up on that 
target.

I do still plan on reviewing your patch set for fixing booting on the mac99 
target. I just haven't found the time to do it yet.