LX2162A USXGMII link never completes Hey all, I have an LX2162A SoM manufactured by Solidrun. I'm using a Clearfog devkit but moving to a custom carrier soon. Solidrun provides base RCW/DCP/DPL and I've verified functionality. In my case, the DPC for dpmac3 works for the SFP cage and I get an XFI link via SFP DAC cable and various SFP modules. The RCW "rcw_2000_650_2900_3_11_0_auto" sets to SerDes1=3, SerDes2=11 and I'm using a QorIQ kernel (lf-6.6.52-2.2.0) and mc-utils (10.39.0) but with some Solidrun patched applied to both. Uboot and other things are also patched. All patches come from here: https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 I have a MaxLinear GPY245-EKV-1 (and -2) devkit(s) that wants USXGMII over DAC cable to connect the phy to the device. Apparently this is pretty normal. Eventually this phy chip will be integrated into SerDes2=7 Lane6 and Lane7 but I have to use the SFP cage on the Clearfog for testing. Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP I'm only trying to configure dpmac3 to use this USXGMII link via DPC: mac@3 {
link_type = "MAC_LINK_TYPE_PHY";
enet_if = "USXGMII";
}; (I've also tried MAC_LINK_TYPE_BACKPLANE) Confirmed via "restool dpmac info dpmac.3" shows "DPMAC ethernet interface: DPMAC_ETH_IF_USXGMII". In Linux, I added the MaxLinear driver and patched a few things: gpy_update_interface() fix (LKML, Daniel Golle). This was returning -EINVAL for USXGMII interface, crashing phy_state_machine. Patched lynx_pcs_config_usxgmii() in pcs-lynx.c to also write MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) via mdiobus_c45_modify(), since the function only ever wrote MII_ADVERTISE and never enabled AN on the Replicator block itself. This gap matches another post on this forum ("LS1028A 10g-qxgmii phy bring-up") which found the identical symptom (MMD31.0/Replicator control register stuck at 0) and got AN to kick in after manually setting bit 12. This is the DPMAC3 Linux devicetree entry: &dpmac3 {
managed = "in-band-status";
phy-mode = "usxgmii";
phy-handle = <&gpy245_p0>;
phys = <&serdes_1 7>;
status = "okay";
}; where `gpy245_0` is the MDIO node. MDIO traffic to the phy is working. I added a printout in the lynx_pcs driver which shows the readback: mdio_bus 0x0000000008c0f000:00: USXGMII:
wrote ADV=0xd601 BMCR=0x1a00
readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 Question: Given writes to MDIO_MMD_VEND2 registers on this PCS instance don't appear to persist, is there a known additional step (SerDes/PCS block enable, protocol-specific initialization, or similar) required before the USXGMII on the LX2162A family SoCs will accept configuration? Is protocol 3 fully validated for USXGMII on dpmac3, or primarily intended/tested for XFI? Other questions: Maybe I don't understand GPY245 and USXGMII. I see some folks refer to this as QXGMII and I can't tell if the LX2162A is even capable of that working. Maybe I need to reach out to Solidrun, but all of their patches do not seem to limit the LX2162A's capability. Thanks! Re: LX2162A USXGMII link never completes @yipingwang I really appreciate the detailed response! Everything you said makes sense and I've started learning more about the platform. I've started using the advice in AN13329.pdf. Some of the addresses and things aren't working (probably a version mismatch) but at least I can get the MC log as shown below: => md 0x8340020 10
08340020: e0000006 00000021 00060000 00000000 ....!...........
08340030: 00000000 00000000 00000000 00000000 ................
08340040: 00000000 00000000 00000000 00000000 ................
08340050: 00000000 00000000 00000000 00000000 ................
=> md 0x21e1000000
21e1000000: 4d430100 00000000 01400000 00300000
[email protected].
21e1000010: 00000073 00000000 00000000 00000000 s...............
21e1000020: 00000000 00000000 00000000 00000000 ................
21e1000030: 00000000 00000000 00000000 00000000 ................
=> md 0x21e1400000 50
21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U
21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed
21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data
21e1400030: 6c697720 6562206c 69727020 6465746e will be printed
21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn
21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait
21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events .
21e1400070: 000a2e2e 00000000 00000000 00000000 ................
21e1400080: 00000000 00000000 00000000 00000000 ................
21e1400090: 00000000 00000000 00000000 00000000 ................
21e14000a0: 00000000 00000000 00000000 00000000 ................
21e14000b0: 00000000 00000000 00000000 00000000 ................
21e14000c0: 00000000 00000000 00000000 00000000 ................
21e14000d0: 00000000 00000000 00000000 00000000 ................
21e14000e0: 00000000 00000000 00000000 00000000 ................
21e14000f0: 00000000 00000000 00000000 00000000 ................
21e1400100: 00000000 00000000 00000000 00000000 ................
21e1400110: 00000000 00000000 00000000 00000000 ................
21e1400120: 00000000 00000000 00000000 00000000 ................
21e1400130: 00000000 00000000 00000000 00000000 ................ I've attempted to poke at the PCCC via uboot. Here are the relevant things: crc32+ MC firmware version 10.39.0
fsl-mc: Booting Management Complex ... SUCCESS
fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1)
Autoboot in 3 seconds
=> mmc read 0x80d00000 0x6800 0x800
=> fsl_mc apply dpl 0x80d00000
fsl-mc: Deploying data path layout ... SUCCESS
=> md.l 0x1ea10b0 1
01ea10b0: 88889991 .... I really hope 0x1ea10b0 is the right address. According the LX2162ARM.pdf, that *could* be the right address and decoding the bits shows: A (lane 0) bit 31 1 = XFI/SFI
B (lane 1) bit 27 1 = XFI/SFI
C (lane 2) bit 23 1 = XFI/SFI
D (lane 3) bit 19 1 = XFI/SFI Is the right right register address (PCCC) to observe? Is there any other information I can provide? Thanks! Re: LX2162A USXGMII link never completes The LX2162A side is documented to support USXGMII on the paths you are using , but the symptom you show looks less like a missing Linux pcs-lynx write and more like the selected PCS instance is still not actually in USXGMII application mode, or MC firmware is programming the wrong 10G PCS selector.
For SerDes1 protocol 3 , the LX2162A reference manual lists all four SerDes1 lanes as USXGMII / XFI , including USXGMII / XFI.3 for the first lane, which corresponds to the DPMAC3 use case you are testing on the Clearfog SFP path . For your future custom-carrier target, SerDes2 protocol 7 also documents lane 6 and lane 7 as USXGMII / XFI.13 and USXGMII / XFI.14 .
The important catch is that the USXGMII / XFI entry is not automatically “USXGMII.” The reference manual says that between USXGMII and XFI on a lane, the default is XFI . The mode is selected through PCCC , the Protocol Configuration Register C, and its SXGMII*_XFI bits select 0b = USXGMII and 1b = XFI/SFI . So the first thing I would check is not the Linux BMCR write itself, but whether the specific SXGMII instance for DPMAC3 has its PCCC XFI-select bit cleared after MC/DPC initialization.
There is also precedent for this exact class of failure being in MC firmware , not in the Linux PCS driver: one LX2162A ticket shows MC clearing the wrong 10G interface selector in PCCC for a USXGMII configuration, and an MC firmware engineering build, version 10.35.101 , resolved the issue . Another ticket notes that MC settings are done by MC firmware, with NXP providing MC as a binary . Since you are on MC 10.39.0 , you should be beyond that specific old fix, but the failure mode you see is still consistent with “MC did not put the intended PCS into USXGMII mode” or “the wrong PCS instance is being addressed.”
What I would do next:
Read PCCC before Linux changes anything. After RCW + MC + DPL/DPC load, but before the Linux PCS driver runs, read PCCC and confirm the relevant SXGMII*_XFI bit is 0 . For DPMAC3 / USXGMII/XFI.3 , expect the first SXGMII selector, not the selector for MAC13/14. If that bit remains 1 , the lane is still XFI/SFI and your VEND2/USXGMII PCS writes are not being applied to a live USXGMII PCS path.
Check that the MDIO access is hitting the intended PCS management port. The SXGMII protocol-control register has an MDEV_PORT field used to match MDIO accesses, and the manual says software must wait at least 3 platform clocks after changing it before MDIO accesses to the SGMII/PCS target . If the MDIO address decode is wrong, writes can appear to “not persist” because you are reading a different or reset/default PCS window.
Confirm the USXGMII AN registers are meaningful only after the mode select is correct. The USXGMII PCS CONTROL register has AUTO_NEGOTIATION_ENABLE at bit 12, and DEV_ABILITY / PARTNER_ABILITY are RW registers . The DEV_ABILITY lower vendor arbitrary speed field must be non-zero, because zero can cause auto-negotiation failure . But if PCCC still selects XFI, these BMCR/ability writes are not the real root problem.
Do not treat QXGMII as a separate required external protocol unless the GPY245 board documentation explicitly says so. LX2162A documentation does contain QXGMII protocol-converter registers, including reset/powerdown control bits such as PD_QXGM and RST_QXGM . NXP community material for LS1028A also refers to a 10G_QXGMII Lynx SerDes driver path . But the documented LX2162A DPMAC interface you are selecting is still USXGMII / XFI , and NXP documentation separately states that LX2160-class devices support USXGMII and that “SXGMII” is not the same thing . In other words: “QXGMII” references in driver/community discussions may describe an internal converter/driver naming path, not necessarily a different MAC-to-PHY contract than the USXGMII mode you configured.
For this Clearfog SFP test, keep the DPC simple. MAC_LINK_TYPE_PHY with enet_if = "USXGMII" is the more natural model for a managed external PHY over MDIO. I would not expect MAC_LINK_TYPE_BACKPLANE to fix a PHY-facing USXGMII setup unless you are intentionally using a backplane/KR-style flow.
I would not conclude that protocol 3 is “primarily XFI-only.” The reference manual documents protocol 3 as USXGMII / XFI for DPMAC3’s SerDes1 lane . What I cannot verify from the retrieved material is a separate validation statement saying “protocol 3 + DPMAC3 + USXGMII was validated with GPY245.” The stronger, evidence-backed statement is: the hardware mode exists, defaults to XFI unless PCCC selects USXGMII, and there is known MC-firmware precedent for programming the wrong 10G PCS selector .
For your specific readback:
wrote ADV=0xd601 BMCR=0x1a00
readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000
that is exactly the kind of result I would expect if the PCS instance is not fully enabled/selected for USXGMII, or the MDIO management window is not addressing the intended PCS instance. I would verify PCCC and the MC log first, before adding more Linux-side writes.
LX2162A protocol 3 is documented for USXGMII / XFI on DPMAC3, but USXGMII depends on MC/PCCC selecting the USXGMII PCS; if VEND2/BMCR writes do not persist, first prove the correct PCCC bit is cleared for DPMAC3 and that MDIO is addressing the correct SXGMII PCS instance. Re: LX2162A USXGMII link never completes
Yes. For SerDes1 , 0x1ea10b0 is the right address for PCCC :
LX2162A CCSR map lists SerDes 1 at 0x1EA_0000–0x1EA_FFFF .
The SerDes memory map lists Protocol Configuration Register C / PCCC at offset 0x10B0 .
Therefore: 0x1EA0000+0x10B0=0x1EA10B00x1EA0000+0x10B0=0x1EA10B0
So your U-Boot read:
Copy
=> md.l 0x1ea10b0 1
01ea10b0: 88889991
is observing the expected SerDes1 PCCC register.
The important caveat is the naming: I would not describe those fields as physical SerDes lane A/B/C/D for your current setup. In the LX2162A SerDes1 protocol table, protocol 3 maps physical lane H / lane 0 to USXGMII / XFI.3 , then lane G/lane 1 to .4 , lane F/lane 2 to .5 , and lane E/lane 3 to .6 . PCCC field names such as SXGMIIA_XFI , SXGMIIB_XFI , etc. are PCS/protocol-control fields, not necessarily the same naming convention as the physical lane letters.
For your value 0x88889991 , the high nibbles decode like this:
Copy
PCCC = 0x88889991
bits 31:28 = 0x8 -> SXGMIIA_XFI = 1, CFG = 000
bits 27:24 = 0x8 -> SXGMIIB_XFI = 1, CFG = 000
bits 23:20 = 0x8 -> SXGMIIC_XFI = 1, CFG = 000
bits 19:16 = 0x8 -> SXGMIID_XFI = 1, CFG = 000
bits 15:12 = 0x9 -> SXGMIIE_XFI = 1, CFG = 001
bits 11:8 = 0x9 -> SXGMIIF_XFI = 1, CFG = 001
The key bit is the _XFI bit. The RM defines 0 as USXGMII mode and 1 as XFI/SFI mode for these fields . So the value you read strongly suggests the relevant USXFI/SXGMII PCS instances are still being selected as XFI/SFI , not USXGMII.
That lines up with your symptom: Linux/restool may report DPMAC_ETH_IF_USXGMII , but if PCCC still has the relevant _XFI select bit at 1 , the underlying SerDes/PCS selection is still effectively in XFI/SFI mode. The RM also explicitly says that to enable 10G-SXGMII, software must set PCCC[SGMIIa_XFI] = 0 .
Your MC log extraction also looks sane. AN13329 says to read MCFBAL/MCFBAH at 0x8340020 , build the MC firmware base, then dump the log-buffer structure at offset 0x01000000 ; the structure contains the magic, log-buffer offset, and log-buffer length . Your 0x21e1000000 dump shows the expected 0x4d430100 magic and points to log offset 0x01400000 , which matches your later dump at 0x21e1400000 .
What I would capture next:
PCCC snapshots at each stage
Copy
md.l 0x1ea10b0 1
Capture it:
immediately after reset / before MC boot if possible,
after MC boot,
after DPC/DPL apply,
after Linux boots,
after the DPMAC is probed/configured.
Adjacent protocol config registers
Copy
md.l 0x1ea10a0 1 # PCC8
md.l 0x1ea10a4 1 # PCC9
md.l 0x1ea10b0 1 # PCCC
PCC8/PCC9 contain other SGMII configuration fields, while PCCC is the SXGMII/XFI selector register .
Confirm which PCCC field changes when you try forcing USXGMII If you can safely poke in U-Boot for experiment only, try clearing the candidate _XFI bit and reading it back immediately. For example, if dpmac3 corresponds to the first SXGMII/USXFI control field, clearing bit 31 would be the experimental check:
Copy
mw.l 0x1ea10b0 0x08889991 1
md.l 0x1ea10b0 1
If it immediately reads back as 0x88889991 , then either the write is blocked/overridden, or that field is not writable in the current block state. If it sticks until MC or Linux runs, then MC/Linux is likely restoring XFI/SFI mode.
Full RCW SerDes decode You already have SerDes1=3, SerDes2=11 ; that matches the dpmac3 lane being available as USXGMII / XFI.3 under SerDes1 protocol 3 . Still, include the full RCW string and raw RCW dump when escalating, because MC firmware often keys off the complete protocol set.
MC firmware + DPC/DPL artifacts Since your MC is 10.39.0 , include:
MC firmware version,
DPC source,
DPL source,
exact dpmac@3 block,
restool dpmac info dpmac.3 ,
the PCCC value after each step.
My current read of your data: yes, 0x1ea10b0 is the correct SerDes1 PCCC address, and 0x88889991 looks like the relevant PCS selectors are still in XFI/SFI mode. That is consistent with XFI working through the SFP cage and USXGMII not accepting/retaining the expected PCS configuration.
