AGX Xavier custom carrier board. Cannot attach to PHY

[ian.draney]

Hello NVIDIA Developers,

I am unable to communicate with a Marvell 88E1512 ethernet transceiver on a custom carrier board for an Xavier device.

These are the messages of interest from a dmesg:

[    7.158662] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    7.273559] eth0: Could not attach to PHY
[    7.273703] net eth0: eqos_open: Cannot attach to PHY (error: -19)

The custom board is different than the Xavier development kit, as the 88E1512 device connects to an onboard switch via SGMII.

A few attempts have been made at editing hardware/nvidia/platform/t19x/common/kernel-dts/t19x-common-platforms/tegra194-platforms-eqos.dtsi and flashing the Xavier, but the error continues to occur. Since it is not using copper-mode, a few attempts have been made to change it, including commenting out the reg-init value. These changes have not fixed the issue. The code below is just the file’s current state, including commented out mode settings.

#include <dt-bindings/gpio/tegra194-gpio.h>

/ {
        ether_qos@2490000 {
		/* PTP_ref clock speed in MHz */
		nvidia,ptp_ref_clock_speed = <312500000>;
		/* rxq_enable_ctrl = <rx0 rx1 rx2 rx3>
		 * 0x0 = Not enabled, 0x1 = Enabled for AV
		 * 0x2 = Enabled for Legacy, 0x3 = Reserved
		 */
		nvidia,rxq_enable_ctrl = <2 2 2 2>;
		nvidia,queue_prio = <0 1 2 3>;

		nvidia,use_tagged_ptp;
		nvidia,ptp_dma_ch = <3>;

		nvidia,chan_napi_quota = <64 64 64 64>;
		nvidia,pause_frames = <0>; /*0=enable, 1=disable */
		nvidia,phy-reset-gpio = <&tegra_main_gpio TEGRA194_MAIN_GPIO(G, 5) 0>;
		nvidia,phy-max-frame-size = <16>;	/* size in kbytes */
		nvidia,eth_iso_enable = <1>; /*0=enable, 1=disable */
		phy-mode = "rgmii-id";
		phy-handle = <&phy0>;

		mdio {
			compatible = "nvidia,eqos-mdio";
			#address-cells = <1>;
			#size-cells = <0>;

			phy0: ethernet-phy@0 {
				reg = <0>;
				interrupt-parent = <&tegra_main_gpio>;
				interrupts = <TEGRA194_MAIN_GPIO(G, 4) IRQ_TYPE_LEVEL_LOW>;
				//marvell,sgmii-mode;
				marvell,fiber-mode;
				// marvell,copper-mode;

				/* Setup LED[2] as interrupt pin (active low) */
				// marvell,reg-init = <0x03 0x12 0x7fff 0x880>;
			};
		};
	};

	thermal-zones {
		CPU-therm {
			trips {
				MAKE_EQOS_TRIP(m40, -40000, 5000);
				MAKE_EQOS_TRIP(m5, -5000, 5000);
				MAKE_EQOS_TRIP(p30, 30000, 5000);
				MAKE_EQOS_TRIP(p65, 65000, 5000);
				MAKE_EQOS_TRIP(p100, 100000, 5000);
			};

			cooling-maps {
				MAP_EQOS(m40, 1);
				MAP_EQOS(m5, 2);
				MAP_EQOS(p30, 3);
				MAP_EQOS(p65, 4);
				MAP_EQOS(p100, 5);
			};
		};
	};
};

Files attached for boot messages obtained over serial and full dmesg output. Any advice here would be appreciated.

Thanks!
Ian

dmesg_phy-eth0-err_20210623.txt (63.6 KB)
serial-boot-log_phy-eth0-err_20210623.txt (31.5 KB)

[Trumany]

Hi, from hardware side, did you follow the design/routing guide of ethernet in product design guide doc? Is your 88E1512 design same to devkit except switch part? If so, it means the issue should be on the switch side, design or driver, right?

[WayneWWW]

Also want to know what is the difference between your design and design guide.

[ian.draney]

Hi @Trumany and @WayneWWW ,

Thank you for your responses. We dug into the schematics and made a couple of corrections that helped the situation, but we still have not yet fully resolved the issue.

The good news is that when we remove the Marvell 88E1512PB2-NNP2C000 from an AGX Xavier Development Kit carrier board and place it on our custom board, the Xavier can see eth0.

The bad news is that when we use a Marvell 88E1512 -A0-NNP2I000, even when soldered on to the AGX Xavier Development Kit carrier board (as well as when soldered to our custom board), the Xavier can not see eth0, which returns us to the original problem where the Xavier cannot talk to the PHY via RGMII.

eth0: Could not attach to PHY
net eth0: eqos_open: Cannot attach to PHY (error: -19)

We have reverted to the original unedited tegra194-platforms-eqos.dtsi file. For testing, we are using JetPack 32.5.1 with no kernel changes. Are there known compatibility issues with the -A0-NNP2I000 submodel of the 88E1512, or is it possible that an driver or device tree update could resolve this detection/communication issue for this particular device?

Thanks!
Ian

[Trumany]

We don’t have answer of compatibility question between the two chips. Please check with vendor for that. We only validated the one on devkit.