From patchwork Sun Aug 9 21:14:33 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Reimar_D=C3=B6ffinger?= X-Patchwork-Id: 31045 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bilbo.ozlabs.org (Postfix) with ESMTPS id 8787EB7B7D for ; Mon, 10 Aug 2009 07:15:24 +1000 (EST) Received: from localhost ([127.0.0.1]:47470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaFjb-0005Vl-Sv for incoming@patchwork.ozlabs.org; Sun, 09 Aug 2009 17:15:20 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaFj3-0005Ug-BZ for qemu-devel@nongnu.org; Sun, 09 Aug 2009 17:14:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaFix-0005S9-2U for qemu-devel@nongnu.org; Sun, 09 Aug 2009 17:14:43 -0400 Received: from [199.232.76.173] (port=36772 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaFiw-0005Rq-Q4 for qemu-devel@nongnu.org; Sun, 09 Aug 2009 17:14:38 -0400 Received: from mail.gmx.net ([213.165.64.20]:34321) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MaFiv-0001da-TP for qemu-devel@nongnu.org; Sun, 09 Aug 2009 17:14:38 -0400 Received: (qmail invoked by alias); 09 Aug 2009 21:14:34 -0000 Received: from p5B1348C1.dip.t-dialin.net (EHLO localhost) [91.19.72.193] by mail.gmx.net (mp050) with SMTP; 09 Aug 2009 23:14:34 +0200 X-Authenticated: #11956158 X-Provags-ID: V01U2FsdGVkX1+G6yM24VSGK4XWZ6Dn10k03R9rE5znu+iIQQqHWA LctAnwaebEH0pA Date: Sun, 9 Aug 2009 23:14:33 +0200 From: Reimar =?iso-8859-1?Q?D=F6ffinger?= To: qemu-devel@nongnu.org Message-ID: <20090809211433.GA8892@1und1.de> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: [Qemu-devel] [PATCH] Intel 8255x/eepro100 compatibility patches X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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?= 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(-) 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);