Re: [ECOS] bugs in AT91 Ethernet driver

[Jürgen Lambrecht <J dot Lambrecht at televic dot com>]

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