Patchwork Intel 8255x/eepro100 compatibility patches

login
register
mail settings
Submitter Reimar Döffinger
Date Aug. 9, 2009, 9:14 p.m.
Message ID <20090809211433.GA8892@1und1.de>
Download mbox | patch
Permalink /patch/31045/
State Superseded
Headers show

Comments

Reimar Döffinger - Aug. 9, 2009, 9:14 p.m.
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
From cdd96658f21e571c077fee08a4ba64e79d49c0b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Reimar=20D=C3=B6ffinger?= <reimar@hokum.(none)>
Date: Sun, 9 Aug 2009 21:36:45 +0200
Subject: [PATCH 1/4] Setting the MDI SCBAck flag when interrupts for MDI are disabled is
 wrong, even if it does not seem to cause any real issue with known
 drivers.

---
 hw/eepro100.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)
Stefan Weil - Aug. 10, 2009, 4:36 a.m.
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
Reimar Döffinger - Aug. 10, 2009, 6:42 a.m.
On Mon, Aug 10, 2009 at 06:36:58AM +0200, Stefan Weil wrote:
> 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.

I'll see if I can find some time, but after a quick look I don't think
it has any changes relevant in this case, and the patches even apply
cleanly.
I also remembered another strangeness: MDI reads never generate an
interrupt (the corresponding flag is ignored), was that code (MID
interrupts) ever tested with some real-world driver (I expect there
is no driver using that feature?).
Reimar Döffinger - Aug. 17, 2009, 7:47 a.m.
On Mon, Aug 10, 2009 at 06:36:58AM +0200, Stefan Weil wrote:
> 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.

Any hints on what those are? The only ones not in upstream seem mostly
cosmetic to me (not that they aren't a good idea), and changing the
VM save format, which I think should better wait for further changes,
e.g. most of the statistics stuff should not be saved because it is not
and for what I can tell stuff like rx_crc_errors never will be used (not
to mention the "complete" thing which makes no sense at all to store).
I'd suggest a patch, but my local tree is a bit too much of a mess with
all those pending patches that I am too lazy.

Patch

diff --git a/hw/eepro100.c b/hw/eepro100.c
index ec31a6a..bf5d920 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1043,9 +1043,7 @@  static void eepro100_write_mdi(EEPRO100State * s, uint32_t val)
             }
             data = s->mdimem[reg];
         }
-        /* Emulation takes no time to finish MDI transaction.
-         * Set MDI bit in SCB status register. */
-        s->mem[SCBAck] |= 0x08;
+        /* Emulation takes no time to finish MDI transaction. */
         val |= BIT(28);
         if (raiseint) {
             eepro100_mdi_interrupt(s);