Jetson Orin AGX EQOS MAC issues with customer carrier board and TI PHY

I have a custom carrier board that has the Jetson Orin AGX Industrial module installed on it. I am trying to boot JetPack 6.2.1 Linux on the Orin with the RGMII interface between the EQOS MAC and a TI DP83869HM PHY (on the carrier card). The error from the serial port is:

[ 14.612967] nvethernet 2310000.ethernet: failed to connect PHY
[ 14.612984] net eth0: ether_open: Cannot attach to PHY (error: -19)

A google search on this error suggested I check several items.

Pinmux:
These are the pinmux settings in the Excel file that I am using:

Reset and Interrupt GPIOS:
image

RGMII and MDIO:

The resulting three output files were copied to the Linux build machine and put into the paths referenced by my custom board conf file.

Device Tree section I am using (PHY ID is confirmed as ID 3 on hardware):
bus@0 {
/* Removed for brevity */
ethernet@2310000 {
/* Setting status = "okay" enables the device */
status = "okay";
/* nvidia,tegra234-eqos refers to the NVIDIA Orin */
/* AGX processor. The -eqos refers to the 1Gb */
/* Ethernet MAC */
/* eqos stands for Ethernet Quality of Service */
/* snps refers to synopsis, with dwc-qos-ethernet */
/* being the base of the 1Gb Ethernet IP */
/* Having both compatible statements is required */
compatible = "nvidia,tegra234-eqos","snps,dwc-qos-ethernet";

/* Phy Handle defined below */
phy-handle = <&ti_dp83869_phy>;
/* Using the RGMII interface so specify the */
/* rgmii-id mode */
/* rgmii-id specifies that the PHY controls the */
/* timing delays instead of the MAC */
/* NVIDIA support confirmed that rgmii MAC does */
/* not support Rx/TX delays internally and they */
/* must be supplied by a PHY. Therfore, rgmii, */
/* rgmii-rxid and rgmii-txid will not work as */
/* phy-mode entries */
phy-mode = "rgmii-id";
/* This maps to the GPIO PG05 pin where the */
/* ENET_RST_N signal is connected */
nvidia,phy-reset-gpio = <&gpio TEGRA234_MAIN_GPIO(G, 5) 0>;
/* mac-addr-idx is used to index into an array in */
/* the I2C eeprom on board the GPU module */
/* Kernel throws error on invalid index right now */
/* so the nvidia,ether-max* entries are used below*/
nvidia,mac-addr-idx = <0>;
nvidia,max-platform-mtu = <8000>;
nvidia,pause_frames = <0>;
/* Some sources online say this is required - set */
/* it to the same as nvidia,ether-mac */
local-mac-adress = [48 80 2D 68 C9 1C];
nvidia,ether-mac = "48:80:2D:68:C9:1C";
nvidia,ether-mac0 = "48:80:2D:68:C9:1C";
nvidia,ether-mac1 = "48:80:2D:68:C9:1D";
nvidia,ether-mac2 = "48:80:2D:68:C9:1E";
nvidia,ether-mac3 = "48:80:2D:68:C9:1F";
nvidia,ether-mac4 = "48:80:2D:68:C9:20";
nvidia,ether-mac5 = "48:80:2D:68:C9:21";
nvidia,ether-mac6 = "48:80:2D:68:C9:22";
nvidia,ether-mac7 = "48:80:2D:68:C9:23";
nvidia,ether-mac8 = "48:80:2D:68:C9:24";
nvidia,ether-mac9 = "48:80:2D:68:C9:25";

/* Not sure if these two lines are helping or */
/* hurting currently */
clock-names = "slave_bus","master_bus","rx","tx","ptp_ref";
reset-names = "eqos";

/* MDIO section describes everything from singals */
/* to devices on this bus */
mdio {
/* Set compatibility to nvidia,eqos-mdio and */
/* synopsis dwc-qos-ethernet-mdio */
compatible = "nvidia,eqos-mdio", "snps,dwc-qos-ethernet-mdio";
/* These next two lines are required */
#address-cells = <1>;
#size-cells = <0>;

/* Define the TI DP83869HM PHY settings - */
/* phy@3 specifices Device ID 03 */
ti_dp83869_phy: ethernet-phy@3 {
/* Set the device to active */
status="okay";
/* Set compatible so that it finds the TI */
/* DP83869 device driver - must be enabled*/
/* in kernel */
compatible = "ti,dp83869";
device-type = "ethernet-phy";
/* reg = must match the PHY device ID */
/* above or 3 */
reg = <0x3>;
/* Set both TX/RX FIFO depths to 4 Bytes */
tx-fifo-depth = <DP83869_PHYCR_FIFO_DEPTH_4_B_NIB>;
rx-fifo-depth = <DP83869_PHYCR_FIFO_DEPTH_4_B_NIB>;
/* Make sure we are in RGMII Copper mode */
ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
ti,max-output-impedance;
ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_A_RCLK>;
rx-internal-delay-ps = <2000>;
tx-internal-delay-ps = <2000>;
nvidia,phy-rst-pdelay-msec = <224>; /* msec */
nvidia,phy-rst-duration-usec = <10000>; /* usec */
/* Set the Interrupt pin up as a gpio pin */
/* and use PG04 - maps to ENET_INT */
interrupt-parent = <&gpio>;
interrupts = <TEGRA234_MAIN_GPIO(G, 4) IRQ_TYPE_LEVEL_LOW>;
};
};
};

/* Removed for brevity */
};

Currently trying to install the mdio-tool into the Linux image to read the PHY registers.

I do not have wires on the MDIO lines currently but could install them if required.

I would greatly appreciate help in figuring out why I can’t talk to the PHY from the EQOS MAC.

*** Please note that this reply is generated by LLM automatically ***

Based on the provided information, I will attempt to help you troubleshoot the issue with your custom carrier board and the Jetson Orin AGX Industrial module.

Error Analysis

The error message “nvethernet 2310000.ethernet failed to connect PHY” and “net eth0: etheropen: Cannot attach to PHY error 19” suggests that there is an issue with the communication between the EQOS MAC and the TI DP83869HM PHY.

Pinmux Settings

You have provided the pinmux settings in the Excel file, which appear to be correct. The RGMII and MDIO pins are properly configured, and the reset and interrupt GPIOs are also set up correctly.

Device Tree

You have confirmed that the PHY ID is set to 3 in the device tree, which matches the hardware configuration.

MDIO Tool

You are trying to install the mdiotool to read the PHY registers, which is a good step in debugging the issue. However, you may not need to install wires on the MDIO lines if you can use the mdiotool to read the registers.

Possible Causes

Based on the error messages and the configuration, here are some possible causes:

  1. PHY ID mismatch: Although you have confirmed that the PHY ID is set to 3 in the device tree, it’s possible that there is a mismatch between the device tree and the hardware configuration. Double-check that the PHY ID is correct and matches the hardware configuration.
  2. Pinmux configuration: Although the pinmux settings appear to be correct, it’s possible that there is an issue with the pinmux configuration. Verify that the pinmux settings are correct and that there are no conflicts with other devices on the board.
  3. MDIO clock: The MDIO clock is not explicitly mentioned in the configuration. Ensure that the MDIO clock is properly configured and that it is enabled.
  4. PHY reset: The PHY reset signal is not explicitly mentioned in the configuration. Ensure that the PHY reset signal is properly configured and that it is asserted correctly.
  5. Hardware issue: There may be a hardware issue with the board or the PHY. Verify that the board is properly assembled and that there are no issues with the PHY or the EQOS MAC.

Comparison with Other Configurations

Since you are using a custom carrier board, it’s possible that the configuration is different from other boards. Compare your configuration with other boards that use the same PHY and EQOS MAC to ensure that there are no differences in the configuration.

Recommendations

  1. Verify the PHY ID: Double-check that the PHY ID is correct and matches the hardware configuration.
  2. Verify the pinmux configuration: Verify that the pinmux settings are correct and that there are no conflicts with other devices on the board.
  3. Check the MDIO clock: Ensure that the MDIO clock is properly configured and that it is enabled.
  4. Check the PHY reset: Ensure that the PHY reset signal is properly configured and that it is asserted correctly.
  5. Use the mdiotool: Use the mdiotool to read the PHY registers and verify that the PHY is properly configured.
  6. Check the hardware: Verify that the board is properly assembled and that there are no issues with the PHY or the EQOS MAC.

By following these recommendations, you should be able to troubleshoot the issue and resolve the problem with your custom carrier board and the Jetson Orin AGX Industrial module.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

If you get this working please let me know your solution. I’m getting a similar error, but I’m using a KSZ9031 instead of the TI part.