[ECOS] bugs in AT91 Ethernet driver

Lambrecht Jürgen J.Lambrecht@TELEVIC.com
Sun Jun 1 21:36:00 GMT 2008


> -----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
> 
> Thanks for your replies.
> 
> > -----Original Message-----
> > From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> > owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
> > Sent: zaterdag 31 mei 2008 14:04
> > To: I-Yanaslov
> > Cc: Andrew Lunn; ecos-discuss@sources.redhat.com
> > Subject: Re: [ECOS] bugs in AT91 Ethernet driver
> >
> > On Sat, May 31, 2008 at 03:49:24PM +0400, I-Yanaslov wrote:
> > >
> > >> However, you are wrong about the TX buffers being on the heap. The
> > >> buffer is inside the at91_eth_priv_t structure. This is allocated
> at
> > >> the end of if_at91.c. It will be placed in the data segment.
> > >
> > > at91_eth_priv structure is contains only RX buffers, RX buffer
> > > descriptors and "TX buffer descriptors". No contains "TX buffers".
> > >
> > > at91_eth_send() shows " priv->tbd[priv->curr_tbd_idx].addr =
> > > sg_list[i].buf; " - no memory copy, only address assigment.
> > > But, sg_list[] it is mbuf, dynamically allocated in TCP/IP stack.
> >
> > Ah, OK. My error. That makes it more messy.
> >
> > How big is the SRAM on these ARM9 devices? 32K, 64K? If it is big
> > enough maybe we can move net_mbufs_area[] into the SRAM. Otherwise a
> > copy is needed for every packet to be transmitted.
> >
> 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??

> And then copy every packet to SRAM before doing DMA...
> 
In attachment my patch.
It contains
- in at91_eth_send(): modification (#ifdef SRAM1_ORIGIN) to copy sg_list[i].buf first to internal SRAM, and only then do a DMA to the EMAC
- in at91_eth_recv(): bugfix described in previous mail
- general: I don't have a PHY attached but a switch. The MII is always up at 100Mbps, so no need to use SMI to read the link status in the phy registers. So put '#ifdef PHY_PRESENT' around those parts of the code

I tested it with my AT91SAM9620-EK based board. And it works just as before (see above).

Kind regards,
Juergen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: if_at91_jtagram_ecos1.01.06_sg1TXsram1.txt
URL: <http://sourceware.org/pipermail/ecos-discuss/attachments/20080601/0576fa1b/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: if_at91_udiff.txt
URL: <http://sourceware.org/pipermail/ecos-discuss/attachments/20080601/0576fa1b/attachment-0001.txt>
-------------- next part --------------
-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


More information about the Ecos-discuss mailing list