SPRADJ8 October   2024 AM3351 , AM3352 , AM3354 , AM3356 , AM3357 , AM3358 , AM3359 , AM4372 , AM4376 , AM4377 , AM4378 , AM4379 , AM620-Q1 , AM623 , AM625 , AM625-Q1 , AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1 , AM62P , AM6411 , AM6412 , AM6421 , AM6422 , AM6441 , AM6442 , DP83822H , DP83822HF , DP83822I , DP83822IF , DP83826E , DP83826I , DP83848-EP , DP83848Q-Q1 , DP83867CR , DP83867CS , DP83867E , DP83867IR , DP83867IS , DP83TC812R-Q1 , DP83TC812S-Q1 , DP83TC813R-Q1 , DP83TC813S-Q1 , DP83TC814R-Q1 , DP83TC814S-Q1 , DP83TG720R-Q1 , DP83TG720S-Q1 , DP83TG721R-Q1 , DP83TG721S-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. Terminology
  5. Prerequisites
  6. Quick Initial Steps
  7. Debug Overview
  8. Network Driver Initialization Process
  9. Ethernet PHY Analysis
  10. Ethernet MAC Statistics Analysis
  11. How IPv4 Address is Obtained
  12. Follow the Packet
  13. 10Debug Network Topologies and Techniques
    1. 10.1 Direct Connection
    2. 10.2 Static IP Addresses
    3. 10.3 Setting Low Bit Rates
    4. 10.4 Beware When Connecting to a Switch
  14. 11Linux® Utilities Summary
  15. 12Checklist for Requesting Ethernet Support

Ethernet MAC Statistics Analysis

Review the MAC statistics for errors between the DUT and the link partner to verify that basic transmission and reception of Ethernet packets was successful. Remember that even if basic transmission and reception of packets occur, there can be errors that are limiting network throughput. Some errors and solutions are discussed in this section.

AM62x, AM64x, AM62Ax, AM62P Full Ethernet Packet Flow With
                    MAC Statistics Figure 7-1 Full Ethernet Packet Flow With MAC Statistics

Reviewing the MAC statistics indicates the number of packets sent, received, and the number of ones dropped with errors. Remember that MAC statistics are the results from monitoring the packets directly at the interface.

Analyzing the granularity of an individual packet when examining the interface statistics is not necessary. The main behavior to look out for are incrementing counts for RX and TX good frames and checking that there are no errors detected such as CRC, alignment, and so forth.

Incrementing TX and RX good frames statistics registers are an indication that sending and receiving packets between the MAC and the PHY is working as expected. This is also an indication that the MAC-PHY TX and RX clock is working correctly.

If the MAC statistics error counters are increasing, then there are packets being dropped at the interface. For example, a non-zero RX CRC error counter indicates that packets are received with CRC checksum errors and, as a result, dropped at the interface.

Note: TX errors such as CRC errors are not among the list of MAC statistics on the platform under test that can be captured. TX CRC errors are only detected by the RX error counters of the link partner.

The following MAC statistics are in the context of a TI EVM directly connected to another board by connecting an Ethernet cable between the two link partners. Neither link of the two link partners are running a DHCP server to dynamically assign IP addresses. As Section 3 mentioned, you do not need to obtain an IP address to examine packet traffic. When examining traffic at this level, the key takeaway is to determine that no errors are observed during basic packet send and receive.

Once a link up on an interface is detected and the MAC driver is initialized, there is network traffic initiated in an attempt to acquire an IP address. The following TX and RX are the result of this network traffic, indicating how many packets were transmitted and received.

Specifically, the example snippet of the MAC statistic for TX packets is a result of connecting an Ethernet cable in between the two link partners. Once the link is detected to be up on an interface, the Linux kernel attempts to acquire an IP address. Some of the frames reported on the tx_broadcast_frames statistics are the DHCP request frames from the DUT that are used to acquire an IPv4 address. Furthermore, if the tx_good_frames statistic are incrementing, then this is a good an indication that packets were transmitted from the MAC of the DUT onto the wire.

A portion of an example ethool -S <interface> output showing the TX MAC statistics:

tx_good_frames: 19
tx_broadcast_frames: 2
tx_multicast_frames: 17

The following RX results from the MAC statistics reveal that packets are received as well after connecting an Ethernet cable. These particular statistics show that there are packets correctly received by the MAC. With this example, there is not an IP address assigned to the platform. The actual Ethernet protocol in use does not matter at this level. The main goal is to check that no corrupted packets are received and that packets are properly sent.

A portion of an example ethtool -S <interface name> output showing RX MAC statistics:

rx_good_frames: 104
rx_broadcast_frames: 10
rx_multicast_frames: 94

The next example gives a closer view on the RX error results from the MAC statistics. Here, there are no errors detected. However, if these error statistics are incrementing, it gives an indication to what particular errors caused the packets to be dropped at the interface. For Texas Instruments' processors serving as the DUT, the definitions of each MAC statistics counter can be found in the respective Technical Reference Manual (TRM) for that particular processor.

Portion of sample ethtool -S <interface name> showing RX error statistics:

rx_crc_errors: 0
rx_align_code_errors: 0
rx_oversized_frames: 0
rx_jabber_frames: 0
rx_undersized_frames: 0
Note:

Debug Suggestions:

  • If the ethtool utility tool is not returning any data for either link detection or MAC statistics, then this indicates the MDIO communication to the PHY is not performing as expected. Confirm the PHY device driver was loaded and correctly identified in the Linux boot log. If the PHY was not correctly identified, consult Section 6.
  • If there is TX traffic, but no RX traffic, then see Section 4, Section 9, or the debug suggestions at the end of each section in this application note.

Section Summary:

  • The results of ethtool -S <interface name> for an interface provides data on the send and receive process.
  • Connecting the Ethernet cable between two link partners generates traffic that can be viewed with ethtool without the need for obtaining an IP address.