Re: [ECOS] AT91 EMAC Ethernet driver RX mangles packet data ??

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

Hello Ivan and Andrew,

I am still struggling with the driver.
The TX is OK.
The RX seems OK, but I have *DMA problems*: the EMAC looses packets, and 
then the OVR bit (Receive Overrun) in the RSR register is set. This 
means "The DMA block was unable to store the receive frame to memory, 
either because the bus was not granted in time or because a not OK 
hresp(bus error) was returned."

I have the same OVR errors in RedBoot (data load via TFTP) as in my 
TCP/UDP echo application.

I have instruction cache enabled, but the MMU is not enabled, so also 
the data cache is not enabled then.
You say Ivan that the Linux port works.
Is it correct that the MMU and data cache are enabled in Linux, but not 
in eCos?

Here some interesting test results. I test now with Redboot RAM by doing 
'load -r -b %{FREEMEMLO}420kB.bin' (default to my laptop).
- receive buffer of 4kB in SDRAM:
 => at average 20 times an OVR (with packet loss)
- receive buffer of 4kB in SDRAM; changed BusMatrix settings for EBI 
(SDRAM) slave: EMAC set as Fixed Default Master with Fixed Priority 
Arbitration, and EMAC has highest priority (on 
https://linuxlink.timesys.com/forum/2119, this was done to avoid TX 
underrun)
 => at average 9 times an OVR (with packet loss). So a good improvement
- receive buffer of 4kB in SRAM0
 => at average 0.5 times an OVR (with packet loss). So almost OK.
- receive buffer of 4kB in SRAM0; changed BusMatrix settings for SRAM0 
slave: EMAC set as Fixed Default Master with Fixed Priority Arbitration, 
and EMAC has highest priority; also tried setting ARM-Data as Fixed 
Default Master
 => no difference
- load from my test PC (windows also, but with I have shut down all 
useless services and programs):
 => 20 to 50 OVR errors!

Below some answers to my own questions.

Jürgen Lambrecht wrote:
> Jürgen Lambrecht wrote:
> > Hello,
> >
> > my current driver works fairly will. If I do UDP or TCP separate it 
> > works perfectly (only in release mode, else RX BNA and OVR errors): 
> > up to 28 Mbps for UDP with my echo program. I use bursts up to 64 kB 
> > - my RX uses 512 128B buffers.
> The problem now is in the RX part of the driver. My last modification 
> to the ecos-CVS version dates from May 31:
> http://ecos.sourceware.org/ml/ecos-discuss/2008-05/msg00134.html
> (2 small bugfixes)
> > But If I mix UDP with TCP (send both echo requests out in a burst), 
> > if fails very fast - even without big bursts: I send UDP 1 kB and TCP 
> > 1 kB packet echo request in a burst.
> > -> This crashes the EMAC Ethernet driver! All networking does not 
> > work anymore, not a ping, not the httpd server..
> > But my application still runs (It still toggles the watchdog LED), so 
> > only the networking part has crashed.
> >
> > Why?
> > - memcopy problem because freeBSD uses sg_list's where the first 
> > array is only 14 B, so not aligned anymore to 32 bit boundaries
no, memcpy() handles this OK
> > - the deliver() runs in a thread context, not DSR context. The 
> > resources are not protected by a mutex, so maybe 2 instances of 
> > deliver ...
no: there is only 1 thread that for both RX and TX calls the deliver() 
function (thread in /io/eth/current/src/net/)
> > I will of course investigate this further, but maybe already somebody 
> > has a clue?
Why did the EMAC driver crash after a BNA or OVR receiver error?
Because the EMAC recovers only the active buffer, not the previous ones 
(if the packet is bigger than 128B).
Solution: after having found a SOF (start-of-frame), and while looking 
for an EOF (end-..) you have to check for a new SOF and recover the 
previous buffers if this happens.
Now the EMAC driver never crashes anymore.
(Mark that the original driver was based I think on the Linux driver for 
the AT91RM9000, and the EMAC there uses big RX buffers, only 1 per 
packet, so no buffers to recover.)
I will commit this in a proper way, but it will need some time. If 
somebody wants my driver, mail me.
> > Kind regards,
> > Jürgen 
the same again


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss