This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83869HM: SGMII SERDES SYNC fails sometimes

Part Number: DP83869HM

We use three DP83869HM (SGMII to copper) on a Intel Elkhart Lake CPU.


The PHY connected to the PCH always works but the other two connected to the PSE seem to have problems at establishing the SGMII link sometimes.
Bit 8 in the SERDES_SYNC_STS Register (Offset = 4Fh) is 0.

What is the correct procedure to restart the sync?
What do the other RESERVED bits in this register mean?

Schematic for all three PHYs is the same (and checked by TI). The Ethernet link between PHY and Ethernet Switch is also established on all three ports.

  • Hello,

    While Reg 0x4F may be a helpful clue, can you also please check Reg 0x37? Please note these registers are extended registers and thus need extended access as detailed in datasheet.

    You may also start the SGMII block using Reg 0x14[12]. 

    While the schematic may be the same, the layout and/or MAC may be sources where the communication can go awry, especially as the PCH (can you please provide definition of this?) connection is working.

    Can you please check Reg 0x6E between all 3 designs to ensure that the PHY has been strapped properly?

    This app note may have more troubleshooting tips which may be helpful. Please check this out and if the issue is not resolved by the steps in this document, we can proceed further.

    Sincerely,

    Gerome

  • Hello Gerome

    The Intel CPU consists of a PCH (Platform Controller Hub) which is more or less the Chipset of the CPU with one ethernet MAC and a PSE (Programmable Services Engine) which is an other subsystem in the CPU that contains two more ethernet MACs.

    This are the registers of the three PHYs when they are working

    dwmacEndStart-0: MDIO # 0 SGMII_AUTO_NEG_STATUS       0x0000
    dwmacEndStart-0: MDIO # 0 SERDES Sync Status          0x0146
    dwmacEndStart-0: MDIO # 0 STRAP_STS Register          0x0c00

     

    dwmacEndStart-1: MDIO # 0 SGMII_AUTO_NEG_STATUS       0x0000
    dwmacEndStart-1: MDIO # 0 SERDES Sync Status          0x0156
    dwmacEndStart-1: MDIO # 0 STRAP_STS Register          0x0c00

     

    dwmacEndStart-2: MDIO # 0 SGMII_AUTO_NEG_STATUS       0x0003
    dwmacEndStart-2: MDIO # 0 SERDES Sync Status          0x0146
    dwmacEndStart-2: MDIO # 0 STRAP_STS Register          0x0c00

    -------------------------------------------------------------------------------

    This are the registers when they are not working

    dwmacEndStart-0: MDIO # 0 SGMII_AUTO_NEG_STATUS       0x0000 
    dwmacEndStart-0: MDIO # 0 SERDES Sync Status          0x0290 -> not-synced, what does 90 mean?
    dwmacEndStart-0: MDIO # 0 STRAP_STS Register          0x0c00

     

    dwmacEndStart-1: MDIO # 0 SGMII_AUTO_NEG_STATUS       0x0000
    dwmacEndStart-1: MDIO # 0 SERDES Sync Status          0x0250
    dwmacEndStart-1: MDIO # 0 STRAP_STS Register          0x0c00

     

    dwmacEndStart-2: MDIO # 0 SGMII_AUTO_NEG_STATUS       0x0003 
    dwmacEndStart-2: MDIO # 0 SERDES Sync Status          0x0186 -> not-synced, what does 86 mean?
    dwmacEndStart-2: MDIO # 0 STRAP_STS Register          0x0c00 

    --------------------------------------------------------------------------------

    Is there an extended datasheet? I have seen other support issues were they discuss about register (0xd6) that are not described in the datasheet on the homepage.

    The hardware works every time with BIOS / Win10, the problems are on our target system with Coreboot / VxWorks. We assume that some registers are not set correctly by Coreboot or in the wrong order and thus the SGMII link can not be established.   

    I also made ethernet compliance tests with the MSP430 LaunchPad, all three port as OK at 10/100/1000MBit/s.   

    Regards

    Martin

  • Hi Martin,

    I would want to focus less on Reg 0x4F and more on Reg 0x37. As you can see, even when non-synced, the SGMII is still connected on MAC2. Meanwhile, MACs 1 and 2 never get SGMII linkup (0x3). 

    You are claiming that in BIOS this design works correct, while on VxWorks that is where issues are being had. If the hardware is the exact same with a SW difference, this is telling that something SW is gating the functionality. Can you please check the differences in strapping between the two SW? I would also recommend checking the signaling on the SGMII lines to see if there is something going awry there. A diff probe would be helpful in this case.

    Sincerely,

    Gerome