qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches
Date: Mon, 10 Aug 2009 06:36:58 +0200
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)

Reimar Döffinger schrieb:
> Hello everyone,
> I have been playing around a bit with the OS X/darwin network drivers for 
> these
> cards and noticed that they seem to differ quite a bit from the Linux ones.
> If you're interested, the source of the core part is here:
> http://www.opensource.apple.com/source/AppleIntel8255x/AppleIntel8255x-19/i82557Private.cpp
> Attached is a series of patches that makes things work with at least
> some version of that (sorry, I only tried some binary I found on the
> net, didn't compile from source).
> In addition, I also used the documentation from here:
> http://www.intel.com/design/network/manuals/8255X_OpenSDM.htm
>
> The first patch does not set the SBAck flag for MDI interrupts when
> interrupts are actually disabled for MDI.
> I think (have not tested yet) that this is not necessary to fix
> anything, but according to the documentation the current code is wrong.
>
> The second patch is to ensure that a driver will not
> accidentally/incorrectly change the RU/CU state with a write.
> This is incomplete and a bit ugly, but good enough for these drivers.
>
> The third patch adds support for some kind of receive buffers "flexible
> mode". The Intel documentation as I read it claims that no such mode exist
> for receive, but the fact that those (working with real hardware I
> expect) drivers use it contradicts that...
> This _definitely_ is necessary to support these drivers.
>
> And the last patch expands received data shorter than 60 bytes so no
> short-frame detection is incorrectly triggered, and of course also
> throws away all short-frame detection code since it makes no sense.
> It was also wrong since size is without CRC and thus the short frame
> limit is 60, not 64. And related to that (but without a patch), I think
> that the
>   
>>    } else if ((size > MAX_ETH_FRAME_SIZE + 4) && !(s->configuration[18] & 
>> 8)) {
>>     
> check is wrong, too, and the + 4 should not be there...
> Back to the patch, e.g. the rtl8139 driver also expands those frames
> (and I just copied the code for that).
> This too _definitely_ is necessary to support these drivers.
>
> Hope this is interesting to someone and maybe we can even get these
> merged...
>
> Thanks,
> Reimar Döffinger
>   


Hi,

this is interesting to me. Maybe you want to try a newer version of
eepro100.c. The latest version is in http://repo.or.cz/w/qemu/ar7.git,
http://repo.or.cz/w/qemu/ar7.git?a=blob;f=hw/eepro100.c

It has some really important improvements. I want to get it ready
for inclusion in the official QEMU by the end of August.

Regards
Stefan Weil






reply via email to

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