cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pillinj1
Contributor
Contributor
4,654 Views
Registered: ‎02-11-2014

ZynqMP Ethernet PS SGMII with Ti83867 Phy issues

Hi,

 

I'm having issues with the Ethernet on a custom board with a ZynqMP and the Ti83867 PHY running in SGMII mode. MDIO interface is wired. Some details

  •  I'm using GEM0 on GT Lane0 using a 125MHz reference clock on Lane2.
    • I've confirmed the 125MHz is being generated on the board to the correct pins and reconfirmed that the ZynqMP is configed for this (both I/O config and Ref Clk config)
  • I've added this devicetree fragment according to AR66592 (https://www.xilinx.com/support/answers/66592.html):
    • &gem0 {
      status = "okay";
      phy-handle = <&phy0>;
      phy-mode = "sgmii";
      phy0: phy@0{
      reg = <0>;
      ti,rx-internal-delay = <0x8>;
      ti,tx-internal-delay = <0xa>;
      ti,fifo-depth = <0x1>;
      };
      };
  • During Linux boot, I get "TI DP83867 ff0b0000.etherne:00: attached PHY driver [TI DP83867] (mii_bus:phy_addr=ff0b0000.etherne:00, irq=-1)"
  • If I connect my PC to the board with an Ethernet cable, the PC gets a 1000MB/s link. The PC fails to ping the Zynq, however the activity LED (and wireshark) show the ping requests being made.
  • When the Zynq tries to ping the PC, the activity LED does nothing
  • the PCS_STATUS register for the GEM shows no link.

I'm looking for any help debugging this issue.

 

One possible thing I'm looking at is related to this guide (http://www.wiki.xilinx.com/Zynq+Ultrascale+MPSOC+Linux+SIOU+driver) which talks about configuring the PS GTR clocks for Linux. AR66592 does not mention anything about the need for this. That said, I tried adding "phys = <&lane0 PHY_TYPE_SGMII 0 2 125000000>;" under the gem0 devicetree entry, but it didn't do anything.

 

Thanks!

0 Kudos
19 Replies
rgb-stiltd
Visitor
Visitor
4,388 Views
Registered: ‎06-21-2017

Hi,

 

This was a little while ago. Were you able to resolve this, as it looks like I'm in a similar situation?

 

Thanks,

 

Richard.

0 Kudos
4,195 Views
Registered: ‎08-09-2018

We are planning to use the same TI PHY device with a ZYNQ MPSOC.  Was this resolved?

0 Kudos
ottob
Explorer
Explorer
4,186 Views
Registered: ‎05-26-2017

We use that PHY both in RGMII (connected to PL) and SGMII (Connected to PS) in our design. Works well

0 Kudos
4,171 Views
Registered: ‎08-09-2018

Thank you for the reply.  What did you use to source the MGTREFCLK for the SGMII?  

 

The SGMII Differential clock from the PHY is fixed at 625MHz which is too fast for the PS_GTR.  We are planning on using the PHY's Clock Out which can be configured to be a fixed single ended 125MHz clock and pass this through a buffer to provide a 125MHz differential signal to the PS_GTR. 

 

Best Regards,

Steve

0 Kudos
ottob
Explorer
Explorer
4,147 Views
Registered: ‎05-26-2017

We used a 5P49V5907 clock generator chip, mostly because we need other frequencies 

 

You'll get more clock jitter grabbing it from the PHY's "CLK_OUT", but it could be OK... Check the datasheets. Or even better a Xilinx FAE :)

 

/Otto

0 Kudos
4,136 Views
Registered: ‎08-09-2018

Thank you for the reply Otto.  This is good information. 

 

Here's some background information. 

The TI FAE stated the clock needed to be sync'd with the data and recommended the use of the single-ended Clock Out from the PHY device and gave information on how this clock could be fixed to 125 MHz. 

 

The Xilinx documentation infers the 125MHz clock can be sourced from the GTR reference clock or one of the PS PLLs.  

From UG1085 (V1.7 Nov 1, 2017) pg 789 for PS-DTR Transceiver Features

"Clocking : 

Internal PLL per Lane

Different reference clock inputs per lane "

 

Xilinx Field FAE stated we could use a 125MHz clock from a PS PLL

Xilinx Factory FAE stated the clock could only be sourced by the external Differential clock pins.

 

Sometimes its better to get info from someone who has actually done something that actually works.

I can't say how much I appreciate your input. 

Thanks again Otto.

 

Regards,

Steve

 

0 Kudos
ottob
Explorer
Explorer
4,129 Views
Registered: ‎05-26-2017

Hi Steve !

 

Lots of variety in the advice there hehe.. Interesting that the TI FAE claimed the clock and data needs to be sync'd.. Are you planning to use PTP or synchronous Ethernet ? We don't have CLK_OUT from the phy connected to anything. 

 

Its worth noting that we only run the PHY in 100Mbit, however the way SGMII works it still runs at 1.25GHz but it replicates every frame ten times. (We didnt have room for the big Gigabit magnetics on our board)

 

125MHz is pretty slow nowadays, so I bet you'll be fine using the PHY's clock, or a PS PLL generated clock

 

/Otto

0 Kudos
4,116 Views
Registered: ‎08-09-2018

Hi Otto,

 

No synchronous Ethernet.  We are designing to IEEE 802.3ab (10/100/1000 T-Base).  We will support operating at a Gig if the terminal at the other end of the link and the line signal integrity supports running at a Gig too.  Otherwise the line rate will negotiate down in compliance with the spec.

 

Right now we are using the PHY's single ended clock out configured to 125 MHz and passing this through a differential driver to supply the PS_GTR Ref Clock.  I'll post an update once we get prototypes to test.

 

Regards,

Steve

0 Kudos
itays
Visitor
Visitor
2,865 Views
Registered: ‎07-04-2019

Hi,
Did you managed to make it work?
We are using the same configuration
(SGMII with 83867E and phy is generating the 125Mhz clock and pass it thru differential driver)
but it's not working.

Any advice and suggestions will be greatly appreciated.

Thanks
0 Kudos
pdo
Visitor
Visitor
2,312 Views
Registered: ‎09-27-2019

Hi all,

We too are having difficulties interfacing a TI83867 PHY to the Zynq's PS-GTR transceivers using SGMII.  If anyone has a success story to report I'd love to hear the details.

Thanks

 

0 Kudos
shabbirk
Moderator
Moderator
2,305 Views
Registered: ‎12-04-2016

Hi 

How is your device tree look like?

Example DT here, for GEM2 (system-user.dtsi):

&gem2 {
status="okay";
phy-mode="sgmii";
};

Final system.dts file should contain the below device node under GEM-2 (ethernet@ff0d0000 ), assuming phy addr being 0 here for example:

phy@0 {
reg = <0x0>;
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0xa>;
ti,fifo-depth = <0x1>;
ti,rxctrl-strap-worka;
linux,phandle = <0x14>;
phandle = <0x14>;
};

Basic registers to debug are attached in this AR (SGMIIInit_fix.tcl)

https://www.xilinx.com/support/answers/66592.html

0 Kudos
pdo
Visitor
Visitor
2,293 Views
Registered: ‎09-27-2019

Hi shabbirk,

We're using GEM3 and my device tree entry in system-user.dts is currently:-

&gem3 {
    phy-mode = "sgmii";
    phy-handle = <&phy0>;
    status = "okay";

    phy0: phy@0 {
        reg = <0x0>;
        device_type = "ethernet-phy";
        ti,rx-internal-delay = <0x8>;
        ti,tx-internal-delay = <0xa>;
        ti,fifo-depth = <0x1>;
        ti,dp83867-rxctrl-strap-quirk;
    };
};

so I see one of my 'ti' properties is named differently -- will look more closely into that.  I'm also wondering where the numbers you have in your phandle properties come from?

Also, I have a big question as to the nature of the REFCLK signal that should be supplied to the PS-GTR block implementing the SGMII interface: does the REFCLK need to be synchronous (fixed phase relationship) with the RX serial data coming from the PHY chip?

Thanks

0 Kudos
pdo
Visitor
Visitor
2,226 Views
Registered: ‎09-27-2019

An update: I now have it working in U-Boot by adding a 'is-internal-pcspma' property to the device tree, which is now:-

&gem3 {
    phy-mode = "sgmii";
    is-internal-pcspma;
    phy-handle = <&phy0>;
    status = "okay";

    phy0: phy@0 {
        reg = <0x0>;
        device_type = "ethernet-phy";
        ti,rx-internal-delay = <0x8>;
        ti,tx-internal-delay = <0xa>;
        ti,fifo-depth = <0x1>;
        ti,dp83867-rxctrl-strap-quirk;
    };
};

So I can acquire an IP address using BOOTP and ping other entities on the network from within U-Boot.  However, I see no signs of life when the kernel is loaded and Linux running.

A side-effect of this is that I have answered my question about the PS-GTR's REFCLK: it does NOT need to be phase-related to the RX serial data coming from the PHY (I have it sourced from a bench signal generator at the moment).

Any ideas on my kernel problem would be greatly appreciated.  I'm running Vivado/Petalinux 2018.3.

0 Kudos
shabbirk
Moderator
Moderator
2,208 Views
Registered: ‎12-04-2016

Hi @pdo 

Can you allso try adding the TI phy quirks in GEM node of the device tree and see if that helps in detecting the PHY and link gets established in linux?

Updated DT should look like this:

&gem3 {
    phy-mode = "sgmii";
    is-internal-pcspma;
    phy-handle = <&phy0>;
    status = "okay";
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0xa>;
ti,fifo-depth = <0x1>;
ti,dp83867-rxctrl-strap-quirk; phy0: phy@0 { reg = <0x0>; device_type = "ethernet-phy"; ti,rx-internal-delay = <0x8>; ti,tx-internal-delay = <0xa>; ti,fifo-depth = <0x1>; ti,dp83867-rxctrl-strap-quirk; }; };

 

0 Kudos
pdo
Visitor
Visitor
2,192 Views
Registered: ‎09-27-2019


@shabbirk wrote:

Hi @pdo 

Can you allso try adding the TI phy quirks in GEM node of the device tree and see if that helps in detecting the PHY and link gets established in linux?

Updated DT should look like this:

&gem3 {
    phy-mode = "sgmii";
    is-internal-pcspma;
    phy-handle = <&phy0>;
    status = "okay";
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0xa>;
ti,fifo-depth = <0x1>;
ti,dp83867-rxctrl-strap-quirk; phy0: phy@0 { reg = <0x0>; device_type = "ethernet-phy"; ti,rx-internal-delay = <0x8>; ti,tx-internal-delay = <0xa>; ti,fifo-depth = <0x1>; ti,dp83867-rxctrl-strap-quirk; }; };

 


No, that didn't change anything.  If I read back the pcs_status register (address 0xFF0E0204), I see it changing between 0x00000129 and 0x0000012D, showing that the link_status bit is going up and down.  In U-Boot this is a solid 0x0000012D.

 

0 Kudos
arjaanda
Visitor
Visitor
1,492 Views
Registered: ‎02-20-2020

I am also stuck with the same issue now. The pings in the Uboot work but I do not see eth0 interface coming up. Kernel boot message shows "Configuring network interfaces... Cannot find device "eth0"". Please let me know if a solution was found

0 Kudos
jacobdubie
Visitor
Visitor
1,278 Views
Registered: ‎06-03-2020

Hey All,

I'm also stuck on this same issue as well. I'm first starting with U-boot to try and get this up. I'm using a Zynq Ultrascale+ on a custom board with a Ti83867 trying to use SGMII to connect to the PHY. I've done all of the things in this post and other posts, but no luck yet. I'm using an external differential clock for the PS-GTR. I have access to the 83867 registers via MDIO. I've performed several loopback tests:

Loopback internal to the PHY does not work, whereas loopback internal to the PCS on the zynq does work, so it seems like there is something wrong with the SGMII link. I have Ethernet working with RGMII with a different board with a zynq. Using mdio I can see that the link is up and many other things here is the output from the first two registers:

=> mii dump 1 0
0. (1140) -- PHY control register --
(8000:0000) 0.15 = 0 reset
(4000:0000) 0.14 = 0 loopback
(2040:0040) 0. 6,13 = b10 speed selection = 1000 Mbps
(1000:1000) 0.12 = 1 A/N enable
(0800:0000) 0.11 = 0 power-down
(0400:0000) 0.10 = 0 isolate
(0200:0000) 0. 9 = 0 restart A/N
(0100:0100) 0. 8 = 1 duplex = full
(0080:0000) 0. 7 = 0 collision test enable
(003f:0000) 0. 5- 0 = 0 (reserved)


=> mii dump 1 1
1. (796d) -- PHY status register --
(8000:0000) 1.15 = 0 100BASE-T4 able
(4000:4000) 1.14 = 1 100BASE-X full duplex able
(2000:2000) 1.13 = 1 100BASE-X half duplex able
(1000:1000) 1.12 = 1 10 Mbps full duplex able
(0800:0800) 1.11 = 1 10 Mbps half duplex able
(0400:0000) 1.10 = 0 100BASE-T2 full duplex able
(0200:0000) 1. 9 = 0 100BASE-T2 half duplex able
(0100:0100) 1. 8 = 1 extended status
(0080:0000) 1. 7 = 0 (reserved)
(0040:0040) 1. 6 = 1 MF preamble suppression
(0020:0020) 1. 5 = 1 A/N complete
(0010:0000) 1. 4 = 0 remote fault
(0008:0008) 1. 3 = 1 A/N able
(0004:0004) 1. 2 = 1 link status
(0002:0000) 1. 1 = 0 jabber detect
(0001:0001) 1. 0 = 1 extended capabilities


=>

I've made sure of several basic things like 1 V is across RBIAS on the Ti83867. 

My dts in u-boot is as follows:

&gem0 {
status = "okay";
compatible = "cdns,zynqmp-gem", "cdns,gem";
phy-handle = <&phy0>;
phy-mode = "sgmii";
is-internal-pcspma;
phy0: phy@1 {
reg = <0x1>;
device_type = "ethernet-phy";
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0xa>;
ti,fifo-depth = <0x1>;
ti,dp83867-rxctrl-strap-quirk;
};
};

I have zynq_gem.c and dp83867.c relatively up to date, but there may be some of the latest commits I'm missing. For those of you who got it working were there some recent commits that helped fix the issue?

I also tried wiresharking and didn't see any pings or broadcast commands sent out of the phy. Any suggestions would be very helpful!

Thanks!

0 Kudos
vdumas
Observer
Observer
1,014 Views
Registered: ‎02-17-2020

Having the same problem we wonder if you have resolved this issue? What we do not understand is in the PCW when you select which GTLane to use for the GEM you get to choose the ref clk but in the output clocks tab the IOPLL is selected for the corresponding GEM and we cannot select the GTREFCLK.

Did you add the dp83867 to uboot because we cannot dump registers through mii in uboot although we can dump them through the phy_management register(GEM register +0x34)?

0 Kudos
atran17
Contributor
Contributor
391 Views
Registered: ‎01-25-2019

I have the same problem, and I got u-boot network work with this device tree system-user.dtsi :

But Linux kernel network is still not work. It cannot ping others. Only can ping itself.

/include/ "system-conf.dtsi"
/ {
};

&gem0 {
status = "okay";
compatible = "cdns,zynqmp-gem", "cdns,gem";
phy-handle = <&phy0>;
xlnx,has-mdio = <0x1>;
phy-mode = "sgmii";
ti,rx-internal-delay = <0x8>;
ti,tx-internal-delay = <0x0>;
ti,fifo-depth = <0x1>;
ti,dp83867-rxctrl-strap-quirk = <1>;

phy0: phy@0 {
       device_type = "ethernet-phy";
       compatible = "ti,dp83867", "ethernet-phy-ieee802.3-c22";
       reg = <0x0>;
      };
};
0 Kudos