Ethernet PHY bring-up on Jetson Orin: DP83867 and EQOS RGMII

Q: Why is my DP83867 PHY not detected on Jetson Orin?

The most common causes are: MDIO/MDC pins not configured in the pinmux DTS, wrong PHY address in the EQOS device tree node, reset GPIO not toggling correctly, or the EQOS clock not being enabled. Run dmesg | grep -i eqos and dmesg | grep -i mdio to see which step is failing.

Q: What RGMII mode should I use for the DP83867 on Jetson Orin?

For RGMII with internal delays configured in the DP83867 (using its strapping or register settings), use phy-mode = rgmii in the DTS. If the PHY handles only RX delay internally, use rgmii-rxid. If your PCB has external delay components, use plain rgmii. The common mistake is double-counting delays — enabling them in both the DTS and PHY strapping.

Q: How do I configure the MDIO bus for EQOS on Jetson Orin?

In the device tree, MDIO is a sub-node of the EQOS node. The PHY must be declared as a child of the mdio node with the correct reg = . The PHY address is determined by strap pins on the DP83867 (PHYAD[2:0]). Also ensure the MDIO and MDC pins are enabled in the pinmux section of your carrier board DTS.

Q: What is the EQOS PHY address for DP83867 on Jetson Orin?

The PHY address depends on the strap pins (PHYAD[2:0]) on your PCB. DP83867 supports addresses 0x00 through 0x1F. The most common design uses address 0x00 or 0x01. Check your schematic for the strap resistor values and confirm with i2cdetect or mdio-tool on the MDIO bus.

Q: Does the Jetson Orin EQOS support 1G Ethernet on a custom carrier board?

Yes. Orin's EQOS controller supports 10/100/1000 Mbps Ethernet via RGMII. The AGX Orin also has a separate MGBE (Multi-Gigabit Backplane Ethernet) controller for 10G/25G. For standard 1G designs, EQOS + DP83867 is the reference configuration.

Key Insights

Ethernet bring-up with DP83867 on Jetson Orin fails at one of four points: MDIO/MDC not in pinmux, wrong PHY address, RGMII delay double-counted, or EQOS clock not enabled
RGMII delay misconfiguration is the most insidious — if you enable delays in both the DTS (rgmii-id) and the DP83867’s strap pins, they stack and violate RGMII timing
The PHY address in the DTS reg field must exactly match the PHYAD[2:0] strap resistors on your PCB — check your schematic, don’t guess
A link that comes up but drops packets almost always points to RGMII timing — wrong delay mode or missing termination
dmesg | grep -i eqos and dmesg | grep -i mdio in sequence tells you exactly which layer is failing

The EQOS + RGMII architecture on Jetson Orin

Jetson Orin (Tegra234) has two Ethernet controllers:

EQOS (Ethernet Quality of Service): standard 1G/100M/10M controller, RGMII interface to PHY. This is what you use with the DP83867.
MGBE (Multi-Gigabit Backplane Ethernet): 10G/25G, USXGMII/XFI interface. Not relevant to DP83867 designs.

The DP83867 is TI’s widely-used Gigabit Ethernet PHY. It connects to the Orin via RGMII (Reduced Gigabit MII) — 4-bit data paths with source synchronous clocking — and is configured over MDIO (Management Data Input/Output).

The failure modes are well-understood, but the diagnostic messages in dmesg are not always obvious about which layer is failing.

Step 1: verify MDIO/MDC pinmux

The MDIO and MDC signals use Jetson SoM pins that must be explicitly enabled in the carrier board device tree. If these pins are in their default state (often HDMI or SFIO mode on Orin), the MDIO bus won’t work and the PHY won’t be detected.

Check your carrier board DTS for these pin configurations:

/* In your pinmux section */
eqos_mdio_pf5 {
    nvidia,pins = "eqos_mdio_pf5";
    nvidia,function = "eqos";
    nvidia,pull = <TEGRA_PIN_PULL_NONE>;
    nvidia,tristate = <TEGRA_PIN_DISABLE>;
    nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};

eqos_mdc_pf4 {
    nvidia,pins = "eqos_mdc_pf4";
    nvidia,function = "eqos";
    nvidia,pull = <TEGRA_PIN_PULL_NONE>;
    nvidia,tristate = <TEGRA_PIN_DISABLE>;
    nvidia,enable-input = <TEGRA_PIN_DISABLE>;
};

Also verify the RGMII data pins (TX and RX data lanes, clocks) are all set to nvidia,function = "eqos" in the pinmux section. Missing even one pin in the pinmux block causes subtle failures — link may appear but drop packets.

Step 2: confirm the PHY address

The DP83867 PHY address is set by its PHYAD[2:0] strap pins at power-on. Check your schematic for the resistor dividers or pull resistors on these pins. The most common values are 0x00 and 0x01.

Your EQOS device tree node must declare this address correctly:

&eqos {
    phy-mode = "rgmii-id";
    phy-reset-gpios = <&tegra_aon_gpio TEGRA234_AON_GPIO(EE, 2) GPIO_ACTIVE_LOW>;

    mdio {
        #address-cells = <1>;
        #size-cells = <0>;

        ethernet_phy0: ethernet-phy@0 {
            reg = <0x0>;    /* DP83867 PHYAD address — must match strap */
            compatible = "ethernet-phy-id2000.a231"; /* DP83867 PHY ID */
        };
    };
};

A wrong address means the EQOS driver’s PHY scan finds nothing and Ethernet is dead. You can verify the actual PHY address by enabling MDIO debug or using ethtool -d eth0 to attempt register reads.

If the PHY address is wrong in the DTS, dmesg shows:

eqos 6800000.ethernet: no PHY found
eqos 6800000.ethernet: Could not attach to PHY

Step 3: RGMII delay configuration

This is where most teams get stuck. RGMII requires setup and hold timing on the TX and RX data paths. These delays can be implemented in hardware (PCB trace length), in the PHY (internal delay settings), or in the MAC (through device tree phy-mode).

The DP83867 has configurable internal delays. Its phy-mode in the DTS must match how the delays are actually implemented:

phy-mode	What it means
`rgmii`	No delays in MAC or PHY — use PCB delays
`rgmii-id`	MAC applies both TX and RX internal delays
`rgmii-txid`	MAC applies TX delay only; PHY or PCB handles RX
`rgmii-rxid`	MAC applies RX delay only; PHY or PCB handles TX

The most common mistake: using rgmii-id in the DTS (MAC applies both delays) while also enabling internal delays in the DP83867 via strapping or register writes. This doubles the delay, violates RGMII timing, and causes link problems — often “link up but no data” or extreme packet loss.

For a typical design where the DP83867 handles its own internal delays (common reference design choice):

phy-mode = "rgmii";    /* No MAC delays — PHY handles it internally */

Then configure the DP83867 delays via its registers at boot, or use the DP83867’s strap pins to set the delay mode before the driver takes control.

For the NVIDIA DevKit reference design, look at the reference DTS for your carrier board — it shows how NVIDIA configured the delay mode for the KSZ9031 or DP83867 on the reference carrier.

Step 4: reset GPIO timing

The DP83867 requires a hardware reset on power-up. The reset is active-low, and the Orin GPIO must be configured correctly in both the DTS and the pinmux.

phy-reset-gpios = <&gpio TEGRA234_MAIN_GPIO(G, 5) GPIO_ACTIVE_LOW>;
phy-reset-duration-us = <10000>;    /* 10ms reset pulse */
phy-reset-post-delay-us = <50000>;  /* 50ms after deassertion */

If the reset GPIO is wrong (wrong bank, wrong pin, or wrong polarity), the PHY comes up in an undefined state and MDIO register reads return garbage or fail entirely.

Check the reset GPIO against your schematic. Also verify the GPIO pin is configured as output in pinmux (not tristated). A tristated reset GPIO means the PHY may or may not be in reset depending on board-level pull resistors.

Step 5: EQOS clock enable

The EQOS controller needs specific clocks enabled. These are usually handled by the NVIDIA BSP, but on custom carrier boards with modified power domain configurations, they can be missed.

Run this to check clock state:

# On Jetson: check EQOS-related clocks
sudo cat /sys/kernel/debug/clk/clk_summary | grep -i eqos

All relevant EQOS clocks should show non-zero reference counts when Ethernet is in use. If clk_ref_count is 0 for the main EQOS clocks when the interface should be up, that’s your problem.

Diagnostic command sequence

Work through this in order:

# 1. Check if EQOS is probing
sudo dmesg | grep -i eqos

# 2. Check MDIO/PHY detection
sudo dmesg | grep -i "phy\|mdio"

# 3. Check Ethernet interface state
ip link show eth0
ethtool eth0

# 4. Force link attempt
sudo ip link set eth0 up
sudo dmesg | tail -20   # Look for link partner negotiation

# 5. Check PHY registers if accessible
sudo ethtool -d eth0 2>/dev/null || echo "PHY not accessible"

If step 1 fails (eqos 6800000.ethernet: probe failed), the issue is device tree or clock configuration. If step 2 fails (no PHY found), check PHY address and MDIO pins. If step 3 shows the interface but no link, you’re into RGMII delay or physical layer territory.

For broader bring-up context on custom Jetson carrier boards, see Jetson carrier board not booting: 6 root causes nobody documents and Custom carrier board not booting on Jetson Orin. If you’re stuck on Ethernet PHY bring-up and the steps above haven’t cleared it, book a scoping call.

The TI DP83867 datasheet and application notes — including the RGMII delay configuration tables — are on the TI product page for the DP83867IS. The RGMII specification and timing requirements are defined in the IEEE 802.3 standard.

Frequently Asked Questions

Why is my DP83867 PHY not detected on Jetson Orin?

The most common causes: MDIO/MDC pins not configured in pinmux DTS, wrong PHY address in the EQOS node, reset GPIO not toggling correctly, or EQOS clock not enabled. Check dmesg | grep -i eqos and dmesg | grep -i mdio to see which step is failing.

What RGMII mode should I use for the DP83867 on Jetson Orin?

Use rgmii if the DP83867 handles delays internally (via strapping or register writes). Use rgmii-id if you want the MAC to apply both TX and RX delays. Never apply delays in both MAC and PHY simultaneously — that doubles the delay and breaks timing.

How do I configure the MDIO bus for EQOS on Jetson Orin?

MDIO is a sub-node of the EQOS DTS node. Declare the PHY as a child of the mdio node with reg = <PHY_ADDRESS>. Also ensure MDIO and MDC pins are enabled in the pinmux section. Both steps are required.

What is the EQOS PHY address for DP83867 on Jetson Orin?

It depends on your PCB strap resistors (PHYAD[2:0]). Common designs use address 0x00 or 0x01. Check your schematic for the strap values — the DTS reg value must match exactly.

Does the Jetson Orin EQOS support 1G Ethernet on a custom carrier board?

Yes. Orin’s EQOS controller supports 10/100/1000 Mbps via RGMII. The DP83867 + EQOS combination is the standard reference design for 1G Ethernet on custom Orin carrier boards.

ProventusNova brings up custom Jetson Orin carrier boards including Ethernet PHY, USB, PCIe, and camera peripherals. If you’re stuck on EQOS bring-up, book a scoping call.