[参考译文] PROCESSOR-SDK-AM64X：PRU PPS PTP 同步问题

您好、 Daolin、

感谢您的答复。   

请注意、通过确保 testptp 运行、来自 testptp 的 PPS 信号只能同步到 ptp4l  之后 ptp4l 正在运行。 如果 ptp4l 曾经重新启动、您还应该确保 testptp 重新启动、以便 PPS 信号可以重新同步到 ptp4l。 [/报价]

我描述的问题也发生在另一种情况下。 根据注释、即使我先启动 ptp4l（等待同步）、然后打开 PPS 输出并在下一步中长时间断开主时钟（例如 30 分钟）、 然后 AM64x 时钟不同步、因此 PPS 输出从主时钟移出很大距离基准 PPS 脉冲、然后在将主时钟重新连接到 AM64x 后、PPS 输出绝不会与基准 PPS 同步、就像在断开主时钟之前那样。 它将偏移几毫秒、直到 PPS 输出关闭并使用 testptp 再次开启。

也许有一个解决方案（修复/改进内核驱动程序）来避免这种行为,并使 ptp4l 始终能够同步 PPS 输出?
如果 PPS 是否正确同步、则很难从 Linux 用户空间检测到。 Ptp4l 显示主器件偏移为几纳秒、而 PPS 输出偏移为几毫秒。

您好、Michal、  

根据注释、即使我先启动 ptp4l（等待同步）、然后打开 PPS 输出、然后在下一步中断开主时钟长时间（例如 30 分钟）、 然后 AM64x 时钟不同步、因此 PPS 输出从主时钟移出很大距离基准 PPS 脉冲、然后在将主时钟重新连接到 AM64x 后、PPS 输出绝不会与基准 PPS 同步、就像在断开主时钟之前那样。 它将偏移几毫秒、直到 PPS 输出关闭并使用 testptp 再次开启。

感谢您解释这一特殊情况。 还有一个问题、当主时钟断开时、ptp4l 是否停止运行？ 根据该注释、当 ptp4l 从未停止运行或同步停止时、PPS 信号必须在 PTP 同步恢复后停止并再次启动。  

我在 ti-linux-kernel 存储库中找到以下信息：pPS 同步的修复是在大约 11.2024 年 11 月 11 日 https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?id=dc065076ee7768377d7c16af7d1b0767782d8c98 的 icssg-prueth 中实现的 、并且仅在打开 PPS 信号时执行。 是否不应该在 ICSS-IEP 中实现类似的修复、以便在 ptp4l 执行校正期间正确校正 PPS 信号偏移？

我还将与开发人员联系、了解开发人员是否可以在 PTP 同步时同步 PPS、而无需重新启动 PPS。

我正在使用 TQMa64xxL 在定制电路板上测试 PPS-AM64X 版本：11.00.09.04 (Debian-Trixie)。

即使我先启动 PROCESSOR-SDK-LINUX-RT 时钟同步、再打开下一个时钟时间为长（示例）、请等待 ppt430 分钟、 然后 AM64x 时钟不同步、因此 PPS 输出从主时钟移出很大距离基准 PPS 脉冲、然后在将主时钟重新连接到 AM64x 后、PPS 输出绝不会与基准 PPS 同步、就像在断开主时钟之前那样。 它将偏移几毫秒、直到 PPS 输出关闭并使用 testptp 再次开启。

您是否有访问 AM64x EVM 的权限？ 如果是、您是否能够复制 AM64x EVM 上描述的用例？

-道林

您好、Michal、  

主时钟断开时、ptp4l 仍然工作并 查找主时钟、因此根据注释停止并再次启动 PPS 信号不应该是必需的。

感谢您的确认、让我在内部检查这一特定案例。 然而、根据我从开发人员得到的反馈（“ PTP 同步应发生并在触发 PPS 之前达到稳定状态：）、似乎不只是 PTP 停止的情况、如果 PTP 同步不稳定且需要重新同步、则 PPS 应在 PTP 重新同步后重新启动。 这似乎适用于这种特定情况、在断开和重新连接电缆后、需要校正 PTP 同步、此时 PPS 不会动态更新以反映这一点。

我还将与开发人员联系、了解开发人员是否可以在 PTP 同步时同步 PPS、而无需重新启动 PPS。

谢谢。 这将是最好的解决方案;-)。

[/报价]

我得到了反馈、对于 PRU_ICSSG 接口、通常必须在 PTP 完成同步后手动重新启动 PPS。 “进行 PTP 同步时、底层 PTP 时钟会得到校正、但已经生成的 PPS 信号不会产生任何影响。 因此、尽管时钟同步、您不会看到 PPS 信号实现同步“

但是、我询问是否有机会在无需重新启动 PPS 的情况下将 PPS 信号动态调整为 PTP 时钟校正。 作为免责声明、由于开发人员本周正在开展其他一些高优先级活动、因此可能需要一些时间才能获得一些反馈。

您是否有访问 AM64x EVM 的权限？ 如果是、您是否能够复制 AM64x EVM 上描述的用例？

遗憾的是、我无法访问 AM64x EVM、但在我的定制电路板上、PPS 输出接线与 EVM 上的接线相同。

[/报价]

我计划在我这边的 AM64x EVM 上尝试和测试它、但我可能只有在星期四之后才能使用。 如果您没有收到星期四的回复、请 Ping 此主题。

-道林

[/quote]

您好、Michal、  

Michal Bajkacz 说：

您是否有访问 AM64x EVM 的权限？ 如果是、您是否能够复制 AM64x EVM 上描述的用例？

遗憾的是、我无法访问 AM64x EVM、但在我的定制电路板上、PPS 输出接线与 EVM 上的接线相同。

我计划在我这边的 AM64x EVM 上尝试和测试它、但我可能只有在星期四之后才能使用。 如果您没有收到星期四的回复、请 Ping 此主题。

[/报价]

我尝试通过设置以下内容来复制您描述的特定案例：

测试拓扑：

• AM64x EVM（Grandmaster 时钟）<-->AM64x EVM（跟随器时钟）
• 两个运行 Yocto 构建的 RT-Linux SDK 10.1 的 EVM（这是我手头的工作，需要一些时间才能使用相同的 Debian RT-Linux SDK 11.0 进行设置）  
• 连接在两个 EVM 上的 eth2 (PRU-ICSSG) 接口上
• 使用逻辑分析仪测量两个 EVM 上 J18 接头上的 PPS 信号（ME 未准备好示波器）

测试顺序：

1. 使用 ptp4l -P –2 -H -i eth2 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp2 开始同步、其中 gPTP.cfg 文件的内容在以下代码片段中指定。
2. 等待同步完成
3. 使用/usr/kernel-selftest/ptp/testptp -d /dev/ptp2 -P 1 打开 PPS 输出
4. 断开电缆并等待 30 分钟
5. 重新连接电缆并观察 PPS 偏移

root@am64xx-evm:~# cat gPTP.cfg 
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 100 <---100 for Grandmaster, 240 for follower
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
ingressLatency 96
egressLatency 288 

但是、我无法看到您提到的毫秒级 PPS 偏移。 我同样地在断开电缆后经过大约 10 分钟的等待时间捕获了此信息、查看了我的 ptp4l 日志和从逻辑分析仪捕获的 PPS。

主 EVM 日志：

root@am64xx-evm:~# /usr/kernel-selftest/ptp/testptp -d /dev/ptp2 -P 1
pps for system time request okay
root@am64xx-evm:~# [ 531.236334] icssg-prueth icssg1-eth eth2: Link is Down

root@am64xx-evm:~# cat gPTP.cfg 
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 100
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
ingressLatency 96
egressLatency 288
root@am64xx-evm:~# ls
access_dp83869.sh        eth0-no-rate-limit.pcap iperf3_s_output.txt
automate_linkup_linkdown.sh   gPTP.cfg         mpstat-idle.sh
configure_network_schneider.sh hsr_latest.sh      num_linkup_down_cycle.txt
cpu-load-awk.sh         hsr_nonoffload_setup.sh ptp4l-gm-output.txt
cpu-load-mpstat.sh       hsr_setup.sh       top_store.sh
dut3_eth1_tcpdump.pcap     hsr_setup_cut_thru.sh
dut3_eth2_tcpdump.pcap     hsr_setup_v2.sh
root@am64xx-evm:~# cat ptp4l-gm-output.txt | tail -10
ptp4l[419.899]: port 1 (eth2): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[419.899]: selected local clock 70ff76.fffe.1f3c45 as best master
ptp4l[419.899]: port 1 (eth2): assuming the grand master role
ptp4l[468.771]: port 1 (eth2): new foreign master 70ff76.fffe.1f3dc5-1
ptp4l[470.771]: selected best master clock 70ff76.fffe.1f3dc5
ptp4l[470.771]: port 1 (eth2): assuming the grand master role
ptp4l[531.239]: port 1 (eth2): link down
ptp4l[531.239]: port 1 (eth2): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[531.248]: selected local clock 70ff76.fffe.1f3c45 as best master
ptp4l[531.248]: port 1 (eth2): assuming the grand master role
root@am64xx-evm:~# [ 872.228314] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow contf

root@am64xx-evm:~# cat ptp4l-gm-output.txt | tail -10
ptp4l[470.771]: port 1 (eth2): assuming the grand master role
ptp4l[531.239]: port 1 (eth2): link down
ptp4l[531.239]: port 1 (eth2): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[531.248]: selected local clock 70ff76.fffe.1f3c45 as best master
ptp4l[531.248]: port 1 (eth2): assuming the grand master role
ptp4l[872.224]: port 1 (eth2): link up
ptp4l[872.248]: port 1 (eth2): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[875.934]: port 1 (eth2): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[875.934]: port 1 (eth2): assuming the grand master role
ptp4l[875.993]: port 1 (eth2): new foreign master 70ff76.fffe.1f3dc5-1
root@am64xx-evm:~#

跟随者 EVM 日志：

root@am64xx-evm:~# /usr/kernel-selftest/ptp/testptp -d /dev/ptp2 -P 1
pps for system time request okay
root@am64xx-evm:~# [ 529.572816] icssg-prueth icssg1-eth eth2: Link is Down

root@am64xx-evm:~# cat ptp4l-follower.txt | tail -10
ptp4l[525.597]: rms  3 max  4 freq -3521 +/-  4 delay  67 +/-  0
ptp4l[526.598]: rms  5 max  8 freq -3523 +/-  7 delay  67 +/-  0
ptp4l[527.598]: rms  5 max  8 freq -3514 +/-  4 delay  67 +/-  0
ptp4l[528.599]: rms  8 max  11 freq -3514 +/- 11 delay  67 +/-  0
ptp4l[528.974]: port 1 (eth2): SLAVE to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[528.974]: selected local clock 70ff76.fffe.1f3dc5 as best master
ptp4l[528.974]: port 1 (eth2): assuming the grand master role
ptp4l[529.576]: port 1 (eth2): link down
ptp4l[529.576]: port 1 (eth2): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[529.585]: port 1 (eth2): assuming the grand master role
root@am64xx-evm:~# [ 870.564949] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow contrf

root@am64xx-evm:~# cat ptp4l-follower.txt | tail -10
ptp4l[529.576]: port 1 (eth2): link down
ptp4l[529.576]: port 1 (eth2): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[529.585]: port 1 (eth2): assuming the grand master role
ptp4l[870.565]: port 1 (eth2): link up
ptp4l[870.579]: port 1 (eth2): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[873.694]: port 1 (eth2): new foreign master 70ff76.fffe.1f3c45-1
ptp4l[873.750]: port 1 (eth2): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[873.750]: port 1 (eth2): assuming the grand master role
ptp4l[875.694]: selected best master clock 70ff76.fffe.1f3c45
ptp4l[875.695]: port 1 (eth2): MASTER to UNCALIBRATED on RS_SLAVE
root@am64xx-evm:~# cat ptp4l-follower.txt | tail -10
ptp4l[873.750]: port 1 (eth2): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[873.750]: port 1 (eth2): assuming the grand master role
ptp4l[875.694]: selected best master clock 70ff76.fffe.1f3c45
ptp4l[875.695]: port 1 (eth2): MASTER to UNCALIBRATED on RS_SLAVE
ptp4l[876.695]: port 1 (eth2): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[877.570]: rms 13873 max 24294 freq +20890 +/- 6716 delay  68 +/-  1
ptp4l[878.571]: rms 4124 max 5773 freq +2355 +/- 3711 delay  70 +/-  0
ptp4l[879.571]: rms 5356 max 5880 freq -5337 +/- 950 delay  72 +/-  0
ptp4l[880.572]: rms 2888 max 4020 freq -6154 +/- 269 delay  72 +/-  0
ptp4l[881.572]: rms 753 max 1338 freq -4865 +/- 395 delay  72 +/-  0
root@am64xx-evm:~#  
root@am64xx-evm:~# cat ptp4l-follower.txt | tail -10                      
ptp4l[1748.517]: rms  8 max  14 freq -3423 +/- 10 delay  554 +/-  0
ptp4l[1749.517]: rms  15 max  22 freq -3436 +/- 20 delay  556 +/-  0
ptp4l[1750.518]: rms  14 max  19 freq -3429 +/- 19 delay  556 +/-  0
ptp4l[1751.518]: rms  11 max  20 freq -3423 +/- 14 delay  556 +/-  0
ptp4l[1752.519]: rms  11 max  25 freq -3422 +/- 15 delay  554 +/-  0
ptp4l[1753.520]: rms  13 max  28 freq -3414 +/- 17 delay  556 +/-  0
ptp4l[1754.520]: rms  12 max  17 freq -3418 +/- 16 delay  556 +/-  0
ptp4l[1755.521]: rms  10 max  14 freq -3422 +/- 14 delay  556 +/-  0
ptp4l[1756.521]: rms  13 max  23 freq -3420 +/- 18 delay  557 +/-  0
ptp4l[1757.522]: rms  15 max  23 freq -3419 +/- 21 delay  557 +/-  0

作为 TI 调试过程的一部分、我们通常需要能够复制在 TI EVM 上观察到的问题。 如果我在尝试复制您的问题时遗漏了一些内容、请告诉我。

另外、作为一个先行者、我的回应可能会推迟到下周、因为我将参加一些培训课程。  

-道林

尊敬的 Daolin：

为了准确地重现我描述的情况、您必须使用“实数“主时钟来获得基准 PPS 输出信号和时间同步基准源。

我的测试表明、如果我长时间从 PRU-ICSSG eth 接口断开主时钟（我使用 Meinberg Lantime M600 或 Hyperion400 进行测试）（很难确切地说多长时间）、则 PPS 输出将相对于主时钟的基准 PPS 输出发生变化。 存在偏移阈值（我无法确定确切的值）、如果超过该阈值、则 ptp4l 无法将 pps 输出与 AM64x 同步

但是、我问过是否有机会在无需重新启动 PPS 的情况下将 PPS 信号动态调整为 PTP 时钟校正。 作为免责声明、由于开发人员本周正在开展其他一些高优先级活动、因此可能需要一些时间才能获得一些反馈。

这将是最佳解决方案。 然后、ptp4l 提供的有关同步精度的信息将与 PPS 输出相关联。

我使用 AM64x 的电路板的 PPS 输出用于同步多个从模块、这些模块必须与基准 PPS 信号精确同步。 在 AM64x Linux 用户空间下、我无法完全确认来自电路板的 PPS 信号与来自主时钟的 PPS 输出同步、这不符合在工业解决方案中的使用要求、它只能用于测试目的。

您好、Michal、

要准确地重现我描述的情况、您必须使用“实数“主时钟来获得参考 PPS 输出信号和时间同步的基准源。

您能详细解释一下“真正“的主时钟是什么意思吗？ 使用一个 AM64x EVM 并将其配置为主时钟的设置是否不算作“实际“主时钟？  

这将是最好的解决方案。 然后 ptp4l 提供的有关同步精度的信息将与 PPS 输出相关联。

我来跟进一下开发人员的相关事宜。  

在 AM64x Linux 用户空间下、我无法 100%确认来自电路板的 PPS 信号与来自主时钟的 PPS 输出同步、这不符合在工业解决方案中的使用资格、它只能用于测试目的。

根据我的理解、测量 PPS 同步精度的最准确方法是使用示波器测量实际的 PPS 信号、并比较网络中每个器件/模块的 PPS 信号。 我不知道 Linux 用户空间有没有特定的方法来测量所有连接的器件上的 PPS 同步精度。 ptp4l 同步日志理论上应该反映 PPS 同步、但最准确的检查方法仍然是使用示波器。

-道林