cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
randomengineer
Visitor
Visitor
4,329 Views
Registered: ‎10-17-2017

GEM Timestamping Zynq UltraScale+ MPSoC

Jump to solution

So I've been running in circles trying to get PTP (IEEE 1588) working with the XCZU3EG-1 that i have... I have enabled the GEM time-stamping clock as shown in the image below, and enabled it to function through the EMIO interface...

 

GEM TSU Clock

 

I connected the exposed clock (emio_enet_tsu_clk) to a 50 Mhz clock named pl_clk1 which gets created by the zynq_ultra_ps_e0 block

 

Clocks

And my device tree: Which has a tsu-clk entry indicating the clock rate

		ethernet@ff0e0000 {
			compatible = "cdns,zynqmp-gem";
			status = "okay";
			interrupt-parent = <0x4>;
			interrupts = <0x0 0x3f 0x4 0x0 0x3f 0x4>;
			reg = <0x0 0xff0e0000 0x0 0x1000>;
			clock-names = "pclk", "hclk", "tx_clk", "rx_clk";
			#address-cells = <0x1>;
			#size-cells = <0x0>;
			#stream-id-cells = <0x1>;
			iommus = <0x7 0x877>;
			power-domains = <0xf>;
			tsu-clk = <0x2faf080>;
			clocks = <0x3 0x1f 0x3 0x34 0x3 0x30 0x3 0x34>;
			local-mac-address = [00 0a 35 00 02 90];
			phy-mode = "rgmii-id";
			phy-handle = <0x10>;
			pinctrl-names = "default";
			pinctrl-0 = <0x11>;
		};

So my question is: What am I missing? Did I get the DeviceTree entry correct (tsu-clk)?  Are the two other connections relevant, and in what way? I can't seem to find any information on what to do with them( fmio_gem_tsu_clk_from_pl and fmio_gem_tsu_clk_to_pl_bufg) .... Any help is greatly appreciated

0 Kudos
1 Solution

Accepted Solutions
randomengineer
Visitor
Visitor
5,636 Views
Registered: ‎10-17-2017

Hi @nanz,

 

I think we have it figured out... We made changes to the driver to enable the clock through the CCF driver as per the documentation

https://elinux.org/images/b/b8/Elc2013_Clement.pdf

 

View solution in original post

0 Kudos
9 Replies
randomengineer
Visitor
Visitor
4,314 Views
Registered: ‎10-17-2017

Forgot to mention I'm using linuxptp v1.8 here is the typical output:

 

# ptp4l -i eth0 -m
ptp4l[58.894]: selected /dev/ptp0 as PTP clock
ptp4l[58.895]: driver changed our HWTSTAMP options
ptp4l[58.895]: tx_type   1 not 1
ptp4l[58.895]: rx_filter 1 not 12
ptp4l[58.895]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[58.895]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[64.972]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[64.972]: selected best master clock 20b0f7.fffe.03c5d6
ptp4l[64.972]: assuming the grand master role
ptp4l[65.972]: missing timestamp on transmitted sync
ptp4l[65.972]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[81.973]: driver changed our HWTSTAMP options
ptp4l[81.973]: tx_type   1 not 1
ptp4l[81.973]: rx_filter 1 not 12
ptp4l[81.973]: port 1: FAULTY to LISTENING on INIT_COMPLETE

One big hint of it not working is the "missing timestamp on transmitted sync" message

0 Kudos
nanz
Moderator
Moderator
4,231 Views
Registered: ‎08-25-2009

Hi @randomengineer,

While choosing EMIO as GEM TSU CLK, you can choose to use a very precise oscillator and feed it to this. The signals fmio_gem_tsu_clk_from_pl and fmio_gem_tsu_clk_to_pl_bufg ports should be connected in the loopback fashion.

 

Hope this helps.


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

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
randomengineer
Visitor
Visitor
4,187 Views
Registered: ‎10-17-2017

Hi @nanz,

 

Our team found that in the GEM_TSU_REF_CTRL register bit 24 was not set, which keeps the TSU from functioning... We also found that when we interrupted u-boot, and checked the same register, the bit was set... Any idea what could be causing the clock to get disabled during Linux boot?

 

Another note: The device tree entry of 50Mhz is correct, one problem we found was our fsbl wasn't propagating this value due to how it was built... We also managed to get mainline Macb working, which happens to retrieve this clk value automatically using the Common Clock Framework... There were a number of bugs that needed to be fixed with mainline Macb before PTP could function..

0 Kudos
nanz
Moderator
Moderator
4,178 Views
Registered: ‎08-25-2009

Hi @randomengineer,

Which version are you looking at? Can you check if you have enabled CONFIG_MACB_EXT_BD in the kernel configuration. This takes care of PTP dependencies in kernel as well. 

 

So tsu-clk should ideally be a clock node and CCF should take care of programming GEM_TSU_REF_CTRL register. However, depending on which version you are using, MACB driver might need to be patched for this if it's not there in the kernel.


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

Don’t forget to reply, kudo, and accept as solution.

If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs and our Versal Ethernet Sticky Note.

-------------------------------------------------------------------------------------------
0 Kudos
randomengineer
Visitor
Visitor
4,171 Views
Registered: ‎10-17-2017

Hi @nanz,

We do have the CONFIG_MACB_EXT_BD option configured in our kernel config, and we are using the mainline kernel version of macb, which adds tsu_clk as a clock name, and not a property like the current Xilinx version of the macb driver...

 

So our device tree entry looks like

&gem3{
            clocks = <&clkc 31>, <&clkc 52>,<&clkc 48>,<&clkc 52>,<&clkc 43>
            clock-names = "plck", "hclk", "tx_clk", "rx_clk", "tsu_clk"
};

where clkc 43 points to gem_tsu_ref

0 Kudos
randomengineer
Visitor
Visitor
5,637 Views
Registered: ‎10-17-2017

Hi @nanz,

 

I think we have it figured out... We made changes to the driver to enable the clock through the CCF driver as per the documentation

https://elinux.org/images/b/b8/Elc2013_Clement.pdf

 

View solution in original post

0 Kudos
sergios_
Visitor
Visitor
3,868 Views
Registered: ‎05-04-2017

Hello randomengineer.

 

Please, could you share some details about the changes you made to get PTP working on Zynq Ultrascale? I think I'm in a similar case.

 

- I have enabled the GEM time-stamping clock the same way you showed in you original post.

- I have connected the emio_enet_tsu_clk input to an external 100 MHz clock signal (fmio_gem_tsu_clk_from_pl and fmio_gem_tsu_clk_to_pl_bufg left unconnected).

- CONFIG_MACB_EXT_BD is enabled by default in the kernel configuration.

- I have added "tsu-clk = <100000000>;" to GEM3 definition in devitree.

 

I'm using a ZCU102 development board and linuxPTP as you mentioned. The Linux kernel is cloned from Xilinx repositories and positioned at "xilinx-v2017.4" tag.

 

I keep getting "missing timestamp on transmitted sync" message, and adding some printk to macb driver I can see the timestamp value read is always zero.

 

Any help would be appreciated. Thanks.

0 Kudos
aaron_b1
Explorer
Explorer
3,478 Views
Registered: ‎12-20-2017

I would also like to know how you solved this.  This forum has a few Ultrascale+/PTP problems that have no responses from the xilinx folks.  If you've solved this somehow, we would all really appreciate knowing how.

 

0 Kudos
astone21480
Participant
Participant
2,214 Views
Registered: ‎05-14-2012

Please post more details. We are having similar issues. Xilinx has not been helpful either.

0 Kudos