• State
  • Replies 7 replies
  • Subscribers 34 subscribers
  • Views 116 views
  • Users 0 members are here
Support feedback
Options
Options
Related

DP83TC811S-Q1: Interfacing DP83TC811S-Q1 to ZYNQMP GEM using SGMII

Gary Halfyard
Prodigy 10 points

Part Number: DP83TC811S-Q1
Other Parts Discussed in Thread: DP83TC811

Are there any examples reference designs or guides that provide a worked example of how to get the DP83TC811S-Q1 100base-T1 PHY to work with a ZYNQMP (ZU3EG) GEM over SGMII ?  I am using petalinux and have tried everything.

I believe the PHY strap configuration is correct and I can see from the LEDs that the link status is good and activity is detected on the line.  The PHY driver successfully probes and I can manually read the internal registers but I cannot get the MAC and the PHY to communicate.

I have verified all the basics, physical connections are no swapped nor polarity reversed.  The PSGTR has a 125MHz reference clock and the device tree correctly maps SGMII->PSGTR1->GEM1.

I understand that the SGMII Line rate needs to stay at 1.25Gbps and the 100Mbps line rate must use rate adaption. The GEM side seems to need to complete AN for the PCS to get enabled but that does not work unless it is advertised at 1000baseT which then does not enable rate adaption, and on it goes.

Has anybody tried this architecture and managed to get it working or is it a dead-end ?

  • 0
    TI__Mastermind 28662 points

    Hi Gary,

    DP83TC811 supports only 100Mbps SGMII, the SoC must support this speed as well. 

    Can you share the value of register 0x9? I would like to see that bit 12 and 13 equal '1'. Is SGMII auto-negotiation also enabled on the SoC side? 

    Can you also share your schematic?

    Thanks,

    David

  • 0 in reply to David Creger
    Prodigy 10 points

    Unfortunately I cannot share the schematic but it has been reviewed several times and should be correct - it was derived from the reference design/evaluation board in any case.  The hardware straps are all mode 1 (default) and the strap register reads back as 0.

    It is not clear to me whether auto-negotiation is required or not and I believe I have tried virtually every possible combination without success.  Here are some diagnostics from my system using instrumented kernel drivers for both the MAC (macb_main.c) and PHY (dp83tc811.c) that seems to be the best case scenario I Have found so far.

    The issue seems to be isolated to the SGMII interface but I cannot find any definitive information on what the expected procedure for bringing the complete link up successfully is. Hence the main question about whether this, seemingly simple architecture, has ever successfully been used before.

    root@localhost:~# dmesg | grep ff0c
    [ 20.752185] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: dp83811_probe() starting for PHY ID 0x2000a251
    [ 20.752201] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: phydev->phy_id = 0x2000a251
    [ 20.752413] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: dp83811_config_init() starting for PHY ID 0x2000a251
    [ 20.752419] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: dp83811_chip_init() starting for PHY ID 0x2000a251
    [ 20.953205] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: DP83TC11 is SLAVE
    [ 21.063802] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: SGMII_CFG[09] = 0x2000
    [ 21.065182] macb ff0c0000.ethernet eth0: Cadence GEM rev 0x50070106 at 0xff0c0000 irq 53 (7e:2e:4d:f2:30:b6)
    [ 21.078526] macb ff0c0000.ethernet end0: renamed from eth0
    [ 21.542632] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: dp83811_config_init() starting for PHY ID 0x2000a251
    [ 21.542639] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: dp83811_chip_init() starting for PHY ID 0x2000a251
    [ 21.743413] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: DP83TC11 is SLAVE
    [ 21.854029] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: SGMII_CFG[09] = 0x3000
    [ 21.854947] macb ff0c0000.ethernet end0: PHY [ff0c0000.ethernet-ffffffff:00] driver [TI DP83TC811] (irq=POLL)
    [ 21.854958] macb ff0c0000.ethernet end0: configuring for phy/sgmii link mode
    [ 21.854968] macb ff0c0000.ethernet end0: [RD0986] macb_mac_config(): interface=4 ncfgr[0004]=092e0808 ncr[0000]=00000010 pcsctrl[0200]=00001040
    [ 21.854980] macb ff0c0000.ethernet end0: [RD0986] macb_pcs_config(): forced 100M (AN disabled) PCSCNTRL[0200]=00002000
    [ 21.855668] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: dp83811_config_aneg(DISABLE) = 0
    [ 21.855960] macb ff0c0000.ethernet: gem-ptp-timer ptp clock registered.
    [ 21.858913] macb ff0c0000.ethernet end0: [RD0986] macb_link_up(): ncfgr[0004]=092e084b
    [ 21.859222] macb ff0c0000.ethernet end0: [RD0986] macb_link_up(): ncr[0000]=00100010
    [ 21.859248] macb ff0c0000.ethernet end0: Link is Up - 100Mbps/Full - flow control off
    [ 82.270275] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [DIAG] BMCR[00]=0x2100 BMSR[01]=0x0065 SGMII_CFG[09]=0x1000 SGMII_STAT[0459]=0x0000
    [ 82.270432] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [DIAG] INT_STAT1[12]=0x0000 INT_STAT2[13]=0x0000 INT_STAT3[18]=0x0000

    ifconfig end0
    end0 Link encap:Ethernet HWaddr 7E:2E:4D:F2:30:B6
    inet6 addr: fe80::7c2e:4dff:fef2:30b6/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:10016 (9.7 KiB)
    Interrupt:53

    root@localhost:~# ethtool end0
    Settings for end0:
    Supported ports: [ TP ]
    Supported link modes: 100baseT/Full
    100baseT1/Full
    Supported pause frame use: Transmit-only
    Supports auto-negotiation: No
    Supported FEC modes: Not reported
    Advertised link modes: 100baseT/Full
    100baseT1/Full
    Advertised pause frame use: Transmit-only
    Advertised auto-negotiation: No
    Advertised FEC modes: Not reported
    Speed: 100Mb/s
    Duplex: Full
    Auto-negotiation: off
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: external
    MDI-X: Unknown
    Supports Wake-on: ags
    Wake-on: gs
    SecureOn password: 00:00:00:00:00:00
    Link detected: yes

  • 0 in reply to Gary Halfyard
    TI__Mastermind 28662 points

    Hi Gary,

    I see the value of register 0x9 changing multiple times. 0x3000 would be the value which enabled SGMII and SGMII auto-negotiation. Can you please check on Zynq side that SGMII and SGMII auto-negotiation are enabled? Do you see toggling on the RX_P, RX_M, TX_P, TX_M signals when probed?

    Thanks,

    David

  • 0 in reply to David Creger
    Prodigy 10 points

    I do appreciate the suggestions but I have already been around the loop trying many many suggestions and checking various things, trawling through the online support forums for similar issues.  All without success.  The drivers are both patched so the Zynq side and the PHY side are both doing exactly as intended.

    [ 21.854980] macb ff0c0000.ethernet end0: [RD0986] macb_pcs_config(): forced 100M (AN disabled) PCSCNTRL[0200]=00002000

    [ 21.855668] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [RD0986]: dp83811_config_aneg(DISABLE) = 0

    SGMII auto-negotiation is intentionally disabled for both sides of the interface which is why the log shows register 9 in the PHY changing.

    So, what I'm actually after is the documentation that tells me exactly what the procedure should be and what I should be reading back from any status registers that confirms it is operating correct.  Currently everything seems to indicate the complete link is up when it clearly isn't and its pretty-much guesswork as to whether it is being set up and configured correctly anyway.  I have not been able to find any such information so any help you can provide will be much appreciated.

    Unfortunately, probing the board is pretty difficult and is my last resort - if there are status registers that can be read back to tell me whether the PHY detects any signal on the SGMII Input, whether it can lock to it, recover the clock, decode it or whatever, that would be preferable.

    Thanks again for your help !

  • 0 in reply to Gary Halfyard
    TI__Mastermind 28662 points

    Hi Gary,

    0x434[14] gives an indication of SGMII CDR lock. '1' is locked, '0' is unlocked. Let me know the value of this register. I would also recommend probing the SGMII signals regardless, to see the presence and amplitude of any signal. 

    Thanks,

    David

  • 0 in reply to David Creger
    Prodigy 10 points

    Thanks - I added that register to the list for debugging.  Is that a documented register as it doesn't appear in the datasheet (I downloaded it from here -> https://www.ti.com/lit/gpn/dp83tc811s-q1) ?

    Here's what it shows .. bit #14 is set.  Are the other bits of any significance ?

    [ 82.244046] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [DIAG] BMCR[00]=0x2100 BMSR[01]=0x0061 SGMII_CFG[09]=0x1000 SGMII_STAT[0459]=0x0000 SGMII_CDR[0434]=0xc350
    [ 82.244209] TI DP83TC811 ff0c0000.ethernet-ffffffff:00: [DIAG] INT_STAT1[12]=0x0000 INT_STAT2[13]=0x0000 INT_STAT3[18]=0x0800

    Unfortunately, I cannot probe the signals very easily but I am working on it.  Thanks for your help !

  • 0 in reply to Gary Halfyard
    TI__Mastermind 28662 points

    Hi Gary,

    The shared register is reserved. This may hint that there is some SGMII signal at the TX pins. It it still valuable to probe the signal to verify.  

    Is data communication successful in one direction but not the other?

    Thanks,

    David