MCF5475 and FEC

[benoit]

Hello,

I have a problem with my FEC.
I use M5475EVB board with last uClinux. But there is not FEC by default, so I have past the LinuxBSP FEC of freescale on uClinux.
But it doesn’t work very well.

I have tested with ftp and the results are:

For a file of 10KBytes (5 tests):

• Data from PC(Mandriva) to m5475evb board: 5 to 16KBytes/s
• Data from m5475evb board to PC(Mandriva): 1024 to 1280KBytes/s

For a file of 100KBytes (5 tests):

• Data from PC(Mandriva) to m5475evb board: 0KBytes/s (transfer complete in 185s to 826s)
• Data from m5475evb board to PC(Mandriva): 20 to 2089KBytes/s

for a file of 1MBytes (5 tests):

• Data from PC(Mandriva) to m5475evb board: 25 to 27KBytes/s
• Data from m5475evb board to PC(Mandriva): 103 to 1835KBytes/s

Is very irregular and transfer is faster in a direction than in other.
Somebody knows where is the problem?

Thanks,
--benoit

[mccPaul]

Hi Benoit,

I have experience with the FEC on 52235 and 5282 and I believe that there is little difference with the 5475. I have driver code that can transmit data at over 90Mbit/s, but this is UDP packets which are not being created by the TCP/IP stack but they are being DMA'd direct to the FEC from external hardware.

The FEC driver is normally very simple, you just need to create frame buffers and then fill in buffer descriptors for the FEC. The FEC then transmits the frames at wire speed. If you have delays i ntransmission then this is caused either by collisions on the network (unlikely) or by your protocol stack.

For reception, the FEC driver is usually even simpler. A frame is receieved and passed directly to the stack for processing.

The erratic delays you are seeing are most likely due to the way that FTP has been implemented by the stack in uCLinux (no experience with uCLinux so no comment here). Where are you writing the files to in your device? If flash, then it may be much slower to write a file from a PC to your device than to read it.

To test the performance more reliably, I suggest that you try and remove as much stack and protocol induced delays by writing a small test application for creates and transmits UDP packets filled with program generated data. You also need another application that receives these packets. Both applications can count the transfer rate.

If you still have problems, post the source for the driver and I will compare the way it works with the driver code I have.

Cheers,

Paul.

[benoit]

Hi paul,

Thanks for your help.

I have tested with tftp which use UDP and I have gotten a "time out".

- uClinux is compiled with the uClinux m68k toolchain (gcc 4.1.1).
- I load kernel with colilo in RAM.

ifconfig on the board:
eth0      Link encap:Ethernet  HWaddr 00:11:22:33:44:50
         inet addr:192.168.100.2  Bcast:192.168.100.255  Mask:255.255.255.0
         UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:350 errors:0 dropped:0 overruns:0 frame:0
         TX packets:300 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
                   Interrupt:103 Base address:0x9000
         
and ifconfig on the PC:
eth0      Lien encap:Ethernet  HWaddr 00:80:C8:63:56:87
         inet adr:192.168.100.1  Bcast:192.168.100.255  Masque:255.255.255.0
         adr inet6: fe80::280:c8ff:fe63:5687/64 Scope:Lien
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:91797 errors:36 dropped:0 overruns:0 frame:35
         TX packets:92277 errors:24 dropped:0 overruns:0 carrier:24
         collisions:0 lg file transmission:1000
         RX bytes:5855291 (5.5 Mb)  TX bytes:52369614 (49.9 Mb)
         Interruption:11 Adresse de base:0xe400

After transmission of 100Ko with ftp, on the PC RX packets errors and frame is increased of 1.


And the drivers work very well in the freescale LinuxBSP.


I give you fec and dma drivers sources in attachment.

Thanks,

 benoit.

[mccPaul]

Hi Benoit,

There is nothing obvious in the driver code that would suggest a reason for slow tx or rx. I still suspect that the fault lies further up the stack. It looks as if a DMA transfer to the FEC will be completed with no delays (assuming that there are sufficient buffer descriptors in SRAM) so there seems to be no reason why the delays are caused by the FEC driver code.

You may be able to test this by starting a timer in the fec_tx() function of the FEC driver and then read the timer in fec_interrupt_fec_tex_handler() to see how long the DMA is taking (it may be easier to toggle a GPIO line and measure the time with a scope).

I still think that it is worth writing a small app that just sends and receives UDP packets without any copying, or file system involvment. Although TFTP uses UDP, there is still a fair amount of protocol and filesystem involvement. It may be that the version of uCLinux that you are using has a very slow filesystem implementation.

Cheers,

Paul.