This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3358: Linux/AM3358/Dual Ethernet Ports

Part Number: AM3358

Tool/software: Linux

The AM335x Starter Kit (EVM-SK) provides Dual Gigabit Ethernet Ports with Integrated Switch,,but when using bridge between two ports oNetwork port loss description.pdfn the same network interface on a Linux server the network port loss package. 

  • Please provide the information required in this checklist: processors.wiki.ti.com/.../5x_CPSW
  • When posting to the TI e2e forums here are some recommendations on steps to try to isolate possible issues involving CPSW Ethernet on AM3x/4x/5x devices.
    • Requirement
    • Any questions posted concerning the Linux CPSW Ethernet driver must be from using a TI Processor Linux SDK U-Boot/Linux Kernel and filesystem on either a TI EVM or a custom board. Texas Instruments only supports Linux Kernels and U-Boot images that are based on the TI Processors Linux SDK.
    Yes.
    • During the boot process check to make sure the Ethernet PHYs being are reported correctly in the console log. This means that the PHY being used should be reported and the driver being used is indicated. The CPSW should indicate it has initialized and finally it should report the interface is up. This is example with eth0 connected to a link partner. It should look something like this:
    Yes.

    [ 1.366149] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
    [ 1.372619] davinci_mdio davinci_mdio.0: detected phy mask fffffffc
    [ 1.380645] davinci_mdio.0: probed
    [ 1.384185] davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver unknown
    [ 1.391601] davinci_mdio davinci_mdio.0: phy[1]: device 0:01, driver unknown
    [ 1.399230] usbcore: registered new interface driver zd1201
    • Look at basic link elements after the system is booted to make sure that there is a link partner detected. No Ethernet traffic will be possible until the PHY is reporting a link detection. In fact, if no link is detected by the PHY that issue needs to be debugged first. Do not proceed debugging until the PHY is detecting a link. This means working with the PHY manufacturer to resolve the link detection issue. The commands are in bold.
    • ethtool eth0 : This will show what the link status is. Here are some questions that might help with link status trouble-shooting.
    • Is auto negotiation enabled on both ends of the link?
    • Do the link speeds match between the TI device and the link partner?
    • Is the Link duplex mode correct?

    • ethtool -S eth0 : This will show the hardware statistics. Here errors are reported for CRC errors, overruns etc. Errors reported by the hardware typically indicate the packet was dropped. Here are a couple of key errors to review:
    • RX Checksum errors – Can indicate bad cables, layout issues.
    • RX Overrun errors – This indicates packet drops due to the RX DMA descriptors being momentarily exhausted.
    • RX Start of Frame errors – This indicates that packets that have been dropped due the internal FIFOs of the switch being temporarily full.


    • What does the interface say:
    • ifconfig
    • Is the link up? Yes.
    • Is there an IP address? Yes.
    • Is the interface reporting data being received or transmitted? Yes.

    • Network view
    • Use Wireshark from the view of a link partner, typically the Linux PC is used here to capture packets.
    • Start a ping transaction from the device which will start an ARP process. Do any ARP packets show up in Wireshark? Yes.

    • Performance
    • When testing the interface with iperf a very common question is about not being able to match the numbers reported as part of the performance datasheet release with the TI SDK. The most common reason for this is because the developer started with a mainline kernel and not a TI SDK kernel. Also, when pulling a mainline kernel the defconfig supplied with mainline is not the same as the kernel defconfig supplied and tested with the TI SDK. Using a mainline kernel will have a significant performance drop.

    • When posting to the forums please capture the information requested below. Please send these as attachments as some of the logs will be lengthy.
    • Kernel version and source, also include the results of this command: uname -a

    • File system, TI SDK or Arago/Yocto based filesystem
    TMDSSK3358

    • Custom board or TI board? Please include device tree source file.
    TI board, TMDSSK3358
    • Console log of the boot process that includes U-Boot and the Kernel.



    • ethtool <interface such as eth0 or eth1>
    • ethtool -S <interface such as eth0 or eth1>
    • ifconfig <interface such as eth0 or eth1>ethtool
    root@am335x-evm:~# ifconfig eth0 192.168.1.111
    root@am335x-evm:~# ifconfig
    eth0 Link encap:Ethernet HWaddr C4:ED:BA:8D:C0:11
    inet addr:192.168.1.111 Bcast:192.168.1.255 Mask:255.255.255.0
    UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
    RX packets:215 errors:0 dropped:42 overruns:0 frame:0
    TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:25827 (25.2 KiB) TX bytes:3410 (3.3 KiB)

    eth1 Link encap:Ethernet HWaddr C4:ED:BA:8D:C0:13
    inet addr:192.168.20.231 Bcast:192.168.20.255 Mask:255.255.255.0
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:119 errors:0 dropped:0 overruns:0 frame:0
    TX packets:119 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:189485 (185.0 KiB) TX bytes:189485 (185.0 KiB)

    root@am335x-evm:~# ifconfig eth1 192.168.58.123
    root@am335x-evm:~# ifconfig
    eth0 Link encap:Ethernet HWaddr C4:ED:BA:8D:C0:11
    inet addr:192.168.1.111 Bcast:192.168.1.255 Mask:255.255.255.0
    UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
    RX packets:248 errors:0 dropped:44 overruns:0 frame:0
    TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:29176 (28.4 KiB) TX bytes:5784 (5.6 KiB)

    eth1 Link encap:Ethernet HWaddr C4:ED:BA:8D:C0:13
    inet addr:192.168.58.123 Bcast:192.168.58.255 Mask:255.255.255.0
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:119 errors:0 dropped:0 overruns:0 frame:0
    TX packets:119 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:189485 (185.0 KiB) TX bytes:189485 (185.0 KiB)

    root@am335x-evm:~# ifconfig
  • Hi,
    The post is marked resolved but I have a question about the posted results from the checklist:

    ethtool -S eth0 : This will show the hardware statistics. Here errors are reported for CRC errors, overruns etc. Errors reported by the hardware typically indicate the packet was dropped. Here are a couple of key errors to review:
    • RX Checksum errors – Can indicate bad cables, layout issues.
    • RX Overrun errors – This indicates packet drops due to the RX DMA descriptors being momentarily exhausted.
    • RX Start of Frame errors – This indicates that packets that have been dropped due the internal FIFOs of the switch being temporarily full.

    Could you please post the results of this command?

    ethtool -S eth0

    Regards,
    Schuyler
  • Hi,

         Thanks for your reply.The post is not resolved.I don't know why this issue has been resolved on the page.I am looking forward to the solution

    ethtool -S eth1
    NIC statistics:
    Good Rx Frames: 454
    Broadcast Rx Frames: 124
    Multicast Rx Frames: 191
    Pause Rx Frames: 0
    Rx CRC Errors: 0
    Rx Align/Code Errors: 0
    Oversize Rx Frames: 0
    Rx Jabbers: 0
    Undersize (Short) Rx Frames: 0
    Rx Fragments: 0
    Rx Octets: 50526
    Good Tx Frames: 163
    Broadcast Tx Frames: 6
    Multicast Tx Frames: 16
    Pause Tx Frames: 0
    Deferred Tx Frames: 0
    Collisions: 0
    Single Collision Tx Frames: 0
    Multiple Collision Tx Frames: 0
    Excessive Collisions: 0
    Late Collisions: 0
    Tx Underrun: 0
    Carrier Sense Errors: 0
    Tx Octets: 12670
    Rx + Tx 64 Octet Frames: 41
    Rx + Tx 65-127 Octet Frames: 484
    Rx + Tx 128-255 Octet Frames: 79
    Rx + Tx 256-511 Octet Frames: 13
    Rx + Tx 512-1023 Octet Frames: 0
    Rx + Tx 1024-Up Octet Frames: 0
    Net Octets: 63196
    Rx Start of Frame Overruns: 0
    Rx Middle of Frame Overruns: 0
    Rx DMA Overruns: 0
    Rx DMA chan: head_enqueue: 1
    Rx DMA chan: tail_enqueue: 327
    Rx DMA chan: pad_enqueue: 0
    Rx DMA chan: misqueued: 0
    Rx DMA chan: desc_alloc_fail: 0
    Rx DMA chan: pad_alloc_fail: 0
    Rx DMA chan: runt_receive_buf: 0
    Rx DMA chan: runt_transmit_buf: 0
    Rx DMA chan: empty_dequeue: 0
    Rx DMA chan: busy_dequeue: 520
    Rx DMA chan: good_dequeue: 264
    Rx DMA chan: requeue: 0
    Rx DMA chan: teardown_dequeue: 0
    Tx DMA chan: head_enqueue: 163
    Tx DMA chan: tail_enqueue: 0
    Tx DMA chan: pad_enqueue: 0
    Tx DMA chan: misqueued: 0
    Tx DMA chan: desc_alloc_fail: 0
    Tx DMA chan: pad_alloc_fail: 0
    Tx DMA chan: runt_receive_buf: 0
    Tx DMA chan: runt_transmit_buf: 18
    Tx DMA chan: empty_dequeue: 163
    Tx DMA chan: busy_dequeue: 0
    Tx DMA chan: good_dequeue: 163
    Tx DMA chan: requeue: 163
    Tx DMA chan: teardown_dequeue: 0

  • I am looking forward to the solution,the post is not resolved,My last reply was a mistake.
  • Hi,
    Thank you for posting the results of the ethtool command. I don't see any errors from a hardware point of view, I was looking for rx overruns.

    I do have to aplogize, somehow when I was looking at this forum thread the first time I missed the document that you attached answering the checklist questions.

    Currently installed on the TI EVM is a 3.2 kernel. I would recommend upgrading to the latest SDK from TI for this EVM and then redo the testing. There have been several changes to the driver software over the last 5-6 years.

    Best Regards,
    Schuyler
  • Hi,

       Thanks for your suggestion.The problem has been resolved.The reason is that the smartEEE function of AR8031 needs to be turned off.