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

Network Driver Initialization Process

On TI Arm® based processors there are two drivers that initialize during a Linux boot: the MDIO driver and the CPSW or PRU_ICSSG (or both) driver. The MDIO driver is used for communicating with the Ethernet PHY. The CPSW or PRU_ICSSG (or both) driver set up the Ethernet MAC. To check if these drivers are initialized properly, the boot log of the DUT needs to be examined. The following initialization stages show up:

  1. Both the MDIO and CPSW or PRU_ICSSG drivers have initialized without errors.
  2. The MDIO driver has detected the PHYs at the respective PHY address defined in the board DTS file. The exact PHY address is determined by the PHY hardware boot strapping.
  3. The Ethernet interface is up and a link is established, assuming a cable is attached to the Ethernet port before boot up.

The following log shows an example of what is expected as part of the initialization. The timestamps printed out for each line can differ between different boot sequences.

[    1.060850] davinci_mdio 8000f00.mdio: Configuring MDIO in manual mode
[    1.095345] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[    1.098179] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver TI DP83867
[    1.098198] davinci_mdio 8000f00.mdio: phy[1]: device 8000f00.mdio:01, driver TI DP83867
[    1.098246] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006
[    1.098500] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5
[    1.098505] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512
[    1.099141] pps pps0: new PPS source ptp0
[    1.099456] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1
[    1.120288] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19

In this example, the MDIO driver is the davinci_mdio and the CPSW driver is am65-cpsw-nuss. There are two TI DP83867 PHYs on the DUT and the expected PHY addresses are boot strapped to address 0 and 1. The MDIO driver detected these PHYs at these addresses as specified in the board DTS and attached them to the DP83867 PHY driver. No Ethernet cable was connected before the boot up sequence so a link up message does not show up.

The following log shows the MDIO driver scanning the bus for the Ethernet PHYs that have been defined in the DTS file for the DUT. This is an expected normal initialization sequence. The PHY vendor is identified and the corresponding PHY driver is identified as well.

[    6.902614] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:01] driver [TI DP83867] (irq=POLL)
[    6.902648] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii-rxid link mode
[    6.938874] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=POLL)
[    6.938911] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii-rxid link mode

The PHY is defined in the board DTS file is then referenced by the CPSW port in the respective DTS definition. The following code is an edited portion from a TI EVM showing the MDIO with the PHY for an Ethernet port and how the MDIO and PHY are identified in the Linux console during a Linux boot.

A DTS PHY node example, shortened for discussion purposes

&cpsw3g_mdio {
	cpsw3g_phy0: ethernet-phy@0 {
		reg = <0>;    <-- check PHY address, verify this is correct
		......
	};
};

This line shows the PHY defined in the DTS being identified 

[    6.938874] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=POLL)

If the MDIO driver is not able to communicate with an Ethernet PHY, there are several errors that can occur that are either related to the DTS or problems in the PHY state from a hardware implementation issue.

Note:

Debug suggestions for PHY initialization issues:

Now that the Ethernet PHYs are identified, these PHYs can be interrogated to see if a link is established with a link partner. If an Ethernet cable is connected and a link is established, the following logs appear on the DUT console. Data bit rate and duplexity are agreed upon when a link is established. Notice in this example, the speed is 1Gbps, the link is full duplex, and the Ethernet interface is ready to use.

[   11.042192] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   11.042255] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

The Ethernet speed and duplex mode on the TI EVMs are agreed between link partners using auto-negotiation. The above message shows a successful initialization sequence.

If there are issues with the driver initialization, the recommendation is to review the board DTS with the TI EVM that the board is designed around. The following code is a sample of the DTS file that is used to define the CPSW interface (Ethernet MAC) for the TI SK-AM62B-P1 EVM that can be used as a reference.

The following DTS example shows some checkpoints that need to be verified when working with a custom board DTS.

Linux Source tree directory: arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi 
...
&cpsw3g {
	bootph-all;
	pinctrl-names = "default";
	pinctrl-0 = <&main_rgmii1_pins_default>;   <-- verify pin mux is correct
};

&cpsw_port1 {
	bootph-all;
	phy-mode = "rgmii-rxid";         <-- verify interface mode is correct
	phy-handle = <&cpsw3g_phy0>;     <-- verify phy name is referenced correctly
};
...
&cpsw3g_mdio {
	bootph-all;
	status = "okay";
	pinctrl-names = "default";
	pinctrl-0 = <&main_mdio1_pins_default>;    <-- verify pin mux is correct

	cpsw3g_phy0: ethernet-phy@0 {
		bootph-all;
		reg = <0>;
		ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>; <-- rx clock delay 
		ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
		ti,min-output-impedance;
	};
};

Section Summary:

The following are the conditions that indicate a successful initialization process:

  • The MDIO driver has initialized without errors and has identified all expected PHYs on the MDIO bus.
  • The CPSW or PRU_ICSSG (or both) driver has initialized without errors.
  • The CPSW driver is reporting a link up message with the expected bit rate and duplexity.