Hi Mario,
I will ultimately need both eth1 and eth2 sync'ing to different PTP masters
(multi-channel application where each channel is supposed to sync up to its
master).
When I try to run the same command on eth2 (channel 2) I am seeing different
results:
root@stratix10:~/ptp4l_output# ./ptp4l -m -s -H -i eth2 --tx_timestamp_timeout
100
ptp4l[641.964]: selected /dev/ptp2 as PTP clock
ptp4l[641.965]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[641.965]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[648.168]: selected local clock a20d98.fffe.10c90c as best master
ptp4l[655.362]: selected local clock a20d98.fffe.10c90c as best master
ptp4l[662.986]: selected local clock a20d98.fffe.10c90c as best master
ptp4l[669.636]: selected local clock a20d98.fffe.10c90c as best master
ptp4l[677.105]: selected local clock a20d98.fffe.10c90c as best master
The line " ptp4l[641.964]: selected /dev/ptp2 as PTP clock" was not there when
I ran with eth1. The device tree entries are identical between gmac1 and gmac2
other than the emac clocks and resets.
clk_100MHz: clk_100MHz {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <100000000>; /* 100.00 MHz */
clock-output-names = "clk_100MHz-clk";
}; //end clk_100MHz (clk_100MHz)
gmac1: ethernet@ff802000 {
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.74a",
"snps,dwmac";
reg = <0xff802000 0x2000>;
altr,f2h_ptp_ref_clk = "true";
interrupts = <0 91 4>;
interrupt-names = "macirq";
mac-address = [00 00 00 00 00 00];
resets = <&rst 33 &rst 41>;
reset-names = "stmmaceth", "stmmaceth-ocp";
clocks = <&clkmgr 53>, <&clk_100MHz>;
clock-names = "stmmaceth", "ptp_ref";
tx-fifo-depth = <16384>;
rx-fifo-depth = <16384>;
snps,multicast-filter-bins = <256>;
altr,sysmgr-syscon = <&sysmgr 0x48 0>;
phy-mode = "gmii";
status = "okay";
fixed-link {
speed = <1000>;
full-duplex;
};
};
gmac2: ethernet@ff804000 {
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.74a",
"snps,dwmac";
reg = <0xff804000 0x2000>;
altr,f2h_ptp_ref_clk = "true";
interrupts = <0 92 4>;
interrupt-names = "macirq";
mac-address = [00 00 00 00 00 00];
resets = <&rst 34 &rst 42>;
reset-names = "stmmaceth", "stmmaceth-ocp";
clocks = <&clkmgr 54>, <&clk_100MHz>;
clock-names = "stmmaceth", "ptp_ref";
tx-fifo-depth = <16384>;
rx-fifo-depth = <16384>;
snps,multicast-filter-bins = <256>;
altr,sysmgr-syscon = <&sysmgr 0x4c 0>;
phy-mode = "gmii";
status = "okay";
fixed-link {
speed = <1000>;
full-duplex;
};
};
Thanks,
Daniel
-----Original Message-----
From: Zuckerbrod, Daniel
Sent: Friday, August 21, 2020 2:29 PM
To: Mario Molitor <mario_moli...@web.de>
Cc: linuxptp-users@lists.sourceforge.net
Subject: RE: RE: RE: Re: [Linuxptp-users] Stratix 10 & PTP
Mario you have just made my day! It works!
The Stratix 10 ARM enters slave mode and does not run into any faults. To save
myself having to create a config file I just passed the tx_timestamp_timeout as
a switch.
root@stratix10:~/ptp4l_output# ./ptp4l -m -s -H -i eth1 --tx_timestamp_timeout
100
ptp4l[111.343]: selected /dev/ptp1 as PTP clock
ptp4l[111.350]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[111.350]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[112.423]: port 1: new foreign master 001b21.fffe.c00dd6-1
ptp4l[116.423]: selected best master clock 001b21.fffe.c00dd6
ptp4l[116.424]: foreign master not using PTP timescale
ptp4l[116.424]: running in a temporal vortex
ptp4l[116.424]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[120.423]: master offset -30675805846782638 s0 freq +0 path delay
46177
ptp4l[121.423]: master offset -30675805846797286 s1 freq -14648 path delay
46859
ptp4l[122.423]: master offset -1982 s2 freq -16630 path delay 46859
ptp4l[122.423]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[124.423]: master offset 4849 s2 freq -10394 path delay 42672
ptp4l[125.423]: master offset 3009 s2 freq -10779 path delay 40583
ptp4l[126.423]: master offset -3068 s2 freq -15954 path delay 41238
ptp4l[127.423]: master offset -1059 s2 freq -14865 path delay 40989
ptp4l[128.423]: master offset -2646 s2 freq -16770 path delay 40989
ptp4l[130.423]: master offset 527 s2 freq -14391 path delay 40740
ptp4l[131.423]: master offset 1355 s2 freq -13404 path delay 40277
ptp4l[133.423]: master offset -3004 s2 freq -17357 path delay 40572
ptp4l[135.423]: master offset 1496 s2 freq -13758 path delay 40572
ptp4l[136.423]: master offset -1342 s2 freq -16147 path delay 40572
ptp4l[137.423]: master offset 814 s2 freq -14394 path delay 40572
ptp4l[138.423]: master offset -1400 s2 freq -16364 path delay 40572
ptp4l[139.423]: master offset 795 s2 freq -14589 path delay 40572
ptp4l[140.423]: master offset -942 s2 freq -16087 path delay 40566
ptp4l[142.423]: master offset 908 s2 freq -14520 path delay 40245
ptp4l[143.423]: master offset 1125 s2 freq -14030 path delay 40226
ptp4l[144.423]: master offset -1095 s2 freq -15913 path delay 40226
ptp4l[145.423]: master offset 489 s2 freq -14657 path delay 40226
ptp4l[146.423]: master offset -1262 s2 freq -16262 path delay 40385
ptp4l[147.423]: master offset 255 s2 freq -15123 path delay 40226
ptp4l[148.423]: master offset -3 s2 freq -15305 path delay 39932
ptp4l[149.423]: master offset 1104 s2 freq -14199 path delay 39932
ptp4l[150.423]: master offset -1084 s2 freq -16056 path delay 39932
ptp4l[151.423]: master offset 1264 s2 freq -14033 path delay 39530
ptp4l[153.423]: master offset -1714 s2 freq -16632 path delay 39932
ptp4l[154.423]: master offset -1291 s2 freq -16723 path delay 39932
ptp4l[155.423]: master offset 987 s2 freq -14832 path delay 39932
ptp4l[156.423]: master offset -585 s2 freq -16108 path delay 39932
ptp4l[157.423]: master offset 1650 s2 freq -14048 path delay 39530
ptp4l[158.423]: master offset -459 s2 freq -15662 path delay 39514
ptp4l[159.423]: master offset 1015 s2 freq -14326 path delay 39514
ptp4l[160.423]: master offset -1326 s2 freq -16363 path delay 39514
ptp4l[161.422]: master offset 865 s2 freq -14569 path delay 39514
ptp4l[162.423]: master offset -654 s2 freq -15829 path delay 39254
ptp4l[163.422]: master offset 1035 s2 freq -14336 path delay 39254
Thank you!
-----Original Message-----
From: Mario Molitor <mario_moli...@web.de>
Sent: Friday, August 21, 2020 2:21 PM
To: Zuckerbrod, Daniel <dzuckerb...@textronsystems.com>
Cc: linuxptp-users@lists.sourceforge.net
Subject: Aw: RE: RE: Re: [Linuxptp-users] Stratix 10 & PTP
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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-users&data=02%7C01%7Cdzuckerbrod%40textronsystems.com%7C5dca295cc26341211d7108d845ff00f4%7C2d5b202c8c074168a55166f570d429b3%7C0%7C0%7C637336308865242761&sdata=qB19wX2yl26jQGO6PE5btPm06gpiXBlHxem6DQZIzts%3D&reserved=0[https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-users&data=02%7C01%7Cdzuckerbrod%40textronsystems.com%7C5dca295cc26341211d7108d845ff00f4%7C2d5b202c8c074168a55166f570d429b3%7C0%7C0%7C637336308865242761&sdata=qB19wX2yl26jQGO6PE5btPm06gpiXBlHxem6DQZIzts%3D&reserved=0]
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
