From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32642 invoked by alias); 2 Jun 2008 16:03:40 -0000 Received: (qmail 32633 invoked by uid 22791); 2 Jun 2008 16:03:39 -0000 X-Spam-Check-By: sourceware.org Received: from d5152C2DE.access.telenet.be (HELO lx-dmz.televic.com) (81.82.194.222) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 02 Jun 2008 16:03:21 +0000 Received: (qmail 17127 invoked from network); 2 Jun 2008 16:03:19 -0000 Received: from nt-email.televic.com (10.0.0.9) by lx-dmz.televic.com with SMTP; 2 Jun 2008 16:03:19 -0000 Received: from [127.0.0.1] ([10.0.56.49]) by nt-email.TELEVIC.COM with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jun 2008 18:03:18 +0200 Message-ID: <484419C6.7020302@televic.com> Date: Mon, 02 Jun 2008 16:03:00 -0000 From: =?ISO-8859-1?Q?J=FCrgen_Lambrecht?= User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andrew Lunn CC: ecos-discuss@sources.redhat.com References: <369C2E4EDB94C34881A8178BEA192A12052481@nt-email.TELEVIC.COM> In-Reply-To: <369C2E4EDB94C34881A8178BEA192A12052481@nt-email.TELEVIC.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] bugs in AT91 Ethernet driver X-SW-Source: 2008-06/txt/msg00005.txt.bz2 Lambrecht Jürgen wrote: >> -----Original Message----- >> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss- >> owner@ecos.sourceware.org] On Behalf Of Lambrecht Jürgen >> Sent: zondag 1 juni 2008 1:22 >> To: Andrew Lunn; I-Yanaslov >> Cc: ecos-discuss@sources.redhat.com >> Subject: RE: [ECOS] bugs in AT91 Ethernet driver >> >> ... >> The AT91SAM9620 has only 2 SRAMs of 4kB each. >> (The AT91SAM9621 has 160kB of SRAM, but no EMAC and LCD controller >> instead) >> So it will have to be the last option. >> To have a reliable driver, the fix is needed, but that (errata) is not >> why my TX does not work. >> The AT91SAM9620 errata is only valid at heavy network load (when there >> is RX and TX at the same time and then an SDRAM refresh or SDRAM bank >> opening or so). I only do a ping on a private network for test. >> And moreover, the Ethernet driver works in Redboot RAM (ok, not that >> well, 9% of the pings get lost). >> >> I will further debug tomorrow... >> > In attachment ' if_at91_jtagram_ecos1.01.06_sg1TXsram1.txt ' with a log. > It was compiled with if_at91.c patched as below. > You can see that at startup a gratuitous ARP is sent out, and I receive the packet on my laptop with Wireshark. > The next TX (ARP reply as reply on RX of ARP request) is sent out by the TCP/IP stack, but does not leave the board as I don't see it in Wireshark. > It gets stuck somewhere. Maybe the driver is waiting on something, or maybe the TX DMA is blocked?? > > During debugging, I see that 'priv->tx_busy' stays 'true', because the TX-Complete bit (COMP of TSR reg) is never set - I also see that the TX-Used Bit Read (UBR of TSR reg) is set, which is normal I think because the TX buffers have not yet been released (because COMP is not set..). But the TX-GO bit is 0, meaning that transmit is not busy. I added code to release the TX buffers and to clear 'priv->tx_busy' when TX-GO is read 0. Then at each ARP request, there is an ARP reply, but it does not get out.. (monitoring with Wireshark) What's happening - it is like the EMAC TX is blocked, but why? Regards, Juergen -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss