This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> -----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
Attachment:
if_at91_jtagram_ecos1.01.06_sg1TXsram1.txt
Description: if_at91_jtagram_ecos1.01.06_sg1TXsram1.txt
Attachment:
if_at91_udiff.txt
Description: if_at91_udiff.txt
-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |