AM69 Configuring SGMII Phys

Technical Support
, , , ,
12

(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:

  1. Check the complete device tree source for any existing SERDES1 SGMII configurations

  2. 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

  3. 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? :+1: :-1:

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

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