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
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:
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.
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: