OMAP3530 EVM Ethernet Configuration?

msj said:

Does anyone know what the default Ethernet configuration is with the TI DVSDK dvsdk_3_00_01_42? 10Mbps? Full or Half duplex?

The driver will default to the highest supported rate between both the EVM and the switch/hub it is connected to, typically this would be 100baseT full duplex, older versions would print this during the boot sequence though I do not see it in there now. You can usually verify this by checking the status of the switch you are connected to, generally switches have LEDs that provide rate status.

msj said:

Is there a utility available for seeing what the configuration is? or for more info on why the connection is dropping packets?

This I am less sure of, on a Linux PC I have used ethtool to examine and tweak such settings however it is not present in the OMAP3 filesystem out of the box and I am not sure how easy it would be to rebuild it for the OMAP3, and it would only tell you what you should be able to see by looking at your switch's LEDs anyway. As to additional tools, you may find something like Ethereal to be useful in getting more information on what is happening as I hear this tool suggested often, however I have not worked with it myself.

For some potentially easier testing if you have other network hardware available you may want to try it out and use some different configurations, you may get different performance based on the switch/hub/router you have connected up to the EVM.

Hi Bernie,

Thanks for the reply.

The netgear switch(GS908) I am using in-fact does have LED's on the front panel. Unfortunately I have only been able to find speculation on the definition of the LED's, and it would lean toward the ether-net port being at 10Mbps half duplex.  So I was hoping to be able to confirm this via the omap evm side of things.

I have been looking at the ethtool, but am currently unsure how to cross compile/configure it for the ARM?  Maybe I'm missing something simple?

I am also pursuing finding other network hw, that may be able to give me some more information.  But it is kind of a bummer I can't tell what the omap is actually setting, from the omap.

I would also like to understand why, if in fact it is auto-negotiating down to 10M half-duplex?  this doesn't really make any sense, as the omap/phy should support higher speeds and the switch itself supports higher speeds.  Which makes me think something must be miss configured.

I am also using etherreal (wireshark) on the pc end of things, but this is downstream.  It does confirm I am losing a significant number of udp packets, which then points back to the packet drop count increasing on the omap RX port.

Thanks again for the input.  If you have links to cross compiling/configuring ethtool that would be great.

msj said:

The netgear switch(GS908) I am using in-fact does have LED's on the front panel. Unfortunately I have only been able to find speculation on the definition of the LED's, and it would lean toward the ether-net port being at 10Mbps half duplex.

I am not familiar with your particular switch (and I could not find documentation on it on a quick search) but in general the switches I have seen use a green light for their maximum transmission standard and an orange light for a lower standard, for a 10/100 switch this would be green at 100, and orange at 10, however I also have a gigabit 10/100/1000 switch that shows green at 1000 and orange at 100, and it can certainly vary by model. I can say that the OMAP3 EVM is capible of 100baseT interfacing, and that as long as your switch is also capible of this rate that it should be operating at that speed, for example mine does with a D-Link DES-1108.

msj said:

I have been looking at the ethtool, but am currently unsure how to cross compile/configure it for the ARM?  Maybe I'm missing something simple?

I have only used ethtool from the PC side, I am not sure how effective it would be to cross compile it, as there may need to be additional modifications to support its capabilities with the EVM's Ethernet controller. If all you want is conclusive proof of the operating mode it may be easier (assuming ethtool does not cleanly cross compile) to go add some printk statements to the driver source itself to identify its mode, it is possible they are already even in there and masked by some debug flag, however I have not dug into the Ethernet driver source myself.

The easiest way to verify would be to use a switch that has a more obvious 100baseT indicator, or to hook the board up to a PC with a cross over cable and check with ethtool on the PC side.

msj said:

I would also like to understand why, if in fact it is auto-negotiating down to 10M half-duplex?  this doesn't really make any sense, as the omap/phy should support higher speeds and the switch itself supports higher speeds.  Which makes me think something must be miss configured.

This is possible but not typical, if the autonegotiation is really failing I would try out another switch to see if you can get any noticable difference, as mentioned above I am getting 100baseT full duplex with my particular switch, I have also gotten 100baseT with a few other switches I have tried, I have only seen it drop down to 10baseT half duplex if I use a particularly old 10baseT Ethernet hub, so at least for me with the out of the box setup the auto negotiation appears to work. On the other hand I am not really running any sort of bandwidth stress testing or network analysis tools to see what it is really doing, I primarily use the Ethernet for NFS mounting which gives me performance in line with what the PSP datasheet suggests.

I took a qucik look at the driver in the release I have. Ethtool support appears to be in there.  I cross-compiled ethtool source and ran it on my EVM.  Seems to work just fine. Hopefully I have successfully attached my cross-compiled version.

Steve K.

You could also use ethtool to enable/disable auto negotiation or force a particular speed configuration you are interested in.

Thanks,

Prathap.

Thanks Steve!

this works great.  Very much appreciated.

I'd be interested in knowing how you cross compiled it if you get a chance.

thanks again.

-Simon

BTW.  It looks like the LEDs on the ethernet connector on the EVM indicate the status of the link and the speed.

The green LED indicates linked, and it blinks when there is data on the line, and the Amber LED is lit for 100M and off for 10M.

I confirmed this with Steve's ethtool, and a 10M hub and 100M switch.  when connect to the the hub the omap connections auto-negotiated to 10M half duplex and when connected to the switch 100M full duplex.

I did a Google search to find the source (can't remember where I got it from).  Un-tarred it and then

./configure --target=arm-none-linux-gnueabi --host=arm-none-linux-gnueabi --build=i386-linux

And then make. I was lucky that this package is easy to cross-compile. A lot of others aren't as easy.

Steve K.

Thanks Steve.  this is pretty much what I was trying. 

I had download from the sourceforge repository:

http://sourceforge.net/projects/gkernel/

and download the ethtool-6.tar.gz source code.  Then compiled as you did, but when I run the application on the target I get the following:

# ./ethtool eth0
./ethtool: line 1: syntax error: "(" unexpected

Maybe you are using an older version?  or I am missing another library?

So this is good I now have this diagnostic tool and I can confirm the ethernet port is at 100M Full duplex, but unfortunately I am still seeing my original problem.

I am sending ~1Mbps UDP data but only seeing ~0.25Mbps through the omap3530.

I assume the

# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
550000

parameter is telling me the cpu is at 550MHz?

Any other thoughts about why I am seeing so much packet loss on the input side of the ethernet port?

Its Working!!

So I replaced the 10/100/1000 netgear switch with an 10M/half duplex hub, and there are no packets dropped!

In the bad condition ethtool (-d register dump) was showing the RX_DROP packet count increasing.  So the ethernet chip was dropping packets which indicates the omap could not remove the packets quickly enough.  The HW_CFG is showing (from the 9115 data sheet)  TX_FIF_SZ= 5 which indicates the RX DATA FIFO is 10560 bytes.(trade off between TX buffer vs RX buffer on the chip)

The 10M HD hub must be slowing the data transfers down enough for the OMAP to keep up, and no dropped packets.

Any thoughts on why the OMAP could not service the ethernet chip fast enough?  Is there other linux/omap configuration( i.e. interrupt vs polled) that could be mis-configured?

thanks again for ethtool, this really helped!

What is the tool you are using to measure performance? You can use iperf. That has options to obatin UDP performance numbers.

Also how is your test setup? You could obtain performance numbers with iperf in 3 different setups for comparison -

1.By connecting the OMAP EVM to PC directly.

2.Having 100M switch in between OMAP EVM and PC.

3.Having 10M Hub in between OMAP EVM and PC.

Also you could have a OMAP to OMAP setup if you have 2 EVMs.

By obtaining these numbers for different setups, it could help in isolating any switch/hub level issues if they are causing any impact.

Thanks,

Prathap.

Hi Prathap,

I am using wireshark  on the PC to measure the downstream packet through put.  I do have tcpdump running on the omap, but haven't really used it for any performance measurements.

I don't have iperf on the omap, do you have a link where I can get a copy/source?

I actually do have two omap evm's and am using one as the source and the other is ip forwarding on the over to the pc.  It's the ip forwarding target that is dropping the packets.  So the it is the source omap that seems to be able to flood the network too fast for the downstream omap to keep up.  Another reason it seems like this might still be a linux/omap configuration issue on the RX ethernet port.

If I can get iperf running I'll try gather more useful data.

Hi,

You can find details on iperf at the below link -

http://tiexpressdsp.com/index.php/Iperf

Thanks,

Prathap.