• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 35 subscribers
  • Views 2189 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux/DP83867IS: Infinite autoneg cycle with specific Ethernet device

Thomas Karlberg
Prodigy 100 points

Part Number: DP83867IS
Other Parts Discussed in Thread: CDCLVC1104

Tool/software: Linux

We are using the DP83867IS on a new design for 1000BASE-T communication (also supporting 100/10).

This plays well with most devices we have tested, but we struggel to understand why we are entering an infinite autoneg cycle when we connect to a n 8-port Planet FSD-803 (100/10 -switch). All other devices we have tested with works well and completes autoneg as expected, wether they are GbE or 100/10-devices.

We also see that if we disable advertisement of 1000BASE-T on the DP83867IS, autoneg with the FSD-803 completes and we get stable communication. We would like to understand why, and how we can avoid potential deadlock since the design is only available via Ethernet in the intended application (we are not able to disable advertisement of 1000BASE_T if we fail to get communication up and running).

Below is some printout from our system when the PHY is stuck in the autoneg cycle with the Planet switch. We do not see any change in other PHY registers as this happens.

# mii-diag -w eth0
Basic registers of MII PHY #15:  1140 796d 2000 a231 01e1 cde1 006f 2001.
 The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
 Basic mode control register 0x1140: Auto-negotiation enabled.
 You have link beat, and everything is working OK.
 Your link partner advertised cde1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
   End of basic transceiver information.
 
Monitoring the MII transceiver status.
09:29:26.838  Baseline value of MII BMSR (basic mode status register) is 796d.
09:29:28.478  MII BMSR now 7949:   no link, NWay busy, No Jabber (0000).
09:29:30.518  MII BMSR now 796d: Good link, NWay done, No Jabber (cde1).
   New link partner capability is cde1 006f: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
09:29:31.557  MII BMSR now 7949:   no link, NWay busy, No Jabber (0000).
09:29:33.798  MII BMSR now 796d: Good link, NWay done, No Jabber (cde1).
   New link partner capability is cde1 006f: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
09:29:35.639  MII BMSR now 7949:   no link, NWay busy, No Jabber (0000).
09:29:37.881  MII BMSR now 796d: Good link, NWay done, No Jabber (cde1).
   New link partner capability is cde1 006f: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
09:29:38.920  MII BMSR now 7949:   no link, NWay busy, No Jabber (0000).

Regards,

Thomas

  • 0
    TI__Mastermind 19780 points
    Hi Thomas,

    Typically auto-neg loops happen with certain link partners due to not strapping the RX_CTRL line to mode 3 or mode 4 as required by the DS.

    In the case that you want to perform auto-neg, mode 3 strap would be the best for your situation.

    To avoid changing hardware, it is also possible to clear bit[7] of register 0x31 and restart auto-negotiation, this will result in the same stable link operation as setting RX_CTRL to mode 3 on power up. The problem of this work around is it must be implemented every time the PHY is reset or powered up.

    Please also ensure your MAC is using the extended register access method to reach PHY register 0x31. if you do not perform the 4 register write method as described in the "8.4.2.1.3 Write (No Post Increment) Operation" section of the datasheet.

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 100 points
    Hello.

    Thank you for the quick reply.
    I'm afraid we are already clearing bit[7] of register 0x31 and SW resetting the PHY because, yes, our RX_CTRL is strapped in mode 1. Before we implemented this, autoneg with this particular switch worked OK. After implementing the fix, autoneg with this device fails unless we disable 1000BASE-T advertisement.
    Of course, after implementing the fix we are observing much better stability of autoneg and communication with all other devices we have tested.

    Best Regards,
    Thomas
  • 0 in reply to Thomas Karlberg
    TI__Mastermind 19780 points
    Hi Thomas,

    This is interesting that clearing bit[7] causes the problem with this switch. Is this switch EEE enabled? Does it restart auto-negotiation if the link partner is not EEE enabled?

    Are you clearing the entire register 0x31? Bit[12] should = 1 by default and should continue to = 1 and not be overwritten when clearing bit[7].

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 100 points
    Hi Rob.

    By EEE, are you referring to Energy Efficient? No, this switch does not support that, it only lists compliance to IEEE 802.3 (Ethernet), IEEE 802.3u (Fast Ethernet), IEEE 802.3x (Full-duplex Flow Control).

    From what I can see in the workaround, the driver reads 0x31, clears bit 7 from this and writes the result back - we should only be touching bit 7:
    /* RX_DV/RX_CTRL strapped in mode 1 or mode 2 workaround */
    if (dp83867->rxctrl_strap_quirk) {
    val = phy_read_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4);
    val &= ~BIT(7);
    phy_write_mmd(phydev, DP83867_DEVADDR, DP83867_CFG4, val);
    }

    Regards
    Thomas
  • 0 in reply to Thomas Karlberg
    TI__Mastermind 19780 points
    Hi Thomas,

    Yes, I meant Energy Efficient Ethernet when I said EEE. Typically bit[7] needs to modify the DP83867 auto-negotiation only when EEE link partners are involved.

    So you probably have some other issue with link stability and this switch. Can you provide the INT status register, address 0x13 when the link toggles up and down? I want to know if there are any events being logged there.

    Also, can you check that register 0x2D is set to 0x0. This is the fast link drop register. We have seen problems where some PHYs will cause errors and the link will be dropped quickly after a few errors. While the standard IEEE state machine wont drop these links, our FLD feature intended for industrial market could impact the link up/down cycling.

    Can you also share with me the schematic of your DP83867IS implementation?

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 40 points
    Hi Rob!

    The following register read-outs have been taken from our board while connected to the troublesome link partner:

    Case #1 : Repetitive read-out of register 0x13 while link goes down/up/down....:
    ---------------------------------------------------------------------------------------------------------
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x5dc6
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0400
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0044
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1c42
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0440
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0046
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1c06
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0000
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0444
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1c42
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0444
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1042
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1c02
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0440
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1042
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1c02
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0444
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1c06
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0000
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x0444
    # phytool eth0/0xf/0x13
    ieee-phy: reg:0x13 val:0x1042
    #
    #
    #

    Case #2 : 3 read-outs of register 0x002d during the same scenario:
    ---------------------------------------------------------------------------------------
    # phytool write eth0/0xf/0x000d 0x001f
    # phytool write eth0/0xf/0x000e 0x002d
    # phytool write eth0/0xf/0x000d 0x401f
    # phytool read eth0/0xf/0x000e
    0x0400
    # phytool read eth0/0xf/0x000e
    0x0400
    # phytool read eth0/0xf/0x000e
    0x0400
    #

    Regards, Eldor
  • 0 in reply to Rob Rodrigues
    Prodigy 100 points

    Attached are the schematics showing the PHY HW implementation. The results from checking the registers during autoneg cycles will follow soon.

    Regards

    Thomas

    8831.Eth0PHY.pdf

  • 0 in reply to Thomas Karlberg
    TI__Mastermind 19780 points
    Hi Eldor and Thomas,

    From the register dump provided, and the schematic, I see you are having occasional XGMII_ERR_INT and you are providing the PHY's reference clock from a source that is not captured on the schematic.

    It is possible that the jitter on this reference clock is high, or there is a PPM offset between the reference clock to the DP83867 and this particular switch. You may also have the DP83867 resolving a link speed other than the 100M expected.

    Is it possible to look at the jitter of the 25MHZ_CLK_1 reference? We are interested in seeing <10 ps RMS from 1k to 10M, and <50 ps from 10M > 25M

    Also ensure the reference clock provided on TX_CLK is 125MHz, and the XI clock is 25MHz +/- 50ppm. Measur RX_CLK frequency from the DP83867, in 100M it should be 25MHz. If you see it increasing to 125MHz, there is an issue.

    I would also like you to check register 0x11 which will show us if the DP83867 is resolving auto-negotiation to 100base-tx mode, or if it is resolving to 1000base-t.

    Best Regards,
  • 0 in reply to Rob Rodrigues
    Prodigy 40 points

    Hi Rob!

    Some snapshots og reg 0x11 while the link is going down/up:

    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1002
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x0002
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x7c02
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x6c02
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x0002
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1300
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1302
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1000
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x7c02
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x0302
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1002
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x7f02
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1000
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x7c02
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x0300
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x7f02
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x0002
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1000
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1002
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x1000
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x7c02
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x0002
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x7c02
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x0002
    # phytool eth0/0x0f/0x11
    ieee-phy: reg:0x11 val:0x7f02

    Regards, Eldor

  • 0 in reply to Rob Rodrigues
    Prodigy 100 points
    Hello Rob,

    Unfortunately we don't have equipment available at hand that support accurate measurements of jitter, but I've tried to capture these characteristics with the oscilloscopes we have at hand. The 25MHz clock signal comes from ASDMB-25.000MHZ-LY-T, through a CDCLVC1104. This is rated to +/- 10ppm. The oscilloscopes we have do not support measurements down to 10 ps, but over a 2ms delay from triggered flank to measurement I see the signal sway less than +/-20% of a full period. It's not good enough to say much about jitter, but it indicates we have OK PPM accuracy.

    Both RX_CLK and TX_CLK are 25MHz max during this autoneg cycling with this particular switch. I don't see 125MHz unless I connect to a GbE switch, in which case I see it on both Rx and Tx CLK.

    Regards
    Thomas