AM69 Configuring SGMII Phys

tjohnson · May 14, 2026, 3:11pm

Hello Toradex Support,

I am trying to enable additional ethernet interfaces using DP83867 phys, identical to Eth 2 on the development board. I have tried to configure the serdes and phys similar to the Eth 2 port, but it is not working. I see additional CPSW activity in the boot log, but eventually see platform c000000.ethernet: deferred probe pending, which I think means that the phy is not being found.

Both of these SGMII interfaces are on SERDES1, Q/SGMII Lane3 and Q/SGMII Lane4. Any help would be appreciated. The relevant section of my dt is copied below:

/* Update lane control for our configuration /
/ Definitions in arch/arm/dts/k3-serdes.h /
&serdes_ln_ctrl {
idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, / Aquila PCIE_2 L0 (TPR)    /
<J784S4_SERDES0_LANE1_PCIE1_LANE1>,     / Aquila PCIE_2 L1 (TPR)    /
<J784S4_SERDES0_LANE2_PCIE3_LANE0>,     / On-module PCIe Wi-Fi      /
<J784S4_SERDES0_LANE3_USB>,             / Aquila USB0 SS            /
<J784S4_SERDES1_LANE0_QSGMII_LANE3>,    / ETH_9 SGMII               /
<J784S4_SERDES1_LANE1_QSGMII_LANE4>,    / ETH_4 SGMII               /
<J784S4_SERDES1_LANE2_PCIE2_LANE0>,     / On-module PCIe USB Bridge /
<J784S4_SERDES1_LANE3_QSGMII_LANE2>,    / Aquila SGMII MSP_9        /
<J784S4_SERDES2_LANE0_QSGMII_LANE5>,    / Aquila SGMII MSP_6        /
<J784S4_SERDES2_LANE1_QSGMII_LANE6>,    / Aquila SGMII MSP_7        /
<J784S4_SERDES2_LANE2_QSGMII_LANE7>,    / Aquila SGMII MSP_8        /
<J784S4_SERDES2_LANE3_QSGMII_LANE8>,    / Aquila ETH_2 xGMII        /
<J784S4_SERDES4_LANE0_EDP_LANE0>,       / Aquila DP L0              /
<J784S4_SERDES4_LANE1_EDP_LANE1>,       / Aquila DP L1              /
<J784S4_SERDES4_LANE2_EDP_LANE2>,       / Aquila DP L2              /
<J784S4_SERDES4_LANE3_EDP_LANE3>;       / Aquila DP L3              */
};

/* AM69 Ethernet switch */
&main_cpsw0 {
status = “okay”;
};

&serdes1 {
/delete-property/ serdes1_pcie0_2l_link;

serdes1_eth9_sgmii_link: phy@0 {
    reg = <0>;
    #phy-cells = <0>;
    resets = <&serdes_wiz1 1>;
    cdns,num-lanes = <1>;
    cdns,phy-type = <PHY_TYPE_SGMII>;
};

serdes1_eth4_sgmii_link: phy@1 {
    reg = <1>;
    #phy-cells = <0>;
    resets = <&serdes_wiz1 2>;
    cdns,num-lanes = <1>;
    cdns,phy-type = <PHY_TYPE_SGMII>;
};

};

/* TILE Eth 4 SGMII PHY */
&main_cpsw0_port4 {
phy-mode = “sgmii”;
phys = <&cpsw0_phy_gmii_sel 4>, <&serdes1_eth4_sgmii_link>;
phy-names = “mac”, “serdes”;
phy-handle = <&cpsw0_port4_phy4>;
status = “okay”;
};

/* TILE Eth 9 SGMII PHY */
&main_cpsw0_port3 {
phy-mode = “sgmii”;
phys = <&cpsw0_phy_gmii_sel 3>, <&serdes1_eth9_sgmii_link>;
phy-names = “mac”, “serdes”;
phy-handle = <&cpsw0_port3_phy4>;
status = “okay”;
};

/* TILE Ethernet PHY */
&main_cpsw0_mdio {
status = “okay”;

/* TILE Eth 4 SGMII */
cpsw0_port4_phy4: ethernet-phy@4 {
	reg = <4>;
};

/* TILE Eth 9 SGMII */
cpsw0_port3_phy4: ethernet-phy@4 {
	reg = <4>;
};

};

ToradexAI · May 14, 2026, 3:12pm

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

(1), (2), (3), (4), (5), (6), (7)

I’d be glad to help with your SGMII PHY configuration! To provide the most accurate guidance, could you please specify which OS and version you are running on your Aquila AM69? (2)

Common platforms include:

Hardware: Aquila AM69, Verdin iMX8M Plus, Verdin AM62, Apalis iMX8QP
Operating System: Yocto 7.2.0, Torizon OS 6, BSP 7, Torizon OS 7.2.0-build.13
Integration: Device tree overlays, ethernet configuration, PHY setup

You can get detailed information about your system using the tdx-info command. For more details about this tool, see: Getting Device Information with Tdx-Info | Toradex Developer Center

Looking at your device tree configuration, I notice a potential issue with your PHY addressing. Both PHYs are configured with reg = <4>, which would create an address conflict on the MDIO bus (5). The “deferred probe pending” error you’re seeing often indicates that the driver is waiting for a resource (like a PHY) that isn’t available, which could be due to this addressing conflict (5).

Once you provide the OS version information, I can give you more specific guidance on configuring the SGMII interfaces and resolving the PHY detection issues.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

tjohnson · May 14, 2026, 3:13pm

@ToradexAI I am using Yocto 7.5.0 on our Aquila AM69.

ToradexAI · May 14, 2026, 3:13pm

Based on your Yocto 7.5.0 setup on Aquila AM69, I can see the issue with your SGMII PHY configuration. The “deferred probe pending” error is commonly caused by PHY addressing conflicts or missing dependencies (1).

Primary Issue: PHY Address Conflict

Your device tree has both PHYs configured with the same MDIO address:

/* TILE Eth 4 SGMII */
cpsw0_port4_phy4: ethernet-phy@4 {
	reg = <4>;
};

/* TILE Eth 9 SGMII */
cpsw0_port3_phy4: ethernet-phy@4 {
	reg = <4>;
};

Both PHYs cannot share the same MDIO address (4) on the same bus (1). Each PHY needs a unique address.

Configuration Recommendations

Fix PHY Addresses: Assign unique MDIO addresses to each PHY:

/* TILE Eth 4 SGMII */
cpsw0_port4_phy4: ethernet-phy@4 {
	reg = <4>;
};

/* TILE Eth 9 SGMII */
cpsw0_port3_phy3: ethernet-phy@3 {
	reg = <3>;
};

Update PHY Handles: Correct the phy-handle reference for port 3:

&main_cpsw0_port3 {
	phy-mode = "sgmii";
	phys = <&cpsw0_phy_gmii_sel 3>, <&serdes1_eth9_sgmii_link>;
	phy-names = "mac", "serdes";
	phy-handle = <&cpsw0_port3_phy3>;  /* Changed from phy4 to phy3 */
	status = "okay";
};

Add PHY Properties: Include necessary PHY configuration properties:

cpsw0_port4_phy4: ethernet-phy@4 {
	reg = <4>;
	compatible = "ethernet-phy-ieee802.3-c22";
};

cpsw0_port3_phy3: ethernet-phy@3 {
	reg = <3>;
	compatible = "ethernet-phy-ieee802.3-c22";
};

Additional Considerations

The Aquila AM69 module features an 8-port Serial Ethernet with SGMII interface, of which 5 ports are available (2). Ensure your hardware PHY addresses match the device tree configuration.

For device tree overlays on Aquila AM69, you can reference the available overlays in BSP 7.x (3).

Debugging Steps

Check kernel logs for PHY detection: dmesg | grep -i phy
Verify MDIO bus enumeration: dmesg | grep -i mdio
Confirm SERDES link status in boot logs

The deferred probe issue should resolve once the PHY addressing conflict is fixed and the PHYs can be properly detected on the MDIO bus (1).

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

tjohnson · May 14, 2026, 3:26pm

@ToradexAI I thought that having multiple PHYs with the same address would be OK because they are using different SGMII interface; do all ports on CSPW0 share the same MAC?

ToradexAI · May 14, 2026, 3:26pm

You raise an excellent point about SGMII interfaces and MDIO addressing. Let me clarify the CPSW architecture for you.

CPSW MDIO Bus Architecture

All ports on the CPSW (Common Platform Ethernet Switch) typically share a single MDIO bus (1). This means that even though you have different SGMII interfaces (SERDES lanes), the PHY management still occurs through one shared MDIO controller. Therefore, each PHY connected to any CPSW port must have a unique MDIO address on that shared bus (1).

CPSW Port Structure

The CPSW is an Ethernet switch with multiple ports, where:

Each port can have its own MAC interface (RGMII, SGMII, etc.)
Each port connects to its own external PHY
All PHYs are managed through the shared MDIO bus
Each port gets its own network interface in Linux (eth0, eth1, etc.)

Your Configuration Issue

In your device tree, both PHYs are configured on the same MDIO bus (&main_cpsw0_mdio) with the same address:

&main_cpsw0_mdio {
    status = "okay";
    
    /* Both PHYs have reg = <4> - this creates a conflict */
    cpsw0_port4_phy4: ethernet-phy@4 {
        reg = <4>;
    };
    
    cpsw0_port3_phy4: ethernet-phy@4 {
        reg = <4>;
    };
};

Even though these PHYs connect through different SERDES lanes (SGMII interfaces), they both appear on the same MDIO bus and therefore need unique addresses (2).

Correct Configuration

Each PHY needs a unique MDIO address:

&main_cpsw0_mdio {
    status = "okay";
    
    cpsw0_port4_phy4: ethernet-phy@4 {
        reg = <4>;
        compatible = "ethernet-phy-ieee802.3-c22";
    };
    
    cpsw0_port3_phy3: ethernet-phy@3 {
        reg = <3>;
        compatible = "ethernet-phy-ieee802.3-c22";
    };
};

The SGMII interfaces provide the high-speed serial data paths, but PHY management (reading status, configuring settings) still happens through the shared MDIO bus, which is why unique addressing is required (1).

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

tjohnson · May 14, 2026, 9:08pm

@ToradexAI I have adjusted the address of my phys to be unique, and have updated the device tree accordingly. The relevant code is pasted below.

The phys are still not recognized. Looking at the output of several dmesg commands, it appears that the serdes is failing with an error:

root@aquila-am69-12594727:~# dmesg | grep -i phy
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd080]
[ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys).
[ 2.986630] cdns-torrent-phy: probe of 5070000.serdes failed with error -22
[ 4.359717] davinci_mdio 46000f00.mdio: phy[0]: device 46000f00.mdio:00, driver TI DP83867
[ 8.803178] am65-cpsw-nuss 46000000.ethernet eth0: PHY [46000f00.mdio:00] driver [TI DP83867] (irq=371)
[ 8.816250] am65-cpsw-nuss 46000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
root@aquila-am69-12594727:~# demsg | grep -i mdio
-sh: demsg: command not found
root@aquila-am69-12594727:~# demesg | grep -i mdio
-sh: demesg: command not found
root@aquila-am69-12594727:~# dmesg | grep -i mdio
[ 2.756745] davinci_mdio 46000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[ 4.348753] davinci_mdio 46000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[ 4.359717] davinci_mdio 46000f00.mdio: phy[0]: device 46000f00.mdio:00, driver TI DP83867
[ 8.803178] am65-cpsw-nuss 46000000.ethernet eth0: PHY [46000f00.mdio:00] driver [TI DP83867] (irq=371)
root@aquila-am69-12594727:~#

/* Update lane control for our configuration /
/ Definitions in arch/arm/dts/k3-serdes.h /
&serdes_ln_ctrl {
idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, / Aquila PCIE_2 L0 (TPR)    /
<J784S4_SERDES0_LANE1_PCIE1_LANE1>,     / Aquila PCIE_2 L1 (TPR)    /
<J784S4_SERDES0_LANE2_PCIE3_LANE0>,     / On-module PCIe Wi-Fi      /
<J784S4_SERDES0_LANE3_USB>,             / Aquila USB0 SS            /
<J784S4_SERDES1_LANE0_QSGMII_LANE3>,    / ETH_9 SGMII               /
<J784S4_SERDES1_LANE1_QSGMII_LANE4>,    / ETH_4 SGMII               /
<J784S4_SERDES1_LANE2_PCIE2_LANE0>,     / On-module PCIe USB Bridge /
<J784S4_SERDES1_LANE3_QSGMII_LANE2>,    / Aquila SGMII MSP_9        /
<J784S4_SERDES2_LANE0_QSGMII_LANE5>,    / Aquila SGMII MSP_6        /
<J784S4_SERDES2_LANE1_QSGMII_LANE6>,    / Aquila SGMII MSP_7        /
<J784S4_SERDES2_LANE2_QSGMII_LANE7>,    / Aquila SGMII MSP_8        /
<J784S4_SERDES2_LANE3_QSGMII_LANE8>,    / Aquila ETH_2 xGMII        /
<J784S4_SERDES4_LANE0_EDP_LANE0>,       / Aquila DP L0              /
<J784S4_SERDES4_LANE1_EDP_LANE1>,       / Aquila DP L1              /
<J784S4_SERDES4_LANE2_EDP_LANE2>,       / Aquila DP L2              /
<J784S4_SERDES4_LANE3_EDP_LANE3>;       / Aquila DP L3              */
};

/* AM69 Ethernet switch */
&main_cpsw0 {
status = “okay”;
};

&serdes1 {
/delete-property/ serdes1_pcie0_2l_link;

serdes1_eth9_sgmii_link: phy@0 {
    reg = <0>;
    #phy-cells = <0>;
    resets = <&serdes_wiz1 1>;
    cdns,num-lanes = <1>;
    cdns,phy-type = <PHY_TYPE_SGMII>;
};

serdes1_eth4_sgmii_link: phy@1 {
    reg = <1>;
    #phy-cells = <0>;
    resets = <&serdes_wiz1 2>;
    cdns,num-lanes = <1>;
    cdns,phy-type = <PHY_TYPE_SGMII>;
};

};

/* TILE Eth 4 SGMII PHY */
&main_cpsw0_port4 {
phy-mode = “sgmii”;
phys = <&cpsw0_phy_gmii_sel 4>, <&serdes1_eth4_sgmii_link>;
phy-names = “mac”, “serdes”;
phy-handle = <&cpsw0_port4_phy4>;
status = “okay”;
};

/* TILE Eth 9 SGMII PHY */
&main_cpsw0_port3 {
phy-mode = “sgmii”;
phys = <&cpsw0_phy_gmii_sel 3>, <&serdes1_eth9_sgmii_link>;
phy-names = “mac”, “serdes”;
phy-handle = <&cpsw0_port3_phy5>;
status = “okay”;
};

/* TILE Ethernet PHY */
&main_cpsw0_mdio {
status = “okay”;

/* TILE Eth 4 SGMII */
cpsw0_port4_phy4: ethernet-phy@4 {
	reg = <4>;
};

/* TILE Eth 9 SGMII */
cpsw0_port3_phy5: ethernet-phy@5 {
	reg = <5>;
};

};

ToradexAI · May 14, 2026, 9:08pm

The SERDES probe failure is the root cause of your PHY detection issues. The error cdns-torrent-phy: probe of 5070000.serdes failed with error -22 indicates SERDES1 is failing to initialize properly (1).

SERDES Configuration Issues

Looking at your configuration, there are several potential issues with the SERDES1 setup:

1. SERDES Lane Mapping Conflict

Your lane control configuration shows conflicting assignments for SERDES1:

<J784S4_SERDES1_LANE0_QSGMII_LANE3>,    /* ETH_9 SGMII */
<J784S4_SERDES1_LANE1_QSGMII_LANE4>,    /* ETH_4 SGMII */
<J784S4_SERDES1_LANE2_PCIE2_LANE0>,     /* On-module PCIe USB Bridge */
<J784S4_SERDES1_LANE3_QSGMII_LANE2>,    /* Aquila SGMII MSP_9 */

The issue is that you’re trying to use both QSGMII and individual SGMII lanes on the same SERDES. According to the AM69 SerDes specifications, when using QSGMII configuration, all four lanes should be configured together as a group.

2. Reset Configuration Problem

Your SERDES PHY definitions have incorrect reset assignments:

serdes1_eth9_sgmii_link: phy@0 {
    resets = <&serdes_wiz1 1>;  /* Should likely be 0 for lane 0 */
};

serdes1_eth4_sgmii_link: phy@1 {
    resets = <&serdes_wiz1 2>;  /* Should likely be 1 for lane 1 */
};

Recommended Configuration

For proper SGMII configuration on SERDES1, try this approach:

&serdes_ln_ctrl {
    idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>,
                  <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
                  <J784S4_SERDES0_LANE2_PCIE3_LANE0>,
                  <J784S4_SERDES0_LANE3_USB>,
                  <J784S4_SERDES1_LANE0_QSGMII_LANE3>,    /* ETH_9 SGMII */
                  <J784S4_SERDES1_LANE1_QSGMII_LANE4>,    /* ETH_4 SGMII */
                  <J784S4_SERDES1_LANE2_IP1_UNUSED>,      /* Disable conflicting PCIe */
                  <J784S4_SERDES1_LANE3_IP1_UNUSED>,      /* Disable conflicting SGMII */
                  /* Continue with other SERDES configurations */;
};

&serdes1 {
    /delete-property/ serdes1_pcie0_2l_link;
    
    serdes1_eth9_sgmii_link: phy@0 {
        reg = <0>;
        #phy-cells = <0>;
        resets = <&serdes_wiz1 0>;
        cdns,num-lanes = <1>;
        cdns,phy-type = <PHY_TYPE_SGMII>;
    };
    
    serdes1_eth4_sgmii_link: phy@1 {
        reg = <1>;
        #phy-cells = <0>;
        resets = <&serdes_wiz1 1>;
        cdns,num-lanes = <1>;
        cdns,phy-type = <PHY_TYPE_SGMII>;
    };
};

Debugging Steps

Check SERDES status: dmesg | grep -i serdes
Verify clock configuration: Ensure reference clocks are properly configured for SGMII
Check for conflicts: Make sure no other device tree nodes are claiming the same SERDES lanes

The key issue is that SERDES1 must be properly initialized before the CPSW ports can use the SGMII links (1). The error -22 (EINVAL) suggests invalid configuration parameters are being passed to the SERDES driver.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

tjohnson · May 14, 2026, 9:22pm

@ToradexAI I do not see a conflict here. According to the J78S4 AM69x TRM, the PCIe and QSGMII configurations should all be compatible with a 100 MHz reference clock:

I based my serdes_wiz configuration based on what I see in the k3-am69-aquila.dtsi file for Eth2:

&serdes2 {
status = “disabled”;

/* Aquila ETH_2 xGMII */
serdes2_sgmii_link: phy@3 {
    reg = <3>;
    #phy-cells = <0>;
    resets = <&serdes_wiz2 4>;
    cdns,num-lanes = <1>;
    cdns,phy-type = <PHY_TYPE_SGMII>;
};

};

Here the reset is 4, even though the actual lane used is 8.

ToradexAI · May 14, 2026, 9:23pm

You’re absolutely correct about the TI TRM compatibility table. The issue isn’t with clock compatibility but rather with the SERDES probe failure itself. Looking at your reference to the Aquila ETH_2 configuration, you’ve identified an important pattern in the reset numbering.

SERDES Reset Mapping Analysis

The Aquila ETH_2 configuration you referenced shows:

serdes2_sgmii_link: phy@3 {
    reg = <3>;
    #phy-cells = <0>;
    resets = <&serdes_wiz2 4>;
    cdns,num-lanes = <1>;
    cdns,phy-type = <PHY_TYPE_SGMII>;
};

This suggests the reset index doesn’t directly correspond to the lane number but follows a different mapping scheme specific to the SERDES wizard controller.

Revised Configuration

Based on the Aquila reference pattern, try adjusting your reset indices:

&serdes1 {
    /delete-property/ serdes1_pcie0_2l_link;
    
    serdes1_eth9_sgmii_link: phy@0 {
        reg = <0>;
        #phy-cells = <0>;
        resets = <&serdes_wiz1 3>;  /* Adjusted based on Aquila pattern */
        cdns,num-lanes = <1>;
        cdns,phy-type = <PHY_TYPE_SGMII>;
    };
    
    serdes1_eth4_sgmii_link: phy@1 {
        reg = <1>;
        #phy-cells = <0>;
        resets = <&serdes_wiz1 4>;  /* Adjusted based on Aquila pattern */
        cdns,num-lanes = <1>;
        cdns,phy-type = <PHY_TYPE_SGMII>;
    };
};

Additional Debugging

Since the SERDES probe is failing with error -22, check:

SERDES clock configuration: Verify the reference clock is properly configured
Device tree validation: Use dtc to check for any syntax errors
Kernel configuration: Ensure SERDES_CADENCE_TORRENT is enabled in your kernel config

The fact that you see the MDIO bus working (detecting the RGMII PHY at address 0) suggests the basic CPSW infrastructure is functional, but the SERDES1 initialization is preventing the SGMII ports from becoming available.

Try the adjusted reset indices first, as this appears to be a common pattern in the Aquila device tree configurations.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

tjohnson · May 14, 2026, 9:34pm

@ToradexAI Can you explain the serdes_wiz reset numbering pattern that you are following? I do not understand how you got the numbers in your previous response.

ToradexAI · May 14, 2026, 9:34pm

(1)(2)(3)(4)(5)

You’re absolutely right to question my previous reset numbering - I made an error in my analysis and cannot adequately explain the pattern I suggested. Let me be more precise about what we actually know.

What We Know from the Aquila Reference

From the k3-am69-aquila.dtsi file you referenced:

serdes2_sgmii_link: phy@3 {
    reg = <3>;
    #phy-cells = <0>;
    resets = <&serdes_wiz2 4>;
    cdns,num-lanes = <1>;
    cdns,phy-type = <PHY_TYPE_SGMII>;
};

This shows:

Lane 3 (reg = <3>) uses reset index 4 (resets = <&serdes_wiz2 4>)
But this is on SERDES2, not SERDES1

The Problem with My Previous Suggestion

I incorrectly extrapolated a pattern without sufficient data. The reset numbering scheme for serdes_wiz controllers is specific to each SERDES instance and may not follow a simple mathematical relationship.

Recommended Approach

Since the exact reset mapping for SERDES1 lanes isn’t clear from the available documentation, I suggest:

Check the complete device tree source for any existing SERDES1 SGMII configurations
Try systematic testing with different reset indices:
- Start with matching your original approach: lane 0 → reset 0, lane 1 → reset 1
- If that fails, try the TI documentation or reference designs
Examine the kernel logs more closely for specific SERDES configuration errors:

dmesg | grep -A5 -B5 "serdes.*error"

Without access to the complete AM69 device tree sources or TI’s specific SERDES wizard documentation for this configuration, I cannot definitively state the correct reset mapping pattern.

The SERDES probe failure (error -22) suggests a configuration parameter issue that may be related to clock settings, lane assignments, or other factors beyond just the reset numbering.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

tjohnson · May 15, 2026, 6:32pm

@ToradexAI We found one issue that seems to have helped: /delete-property/ should have been /delete-node/ when removing the serdes1_pcie0_2l_link from serdes1. Now I see a new mdio interface (c000f00.mdio):

root@aquila-am69-12594727:~# mdio
46000f00.mdio
c000f00.mdio
fixed-0

root@aquila-am69-12594727:~#

However, I do not see any new network interfaces when using ifconfig.

In the definition of serdes_wiz1, I see that reset 0 is already being used by serdes node in serdes_wiz1, so I think this is why the numbering for lanes starts at 1 instead of 0.

	serdes_wiz1: wiz@5070000 {
		compatible = "ti,j784s4-wiz-10g";
		#address-cells = <1>;
		#size-cells = <1>;
		power-domains = <&k3_pds 405 TI_SCI_PD_EXCLUSIVE>;
		clocks = <&k3_clks 405 2>, <&k3_clks 405 6>, <&serdes_refclk>, <&k3_clks 405 5>;
		clock-names = "fck", "core_ref_clk", "ext_ref_clk", "core_ref1_clk";
		assigned-clocks = <&k3_clks 405 6>;
		assigned-clock-parents = <&k3_clks 405 10>;
		num-lanes = <4>;
		#reset-cells = <1>;
		#clock-cells = <1>;
		ranges = <0x05070000 0x00 0x05070000 0x10000>;
		status = "disabled";

		serdes1: serdes@5070000 {
			compatible = "ti,j721e-serdes-10g";
			reg = <0x05070000 0x010000>;
			reg-names = "torrent_phy";
			resets = <&serdes_wiz1 0>;
			reset-names = "torrent_reset";
			clocks = <&serdes_wiz1 TI_WIZ_PLL0_REFCLK>,
				 <&serdes_wiz1 TI_WIZ_PHY_EN_REFCLK>;
			clock-names = "refclk", "phy_en_refclk";
			assigned-clocks = <&serdes_wiz1 TI_WIZ_PLL0_REFCLK>,
					  <&serdes_wiz1 TI_WIZ_PLL1_REFCLK>,
					  <&serdes_wiz1 TI_WIZ_REFCLK_DIG>;
			assigned-clock-parents = <&k3_clks 405 6>,
						 <&k3_clks 405 6>,
						 <&k3_clks 405 6>;
			#address-cells = <1>;
			#size-cells = <0>;
			#clock-cells = <1>;
			status = "disabled";
		};
	};

When attempting to check the mdio interface with mdio, I get a read error:

root@aquila-am69-12594727:~# mdio
46000f00.mdio
c000f00.mdio
fixed-0
root@aquila-am69-12594727:~# mdio c000f00.mdio
ERROR: Unable to read status (-5)
root@aquila-am69-12594727:~#

ToradexAI · May 15, 2026, 6:32pm

Excellent progress! The /delete-node/ fix was key to enabling the SERDES1 configuration. You’re also correct about the reset numbering - reset 0 is reserved for the main SERDES controller itself (1).

MDIO Interface Detection Progress

The appearance of the new MDIO interface (c000f00.mdio) indicates that SERDES1 is now properly initialized and the CPSW ports are attempting to create their MDIO interfaces. This is significant progress from the previous SERDES probe failure.

Network Interface Creation Issue

The fact that you don’t see new network interfaces with ifconfig suggests the CPSW ports are not fully coming online. This is likely because the PHYs still aren’t being detected properly on the new MDIO bus.

MDIO Read Error Analysis

The error ERROR: Unable to read status (-5) when accessing c000f00.mdio indicates:

The MDIO bus exists but cannot communicate with devices
Error -5 typically means EIO (Input/Output error)
This suggests either no PHYs are present at the expected addresses, or there’s a communication issue

Debugging Steps

Check if PHYs are detected at boot:

dmesg | grep -i "phy\|mdio" | grep c000f00

Scan the MDIO bus for any responding devices:

mdio c000f00.mdio scan

Verify CPSW port status:

dmesg | grep -i cpsw.*port

Potential Issues

Since your PHYs are configured at addresses 4 and 5, but the MDIO scan is failing, consider:

Hardware connectivity: Verify the MDIO signals (MDC/MDIO) are properly connected to your DP83867 PHYs
PHY power and reset: Ensure the PHYs are powered and not held in reset
PHY address configuration: Verify the hardware strapping matches your device tree addresses (4 and 5)

The fact that SERDES1 is now initializing properly suggests your lane configuration is correct, but there’s still a communication issue with the external PHYs (1).

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

alex.tx · May 19, 2026, 8:56pm

This request was closed and merged into request #65264 “AM69 USXGMII Configuration”.