Hello Daniel,
yes, i have running the PTP on Cyclone V and Linux 4.14.71. It was the attached patch necessary.  I think you should see in dmesg a hint in the case that patch is  necessary.
I think your problem is more a wrong setting in your Dev-Tree or wrong connection in fpga. Could you please send me your Dev-Tree  and your dmesg printout for verify this?
Best regards,
Mario
Gesendet: Mittwoch, 19. August 2020 um 04:25 Uhr
Von: "Zuckerbrod, Daniel" <dzuckerb...@textronsystems.com>
An: "linuxptp-users@lists.sourceforge.net" <linuxptp-users@lists.sourceforge.net>
Betreff: Re: [Linuxptp-users] Stratix 10 & PTP

I have tried to move to Linux Kernel 5.7.0 (intel-socfpga) and ran into the same issues. Does anyone have a working PTP implementation in an Intel FPGA?

 

From: Zuckerbrod, Daniel
Sent: Monday, August 10, 2020 9:27 AM
To: linuxptp-users@lists.sourceforge.net
Subject: Stratix 10 & PTP

 

Hi,

 

I am using an Intel/Altera Stratix 10 and would like to use the ARM HPS EMAC PTP interface. I am providing a 100 MHz to the s10_hps_emac_ptp_ref_clock_clk with plans to use the PTP timestamp in the FPGA fabric. I can see the timestamp serially shift out of the ARM as expected.

 

However, no matter what I change in the device tree I seem to always have issues using hardware timestamping (./ptp4l -m -s -i eth1 -H).

 

Software timestamping always works without issue (./ptp4l -m -s -i eth1 -S).

 

I am not sure what the “freq” column means, but it always says -62500000:

 

ptp4l[276.189]: master offset -29715517212917536 s0 freq -62500000 path delay  35700952

ptp4l[277.189]: clockcheck: clock jumped backward or running slower than expected!

 

I am using Linux Kernel version 4.14.73

 

Any help would be appreciated.

 

Thanks,

Daniel

 

 

 

_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
From 2d9ebd65b61805b844a15e156c2673b16bd3e140 Mon Sep 17 00:00:00 2001
From: Mario Molitor
Date: Fri, 16 Nov 2018 09:14:59 +0100
Subject: [PATCH 1/1] stmmac : bugfix of read from HWID after reset

---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1a9a382..6cd010cf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -23,7 +23,7 @@
   Support available at:
 	https://bugzilla.stlinux.com/
 *******************************************************************************/
-
+#include <linux/delay.h>
 #include <linux/clk.h>
 #include <linux/kernel.h>
 #include <linux/interrupt.h>
@@ -4151,15 +4151,15 @@ int stmmac_dvr_probe(struct device *device,
 		priv->plat->phy_addr = phyaddr;

 	if (priv->plat->stmmac_rst) {
-		ret = reset_control_assert(priv->plat->stmmac_rst);
+		//ret = reset_control_assert(priv->plat->stmmac_rst);
 		reset_control_deassert(priv->plat->stmmac_rst);
 		/* Some reset controllers have only reset callback instead of
 		 * assert + deassert callbacks pair.
 		 */
-		if (ret == -ENOTSUPP)
-			reset_control_reset(priv->plat->stmmac_rst);
+		//if (ret == -ENOTSUPP)
+		//	reset_control_reset(priv->plat->stmmac_rst);
 	}
-
+	usleep_range(10, 20);
 	/* Init MAC and get the capabilities */
 	ret = stmmac_hw_init(priv);
 	if (ret)
--
2.7.4

_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Reply via email to