Problems using Zynq UltraScale+ MPSoC GEM TSU for PTP

[sergios_]

Hello.

I'm trying to use the Time Stamping Units integrated in the GEM of a Zynq UltraScale+ MPSoC. I'm working with LinuxPTP over a ZCU102 development board. The Linux kernel is cloned from Xilinx repositories and positioned at "xilinx-v2017.4" tag.

Until now I have followed these steps:

- I have enabled the GEM time-stamping clock and enabled it to function through the EMIO interface.
- 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.

Every time I start LinuxPTP I'm getting "missing timestamp on transmitted sync" message, and adding some printk to macb driver I can see the timestamp value read is always zero.

In fact, using phc_ctl and debugging messages added in the macb driver I can write the registers GEM_1588S and GEM_1588NS, but when I read them back I always read zeroes. It seems that the TSU timer is reset.

Am I missing something?  Any help would be appreciated. Thanks.

[aaron_b1]

Hello @sergios_.  Did you ever get a solution?  I'm facing this problem now.

[sergios_]

Unfortunately I didn't get any answer from Xilinx.

We have this development stopped for the moment but if you find a solution please let me know.

[aaron_b1]

Thank you.

Would you mind telling me how you got the tsu-clk entry in the device tree?  I haven't seen that.  I asked the firmware developer to connect a clock, and I pulled the new HDF file into my petalinux project.  After that, the new device tree had some changed offsets and handles, but there was no new "tsu-clk" property in my device tree entry. 

I attempted to override this device tree entry with a system-user.dtsi entry that would contained a tsu-clk entry, but that failed (that seemed to move the offsets around, and after that, the ethernet device didn't work until I backed that change out)

So, I am unclear how "tsu-clk" is supposed to get into the device tree.

[nanz]

Hi ,

Could you please try connecting fmio_gem_tsu_clk_from_pl and fmio_gem_tsu_clk_to_pl_bufg together? This is the recommended way to loopback the clk.

[aaron_b1]

It turns out my particular problem was getting the tsu-clk device node property for my ethernet device.

In order for PTP to work, your ethernet's node in the device tree must have a "tsu-clk" attribute.  You must add this manually, and no changes are needed to the hardware platform in vivado.

Since I haven't seen this anywhere online, I'll go ahead and post the procedure for adding it to a petalinux project here:

To add the tsu-clk entry to your device tree, edit project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi so that it contains something like this:

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

     amba {
          ethernet@ff0e0000 {
                tsu-clk = <250000000>;
          };
     };
};

It will differ on your system.  You need to use dtc -I dtb -O dts system.dtb" to look at your existing device tree to see what ethernet device you are using.  The main idea is that you are adding the line "tsu-clk = <250000000>;" to your node.  The value 250000000 is the default for my system, and I had to go into vivado to find this out.

There were a few "ethernet" devices in my device tree, but I found there was only one ethernet device in the device tree with "status = "okay""

Reference: https://developer.toradex.com/device-tree-customization#overwriting-properties

[aaron_b1]

I should also mention that the firmware/HDF that vivado outputs matters.  I have had this break the functionality of PTP.

Specifically, when I erroneously asked the firmware developer to add the clock to the gem tsu input, that seemed to break PTP.  When I added the tsu-clk entry to my device tree, things STILL didn't work.  I had to go back to a version of firmware before this change was made in order to get PTP working.

[astone21480]

I just got this working today with emio with 2018.3. I had to add property clock-frequency= <250000000> to the tsu_ext_clk node in my system-user.dtsi. I found this by putting debug statements in the macb_main.c. If anyone needs me to elaborate I can. Basically, you are seeing the ns increment register set back to 0 by the driver. It needs the tsu_rate and it isn't being set correctly on initialization. I also had problems with Petalinux not using the hdf register values. I had to use: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842475/PetaLinux+Yocto+Tips

Section: 

How to update psu_init files in PetaLinux Project

do_compile_prepend(){
   install -m 0644 ${TOPDIR}/../project-spec/hw-description/psu_init.c ${B}/fsbl/psu_init.c
}

[ritakur]

Are all the necessary setting documented in the https://japan.xilinx.com/support/answers/67239.html?
If not, we would need to get it updated.
Would you please let me know where is the tsu_rate?