Hello Daniel,
I think with increase the tx_timestamp_timeout to 100 should the problem
disappear.
You have to adapt this in config file. (e.g. default config in the configs
folder of ptp4l source folder )
ptp4l -f configs/default.cfg.
Please let me know what happen.
I think your previously problem have to do with wrong clock selection. My
interpretation you had with STRATIX10_PERI_EMAC_PTP_CLK the default clock as
ptp reference clock set and with altr,f2h_ptp_ref_clk the external clock
selected.
I think this could be explain the previous problem.
Best regards,
Mario
Gesendet: Freitag, 21. August 2020 um 18:37 Uhr
Von: "Zuckerbrod, Daniel" <dzuckerb...@textronsystems.com>
An: "Mario Molitor" <mario_moli...@web.de>
Cc: "linuxptp-users@lists.sourceforge.net"
<linuxptp-users@lists.sourceforge.net>
Betreff: RE: RE: Re: [Linuxptp-users] Stratix 10 & PTP
Hi Mario,
I made the change like you said except that I made my input clock 100 MHz and
not 125 MHz since that is the clock that I am inputting into the ARM from the
FPGA fabric.
It looks like it is now able to synchronize with my PTP server:
root@stratix10:~/ptp4l_output# ./ptp4l -m -s -H -i eth1
ptp4l[455.076]: selected /dev/ptp1 as PTP clock
ptp4l[455.077]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[455.077]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[456.106]: port 1: new foreign master 001b21.fffe.c00dd6-1
ptp4l[462.106]: selected best master clock 001b21.fffe.c00dd6
ptp4l[462.106]: foreign master not using PTP timescale
ptp4l[462.106]: running in a temporal vortex
ptp4l[462.106]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[465.106]: master offset -30668465921842260 s0 freq +0 path delay
47996
ptp4l[466.106]: master offset -30668465921855884 s1 freq -13624 path delay
45125
ptp4l[467.106]: master offset -462 s2 freq -14086 path delay 45125
ptp4l[467.106]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[468.106]: master offset -2807 s2 freq -16570 path delay 45125
ptp4l[469.106]: master offset -87 s2 freq -14692 path delay 44988
ptp4l[470.106]: master offset -1469 s2 freq -16100 path delay 44852
ptp4l[471.106]: master offset 53 s2 freq -15019 path delay 44852
ptp4l[472.106]: master offset 1376 s2 freq -13680 path delay 42445
ptp4l[473.106]: master offset 1244 s2 freq -13399 path delay 42445
ptp4l[474.106]: master offset 50 s2 freq -14220 path delay 40277
ptp4l[475.106]: master offset -2006 s2 freq -16261 path delay 42564
ptp4l[476.206]: master offset -1239 s2 freq -16095 path delay 42564
ptp4l[477.106]: master offset 2043 s2 freq -13185 path delay 40277
ptp4l[478.106]: master offset -1569 s2 freq -16184 path delay 40747
ptp4l[479.106]: master offset 361 s2 freq -14725 path delay 40747
But then there is a packet drop or something which causes a fault. It looks
like ptp4l never fully recovers from the fault. There is some known packet drop
in the system we are investigating.
ptp4l[480.056]: timed out while polling for tx timestamp
ptp4l[480.056]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[480.056]: port 1: send delay request failed
ptp4l[480.056]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[496.057]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[497.106]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[498.106]: port 1: new foreign master 001b21.fffe.c00dd6-1
ptp4l[502.106]: selected best master clock 001b21.fffe.c00dd6
ptp4l[502.106]: foreign master not using PTP timescale
ptp4l[502.106]: running in a temporal vortex
ptp4l[502.106]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[503.106]: master offset -30668465922413919 s0 freq -14725 path delay
40747
ptp4l[503.439]: timed out while polling for tx timestamp
ptp4l[503.439]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[503.439]: port 1: send delay request failed
ptp4l[503.439]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[519.440]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[520.105]: port 1: new foreign master 001b21.fffe.c00dd6-1
ptp4l[524.105]: selected best master clock 001b21.fffe.c00dd6
ptp4l[524.105]: foreign master not using PTP timescale
ptp4l[524.105]: running in a temporal vortex
ptp4l[524.105]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[525.105]: master offset -30668465922749071 s2 freq -30212 path delay
40747
ptp4l[525.105]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[526.105]: master offset -30668465922735164 s2 freq -62500000 path delay
40747
ptp4l[527.105]: master offset -30668465860279042 s2 freq -62500000 path delay
40747
ptp4l[528.105]: master offset -30668465797792646 s2 freq -62500000 path delay
38320
ptp4l[529.105]: master offset -30668465735308606 s2 freq -62500000 path delay
38320
ptp4l[530.105]: master offset -30668465651913853 s2 freq -62500000 path delay
-20872735
ptp4l[531.105]: master offset -30668465588447389 s2 freq -62500000 path delay
-21855463
ptp4l[532.105]: master offset -30668465525963736 s2 freq -62500000 path delay
-21855463
ptp4l[533.105]: master offset -30668465463480096 s2 freq -62500000 path delay
-21855463
ptp4l[533.708]: timed out while polling for tx timestamp
ptp4l[533.708]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[533.709]: port 1: send delay request failed
ptp4l[533.709]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[549.709]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[550.105]: port 1: new foreign master 001b21.fffe.c00dd6-1
ptp4l[554.105]: selected best master clock 001b21.fffe.c00dd6
ptp4l[554.105]: foreign master not using PTP timescale
ptp4l[554.105]: running in a temporal vortex
ptp4l[554.105]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[555.105]: master offset -30668465901309870 s2 freq -62500000 path delay
-21855463
ptp4l[555.105]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[556.105]: master offset -30668465838856106 s2 freq -62500000 path delay
-21855463
ptp4l[557.105]: master offset -30668465776372003 s2 freq -62500000 path delay
-21855463
ptp4l[558.105]: master offset -30668465713887961 s2 freq -62500000 path delay
-21855463
ptp4l[558.216]: timed out while polling for tx timestamp
ptp4l[558.216]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[558.216]: port 1: send delay request failed
ptp4l[558.216]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
Also the “freq -62500000” shows up after the fault. Any clue why ptp4l doesn’t
recover?
Thanks,
Daniel
From: Mario Molitor <mario_moli...@web.de>
Sent: Friday, August 21, 2020 5:00 AM
To: Zuckerbrod, Daniel <dzuckerb...@textronsystems.com>
Cc: linuxptp-users@lists.sourceforge.net
Subject: Aw: RE: Re: [Linuxptp-users] Stratix 10 & PTP
Hello Daniel,
I have verified your provide dmesg printout and could not seen this problem.
But in your Dev-tree I miss altr,f2h_ptp_ref_clk = "true".
Also I miss 100 Mhz Clock in your dev-tree, but I think the first point
(f2h_ptp_ref_clk = "true") is more important.
For comparing see my following dev-tree cutting:
&gmac0 {
status = "okay";
compatible = "synopsys,dwmac-16.1", "altr,socfpga-stmmac",
"snps,dwmac-3.70a", "snps,dwmac";
altr,f2h_ptp_ref_clk = "true";
phy-handle = <&phy0>;
phy-mode = "rgmii";
//phy-addr = <0xffffffff>;
clocks = <&emac_0_clk &clk_125MHz>;
clock-names = "stmmaceth", "ptp_ref";
...
...
....
clocks {
...
clk_125MHz: clk_125MHz {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <125000000>; /* 125.00 MHz */
clock-output-names = "clk_125MHz-clk";
}; //end clk_125MHz (clk_125MHz)
Please let me know what happen if you have correct this.
Thanks
Mario
Gesendet: Donnerstag, 20. August 2020 um 16:50 Uhr
Von: "Zuckerbrod, Daniel"
<dzuckerb...@textronsystems.com[mailto:dzuckerb...@textronsystems.com]>
An: "Mario Molitor" <mario_moli...@web.de[mailto:mario_moli...@web.de]>
Cc:
"linuxptp-users@lists.sourceforge.net[mailto:linuxptp-users@lists.sourceforge.net]";
<linuxptp-users@lists.sourceforge.net[mailto:linuxptp-users@lists.sourceforge.net]>
Betreff: RE: Re: [Linuxptp-users] Stratix 10 & PTP
Hi Mario,
Attached are my 4.14.73-ltsi dmesg output and DTS. Please let me know if you
think this patch will help with the issue I am seeing.
Thanks,
Daniel
From: Mario Molitor <mario_moli...@web.de[mailto:mario_moli...@web.de]>
Sent: Wednesday, August 19, 2020 6:01 PM
To: Zuckerbrod, Daniel
<dzuckerb...@textronsystems.com[mailto:dzuckerb...@textronsystems.com]>
Cc:
linuxptp-users@lists.sourceforge.net[mailto:linuxptp-users@lists.sourceforge.net]
Subject: Aw: Re: [Linuxptp-users] Stratix 10 & PTP
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[mailto:dzuckerb...@textronsystems.com]>
An:
"linuxptp-users@lists.sourceforge.net[mailto:linuxptp-users@lists.sourceforge.net]";
<linuxptp-users@lists.sourceforge.net[mailto: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[mailto: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[mailto:Linuxptp-users@lists.sourceforge.net]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users[https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-users&data=02%7C01%7Cdzuckerbrod%40textronsystems.com%7C2ec13da5860847a1974d08d845b093d5%7C2d5b202c8c074168a55166f570d429b3%7C0%7C0%7C637335972002342761&sdata=i59fFt4OJvb%2FyQyXEdFkg8AGr9PeCoVyg%2BGb8a3XJrI%3D&reserved=0]
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
