| Message ID | 20090809211433.GA8892@1und1.de |
|---|---|
| State | Superseded |
| Headers | show |
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
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?).
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.
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);