RGMII_TXC missing when trying to use ethernet switch

I’m trying to use an ethernet switch (KSZ9567R) with the AGX module. I’ve followed other instructions and the interface comes up with the change to fixed-link PHY in the device tree. I do not intend to have the switch managed by the jetson, so configuring the ethernet MAC as a fixed-link is sufficient. I haven’t changed any pins from the devboard pinout.
Traffic can flow into the jetson from the switch (0% packet loss), but cannot move the other way (100% packet loss). The TXD[3:0] and TX_CTL signals look good under a scope, but TXC is stuck at zero, so this sounds like the clock is just not being enabled. dmesg doesn’t show anything interesting (such as a failure of the eqos_clock_enable function from the kernel:

root@jetson-agx-xavier-devkit:/var/log# dmesg | grep eqos
[    4.700308] eqos 2490000.ether_qos: failed to read eqos_auto_cal_config_0_reg
[    4.702273] eqos 2490000.ether_qos: Setting local MAC: {redacted}
[   18.279888] eqos 2490000.ether_qos eth0: Link is Up - 1Gbps/Full - flow control off

Here’s the decompiled eqos-related stubs from the compiled device tree:

ether_qos@2490000 {
		compatible = "nvidia,eqos";
		reg = <0x00 0x2490000 0x00 0x10000>;
		reg-names = "eqos_base";
		interrupts = <0x00 0xc2 0x04 0x00 0xc3 0x04 0x00 0xbe 0x04 0x00 0xba 0x04 0x00 0xbf 0x04 0x00 0xbb 0x04 0x00 0xc0 0x04 0x00 0xbc 0x04 0x00 0xc1 0x04 0x00 0xbd 0x04>;
		clocks = <0x04 0x120 0x04 0x20 0x04 0x22 0x04 0x21 0x04 0x23 0x04 0x08>;
		clock-names = "pllrefe_vcoout\0eqos_axi\0eqos_rx\0eqos_ptp_ref\0eqos_tx\0axi_cbb";
		resets = <0x05 0x11>;
		reset-names = "eqos_rst";
		nvidia,local-mac-address = <0x00 0x00 0x00 0x00 0x00 0x00>;
		iommus = <0x02 0x14>;
		iommu-group-id = <0x02>;
		dma-coherent;
		nvidia,csr_clock_speed = <0x19>;
		nvidia,iso_bw = <0x14000>;
		nvidia,rx_riwt = <0x3c>;
		nvidia,rx_frames = <0x10>;
		nvidia,slot_intvl_val = <0x7c>;
		status = "okay";
		pinctrl-names = "idle\0default";
		pinctrl-0 = <0x1e>;
		pinctrl-1 = <0x1f>;
		nvidia,ptp_ref_clock_speed = <0x12a05f20>;
		nvidia,rxq_enable_ctrl = <0x02 0x02 0x02 0x02>;
		nvidia,queue_prio = <0x00 0x01 0x02 0x03>;
		nvidia,use_tagged_ptp;
		nvidia,ptp_dma_ch = <0x03>;
		nvidia,chan_napi_quota = <0x40 0x40 0x40 0x40>;
		nvidia,pause_frames = <0x00>;
		nvidia,phy-reset-gpio = <0x16 0x35 0x00>;
		nvidia,phy-max-frame-size = <0x10>;
		nvidia,eth_iso_enable = <0x01>;
		phy-mode = "rgmii-id";
		vddio_sys_enet_bias-supply = <0x20>;
		vddio_enet-supply = <0x20>;
		phy_vdd_1v8-supply = <0x21>;
		phy_ovdd_rgmii-supply = <0x21>;
		phy_pllvdd-supply = <0x20>;

		eqos-cool-dev {
			cooling-min-state = <0x00>;
			cooling-max-state = <0x05>;
			#cooling-cells = <0x02>;
			linux,phandle = <0xa3>;
			phandle = <0xa3>;
		};

		prod-settings {
			#prod-cells = <0x04>;

			prod {
				prod = <0x00 0x8800 0x80000000 0x00 0x00 0x8804 0x20000000 0x20000000>;
			};
		};

		fixed-link {
			speed = <0x3e8>;
			full-duplex;
		};
	};
eqos_idle {
			linux,phandle = <0x1e>;
			phandle = <0x1e>;

			eqos {
				nvidia,pins = "eqos_td3_pe4\0eqos_td2_pe3\0eqos_td1_pe2\0eqos_td0_pe1\0eqos_txc_pe0\0eqos_tx_ctl_pe5\0eqos_rd3_pf1\0eqos_rd2_pf0\0eqos_rd1_pe7\0eqos_rd0_pe6\0eqos_rxc_pf3\0eqos_rx_ctl_pf2";
				nvidia,tristate = <0x01>;
			};
		};

		eqos_default {
			linux,phandle = <0x1f>;
			phandle = <0x1f>;

			eqos {
				nvidia,pins = "eqos_td3_pe4\0eqos_td2_pe3\0eqos_td1_pe2\0eqos_td0_pe1\0eqos_txc_pe0\0eqos_tx_ctl_pe5\0eqos_rd3_pf1\0eqos_rd2_pf0\0eqos_rd1_pe7\0eqos_rd0_pe6\0eqos_rxc_pf3\0eqos_rx_ctl_pf2";
				nvidia,tristate = <0x00>;
			};
		};

When inspecting PINMUX registers, the TXC pin looks to be in GPIO mode (not SFIO), but writing it to match the other eqos TX pins (value of 0x00022400 didn’t immediately fix the issue:

root@jetson-agx-xavier-devkit:~# devmem 0x02445058 32
0x00022000
root@jetson-agx-xavier-devkit:~# devmem 0x02445018 32
0x00022400
root@jetson-agx-xavier-devkit:~# devmem 0x02445058 32 0x00022400

Any ideas what’s going on here?

1 Like

Hi,

Please find the vendor for their suggestion first.

This is a custom board designed by me - there is no other vendor unfortunately.

No… I am not talking about you. I mean the vendor of KSZ9567R…

There was another case with KSZ ethernet chip before and they provided a new firmware/programming to another users to solve the problem.

This issue is the other direction though, the switch is not the issue. The TX_CLK signal should be generated by the RGMII interface on the Jetson module (125MHz clock) and isn’t.
I’m working on some debugging to see whether the clock initialization code is being run or not in the kernel and whether it’s silently failing somehow; clearly some of it is working since everything except the TX_CLK signal is correct (RX signals, TXD[3:0], etc), but I haven’t gotten to the bottom of that part yet.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.