AQR113 XFI chip phy_mode setting, network connection

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

We have designed a custom carrier board for the jetson agx orin and use the AQR113 as a PHY chip, it is connected over XFI as part of the MGBE pins. The AQR113 is additionally connected to an SPI EEPROM with firmware flashed on in, same version as mentioned by NVIDIA on this forum (AQR-G4_v5.6.7-AQR_VER1922.cld)

When booting the device up with no eth cable plugged in to the PHY, these related messages appear.

[   10.430942] nvethernet 6810000.ethernet: failed to read UPHY GBE mode- default to 10G
[   15.931699] Aquantia AQR113C 6810000.ethernet:00: No AQR phy_mode setting in DT

When a cable is plugged in a new wired connection is detected in ubuntu, which tries to reach the internet but never manages

[   19.356565] IPv6: ADDRCONF(NETDEV_CHANGE): eth4: link becomes ready
[   19.357182] nvethernet 6810000.ethernet: [xpcs_lane_bring_up][477][type:0x4][loga-0x0] PCS block lock SUCCESS
[   19.357522] nvethernet 6810000.ethernet eth4: Link is Up - 1Gbps/Full - flow control rx/tx
[   22.900232] nvethernet 6810000.ethernet: [xpcs_lane_bring_up][477][type:0x4][loga-0x0] PCS block lock SUCCESS
[   22.900274] nvethernet 6810000.ethernet eth4: Link is Up - 1Gbps/Full - flow control rx/tx
[   24.543099] pwm-tegra-tachometer 39c0000.tachometer: Tachometer Overflow is detected
[   25.940216] nvethernet 6810000.ethernet: [xpcs_lane_bring_up][477][type:0x4][loga-0x0] PCS block lock SUCCESS
[   25.940263] nvethernet 6810000.ethernet eth4: Link is Up - 1Gbps/Full - flow control rx/tx

The relevant part of the DT:

	ethernet@6810000 {
		compatible = "nvidia,nvmgbe";
		reg = <0x00 0x6810000 0x00 0x10000 0x00 0x68a0000 0x00 0x10000 0x00 0x68d0000 0x00 0x10000 0x00 0x6800000 0x00 0x10000>;
		reg-names = "mac\0xpcs\0macsec-base\0hypervisor";
		interrupts = <0x00 0x180 0x04 0x00 0x181 0x04 0x00 0x182 0x04 0x00 0x183 0x04 0x00 0x184 0x04 0x00 0x185 0x04 0x00 0x186 0x04 0x00 0x187 0x04>;
		interrupt-names = "common\0vm0\0vm1\0vm2\0vm3\0vm4\0macsec-ns-irq\0macsec-s-irq";
		resets = <0x02 0x2e 0x02 0x2d 0x02 0x2f>;
		reset-names = "mac\0pcs\0macsec_ns_rst";
		clocks = <0x02 0x165 0x02 0x169 0x02 0x171 0x02 0x175 0x02 0x176 0x02 0x177 0x02 0x178 0x02 0x179 0x02 0x17b 0x02 0x17c 0x02 0x17d 0x02 0x17a 0x02 0xf8>;
		clock-names = "rx-input-m\0rx-pcs-m\0rx-pcs-input\0rx-pcs\0tx\0tx-pcs\0mac-divider\0mac\0eee-pcs\0mgbe\0ptp-ref\0mgbe_macsec\0rx-input";
		interconnects = <0x44 0x58 0x44 0x5c>;
		interconnect-names = "dma-mem\0write";
		iommus = <0x03 0x06>;
		power-domains = <0x02 0x12>;
		nvidia,num-dma-chans = <0x0a>;
		nvidia,dma-chans = <0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09>;
		nvidia,num-mtl-queues = <0x0a>;
		nvidia,mtl-queues = <0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09>;
		nvidia,tc-mapping = <0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x00 0x01>;
		nvidia,residual-queue = <0x01>;
		nvidia,rxq_enable_ctrl = <0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02 0x02>;
		nvidia,vm-irq-config = <0x4d>;
		nvidia,tx-queue-prio = <0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x00 0x00>;
		nvidia,rx-queue-prio = <0x01 0x02 0x04 0x08 0x10 0x20 0x40 0x80 0x00 0x00>;
		status = "okay";
		nvidia,dcs-enable = <0x01>;
		nvidia,rx_riwt = <0x200>;
		nvidia,rx_frames = <0x40>;
		nvidia,tx_usecs = <0x100>;
		nvidia,tx_frames = <0x10>;
		nvidia,promisc_mode = <0x01>;
		nvidia,slot_num_check = <0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00>;
		nvidia,slot_intvl_vals = <0x00 0x7d 0x7d 0x7d 0x7d 0x7d 0x7d 0x7d 0x7d 0x7d>;
		nvidia,ptp_ref_clock_speed = <0x12a05f20>;
		nvidia,instance_id = <0x00>;
		nvidia,ptp-rx-queue = <0x03>;
		dma-coherent;
		nvidia,dma_rx_ring_sz = <0x1000>;
		nvidia,dma_tx_ring_sz = <0x1000>;
		nvidia,mac-addr-idx = <0x00>;
		nvidia,max-platform-mtu = <0x3fff>;
		nvidia,pause_frames = <0x01>;
		phy-handle = <0x4e>;
		phy-mode = "10gbase-r";
		nvidia,phy-iface-mode = <0x00>;
		nvidia,phy-reset-gpio = <0x04 0x91 0x00>;

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

			ethernet_phy@0 {
				mode = "xfi";
				aqr-phy-mode = "xfi";
				phy-mode = "xfi";
				compatible = "ethernet-phy-ieee802.3-c45";
				reg = <0x00>;
				nvidia,phy-rst-pdelay-msec = <0x96>;
				nvidia,phy-rst-duration-usec = <0x35f48>;
				interrupt-parent = <0x04>;
				interrupts = <0x93 0x08>;
				phandle = <0x4e>;
			};
		};
	};

To my understanding the same chip is used in the devkit, are you familiar with similar issues? If it is device tree issue what has to be changed there? I already added ‘phy-mode = “xfi”’ line.

Thank You in advanced for any help or insight :)

4

  1. Which Jetpack release are in use?

  2. The device tree seems to have mistake… we don’t directly write something like “xfi” to the node…

5

Hey Wayne,
so far we have been testing with Jetpack 5.1.2. I agree, the node’s containing “xfi” have been added by us, as an attempt to fix the AQR113 error message but don’t seem to take any effect.

6

please read docuemnt.

https://docs.nvidia.com/jetson/archives/r35.6.0/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html?highlight=rgmii#for-phy

7

Thank you, I have followed that guide previously and our DT matches the one in the document.
Our biggest suspicion is if the firmware is correctly flashed, the bring up guide mentions using mdio tool to ensure that the PHY firmware is successfully loaded. Could you give a usage example?
Additionally it would be helpful to understand how AQR PHY chips for the devkit are flashed

8

  1. If you are also using AQR113 node as NV devkit, please don’t change device tree. There is no need to do that. If you have any reason that you need to do change that, please tell.

  2. Please attach the full dmesg log but not parsing by yourself unless you already knew how to debug the situation. But I don’t think that is the case.

  3. The firmware of AQR PHY is pre-flashed by using tools provided by Acquantia. We don’t provide method to flash the fw to AQR phy on Jetson. You need to contact with vendor for it.

9

Here is our full dmesg log
dmesg_log.txt (164.8 KB)

10

Did you ever change the pinmux from original one to a custom one?

11

Yes, I generated the pinmux and gpio .dtsi files from the spreadsheet and applied them to the flashed build. Can changes be seen from the dmesg ?

12

Could you use default setting of pinmux ? As I already told, the default setting already have everything you need. If default setting could not bring the interface up, then hardware review and phy firmware needs to be checked.

13

You are right the default settings should work with our custom board as the PHY circuit is exactly the same as on the dev-kit. Thank you for confirming that.
The issue is most likely with with the PHY firmware, we are in contact with the manufacturer for support.

15

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