Does Xavier NX support gigabit LAN,how to config

Hi Nvidias,

Can Xavier NX support gigabit LAN,we can link 100M LAN but can not link 1000M LAN.How to config gigabit LAN.

This should be GB already. If this is only working with 100Mb/s, then it is likely due to one of:

  • Carrier board.
  • Device tree.
  • Software installed/settings.
  • Switch/HUB limitations.

Sorry, I do not know which, but you will probably want to provide details of your carrier board and any device tree or other changes.

Hi Linuxdev,

I am the colleague of ZhouQiang.
We didn’t modify any dts & code about ether_qos@2490000 from the R32.4.2.

The device-tree about ether_qos is:

        ether_qos@2490000 {
                compatible = "nvidia,eqos";
                reg = <0x0 0x02490000 0x0 0x10000>;    /* EQOS Base Register */
                reg-names = "eqos_base";
                interrupts =    <0 194 0x4>,    /* common */
                                <0 195 0x4>,    /* power */
                                <0 190 0x4>,    /* rx0 */
                                <0 186 0x4>,    /* tx0 */
                                <0 191 0x4>,    /* rx1 */
                                <0 187 0x4>,    /* tx1 */
                                <0 192 0x4>,    /* rx2 */
                                <0 188 0x4>,    /* tx2 */
                                <0 193 0x4>,    /* rx3 */
                                <0 189 0x4>;    /* tx3 */
                clocks = <&bpmp_clks TEGRA194_CLK_PLLREFE_VCOOUT>,
                         <&bpmp_clks TEGRA194_CLK_EQOS_AXI>,
                         <&bpmp_clks TEGRA194_CLK_EQOS_RX>,
                         <&bpmp_clks TEGRA194_CLK_EQOS_PTP_REF>,
                         <&bpmp_clks TEGRA194_CLK_EQOS_TX>,
                         <&bpmp_clks TEGRA194_CLK_AXI_CBB>;
                clock-names = "pllrefe_vcoout", "eqos_axi", "eqos_rx", "eqos_ptp_ref", "eqos_tx", "axi_cbb";
                resets = <&bpmp_resets TEGRA194_RESET_EQOS>;
                reset-names = "eqos_rst";
                /* bootloader should update MAC address */
                nvidia,local-mac-address = <0x00 0x00 0x00 0x00 0x00 0x00>;
                iommus = <&smmu TEGRA_SID_EQOS>;
                iommu-group-id = <TEGRA_IOMMU_GROUP_APE>;
                nvidia,csr_clock_speed = <0x19>; /* CSR clock speed 25MHz */
                nvidia,iso_bw = <81920>; /* sum of read and write bw, 80Mb/s */
                nvidia,rx_riwt = <124>; /* usec value for Rx watchdog interrupt */
                nvidia,slot_intvl_val = <0x07C>;
                status = "disabled";
                eqos_cool_dev: eqos-cool-dev {
                        cooling-min-state = <0>;
                        cooling-max-state = <5>;
                        #cooling-cells = <2>;

        ether_qos@2490000 {
                status = "okay";

        ether_qos@2490000 {
                nvidia,phy-reset-gpio = <&tegra_main_gpio TEGRA194_MAIN_GPIO(R, 1) 0>;
                nvidia,phy-reset-post-delay = <224>;
                nvidia,phy-reset-duration = <10000>;
                mdio {
                        compatible = "nvidia,eqos-mdio";
                        #address-cells = <1>;
                        #size-cells = <0>;
                        phy0: ethernet-phy@0 {
                                reg = <1>;

        ether_qos@2490000 {
                vddio_sys_enet_bias-supply = <&battery_reg>;
                vddio_enet-supply = <&battery_reg>;
                phy_vdd_1v8-supply = <&p3668_spmic_sd2>;        /*sd2_vdd_1v8ls */
                phy_ovdd_rgmii-supply = <&p3668_spmic_sd2>;
                phy_pllvdd-supply = <&battery_reg>;

And I didn’t add any setting of eth0 in /etc/network/interface.
I run the “sudo ethtool eth0” when connecting a gigabit cable, then get:

nvidia@nvidia-desktop:~$ sudo ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

1,we desgined the carrier board,NX—transform—RJ45
2,as follow information.
3,ubuntun OS
4,SWITCH support 1000M

The above shows this is already capable of gigabit if everything else is working. The carrier board wiring must match the device tree, and any device tree component not set up for this carrier board may not function correctly. If you go to the following URL (you will probably need to go here, login, and then click the link again) for documents, there are design guide documents, and the PINMUX spreadsheet (which uses macros) you should check:$product,jetson_xavier_nx

Note that the combination of your supported link modes includes 1000baseT, and simultaneously the advertised link speed broadcasts this capability. The link partner (the switch) advertised 1000baseT/Full as well, and so this must be either a software configuration issue or device tree issue. The actual hardware appears to be accurately reporting gigabit capabilities.

As a test you might see what happens when you force gigabit:
sudo ethtool -s eth0 speed 1000 duplex
…then see if reported speed goes to 1000 from the ethtool, and if the interface actually functions correctly.

If this succeeds, and speed goes to 1000 with valid function, then perhaps this is NetworkManager interfering. However, if manually attempting gigabit fails, then I would have to suspect device tree (the realm of the PINMUX spreadsheet).

For the case of manual ethtool operating succeeding in running gigabit (knowing device tree is likely correct), then you could browse around in the application “sudo nm-connection-editor” (if you don’t have this, then “sudo apt-get add network-manager-gnome”).

also it might be possible to enforce 1GB at the switch/router;
Moreover, the copper wire should be of corresponding standard, all 8 separate wires within the cable need to be connected to RJ45 connectors on both sides and in proper order;
Cat 6 cable supports up to 10GB; 5e cable will support 1GB, cat5 cable will support only up to 100mb/s

Please try the command linuxdev provided first.

sudo ethtool -s eth0 speed 1000 duplex

Also, you could firstly disable auto-negotiation before running this command.

Hi Linuxdev,

I’ve tried “sudo ethtool -s eth0 speed 1000 duplex”, but it returned:

nvidia@nvidia-desktop:~$ sudo ethtool -s eth0 speed 1000 duplex
ethtool: bad command line argument(s)
For more information run ethtool -h

When I run “sudo nm-connection-editor” and set “Link negotiation” to Mannul with speed 1000Mb/s and duplex full,
the speed went to 1000Mb/s, but the interface didn’t work.

My pinmux of eqos is set as:

nvidia@nvidia-desktop:~$ sudo grep eqos /sys/kernel/debug/tegra_pinctrl_reg
Bank: 0 Reg: 0x02445000 Val: 0x00022400 -> eqos_td3_pe4
Bank: 0 Reg: 0x02445008 Val: 0x00022400 -> eqos_td2_pe3
Bank: 0 Reg: 0x02445010 Val: 0x00022400 -> eqos_td1_pe2
Bank: 0 Reg: 0x02445018 Val: 0x00022400 -> eqos_td0_pe1
Bank: 0 Reg: 0x02445020 Val: 0x00022450 -> eqos_rd3_pf1
Bank: 0 Reg: 0x02445028 Val: 0x00022450 -> eqos_rd2_pf0
Bank: 0 Reg: 0x02445030 Val: 0x00022450 -> eqos_rd1_pe7
Bank: 0 Reg: 0x02445038 Val: 0x00022440 -> eqos_sma_mdio_pf4
Bank: 0 Reg: 0x02445040 Val: 0x00022450 -> eqos_rd0_pe6
Bank: 0 Reg: 0x02445048 Val: 0x00022400 -> eqos_sma_mdc_pf5
Bank: 0 Reg: 0x02445050 Val: 0x00002000 -> eqos_comp
Bank: 0 Reg: 0x02445058 Val: 0x00022400 -> eqos_txc_pe0
Bank: 0 Reg: 0x02445060 Val: 0x00022450 -> eqos_rxc_pf3
Bank: 0 Reg: 0x02445068 Val: 0x00022400 -> eqos_tx_ctl_pe5
Bank: 0 Reg: 0x02445070 Val: 0x00022450 -> eqos_rx_ctl_pf2

Try this:
sudo mii-tool -F 1000baseT-FD eth0

I’m not sure why ethtool is not working for this.

@295839633 what category of twisted pair are you using? what router/switch model? if the mode is explicitly set to full duplex at Jetson it will also need to be set to the same at the router/switch device.


Hi Linuxdev,

We measured the mdio signals.
When the cable plugged, the two pairs of signals 100M existed, but another two pairs of signals for 1000M didn’t exist.
If I set 1000M manually, either the signals for 100M or 1000M didn’t exist.

Is there any interface that I can read/write the value of pyh_register by?

Someone from NVIDIA may know that answer. What comes to mind though when 100base-T works, but not gigabit, is that you may be missing two of the wires. “Missing” may not mean physically missing, but could also mean a device tree being incomplete. If those are missing I could also see auto negotiation failing.

Sorry for late reply. This is an issue on devkit, right?

I want to try it with my NX too. Does anyone else also hit this problem?

It is HW issue,It becomes OK when we remove TVS part between line to line.I want do LAN EA test,Can you provide LAN test tool.

could you elaborate what is the TVS part?