This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM623:i2401 的 CPSW/CPTS 权变措施问题(SDK 9.2 及更高版本)

Guru**** 2560150 points
Other Parts Discussed in Thread: SK-AM62B, SK-AM62B-P1

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1542526/am623-issues-with-cpsw-cpts-workaround-for-i2401-sdk-9-2-and-up

器件型号:AM623
主题中讨论的其他器件:SK-AM62BSK-AM62B-P1

工具/软件:

我们一直在努力 转换软件以使用  i2401 的解决方法 、并且遇到了一些问题。

1.第三方软件无法设置 HWTSTAMP_FILTER_ALL  

这会导致软件立即退出、即使它似乎仅需要 PTP 数据包的时间戳。 作为权变措施、我们转换了请求 HWTSTAMP_FILTER_ALL 的调用、而改为启用 HWTSTAMP_FILTER_PTP_V2_EVENT。

2. TI 驱动程序与多个 PTP 服务不兼容

由于使用了第三方软件、我们有两个 PTP 服务正在运行。 由于 poll() 删除时间戳并且每个数据包都是多播的、因此只有一个客户端可以接收时间戳。 我们可以通过不在 poll() 上删除并允许超时机制删除时间戳来解决此问题。 在我们的应用中、事件缓冲区似乎从未填满。

3.有些数据包仍然缺少时间戳

在上述权变措施的情况下、我们仍然会遇到偶尔出现的列表中没有时间戳的 PTP2 数据包。 我已经确认这不是由于列表填写的原因、到目前为止无法确定缺少时间戳的原因。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好 Mathew、  

    感谢您清楚地解释您观察到的问题。  

    首先、有几个问题、

    1.您专门使用哪个 SDK 版本?

    2.您发现此问题时、这是定制板还是 TI AM62x EVM?  

    3、由于我们无法使用两个 PTP 服务访问您的第三方软件、而我们在 Linux 上运行 PTP 的唯一示例是 linuxptp (ptp4l)、您是否只能在第三方软件上看到此问题? 您是否能够看到 ptp4l 的相同问题?

    4.我看到在 CPSW CPTS Linux 驱动程序中、似乎已经有 i2401 权  变措施 git.ti.com/.../ 的实现我有点困惑、因为您似乎也在尝试在软件中单独实现权变措施? 您是否已经知道此链接中所做的更改?

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Daolin:

    1. 在 SDK 9.03 和 SDK 11.0 中会发现这些问题。
    2. 我们主要使用定制电路板、但这些问题可以在 EVM 上轻松重现。
    3. 通过运行两个 ptp4l 实例、可以复制多个 PTP 客户端的问题。 其中一个实例永远不会获得时间戳。
    4. 对 i2401 的引用是您链接的更改导致了所有这些问题。 9.00 SDK 及更早版本中不存在上述问题。

    我将编写一些简单的步骤来复制示例输出。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、  

    感谢您解释这些细节。 今天我没有时间进一步研究这个问题。 我将在明天或星期四进行研究。 我计划通过星期四的更新进行回复。 我需要与开发人员联系、开发人员进行了我链接的更改。  

    我将写一些简单的步骤来复制示例输出。

    是的、这将有助于我们重新创建问题。

    如果您没有收到星期四的回复、请 Ping 此主题。

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、  

    与开发人员交谈后、我们得出结论:我们需要先重新创建问题、以便更好地理解此问题。 从开发人员的角度来看、我们以前在没有时间戳的 PTP 数据包中似乎没有遇到过这个问题。  

    如果您能分享、那就好了  

    1.重新创建该问题需要什么样的硬件设置(最好使用 TI EVM)

    2.需要哪些 ptp4l 命令

    3.预期输出是什么,实际观察到的是什么。

    4、任何其他有助于重现此问题的细节

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Daolin:

    我可以通过以下设置重现这些问题:

    1. SK-AM62B EVM 板
    2. 11.01 固件、网址为 https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-BDCgfEXHLk/11.01.05.03/tisdk-default-image-rt-am62xx-evm-11.01.05.03.rootfs.wic.xz
    3. 使用 PTP2 主器件将 eth0 连接到网络。 任何网络配置都可以工作、但我已经有一个具有主时钟的 LLN、所以我使用了它。

    1.设置  HWTSTAMP_FILTER_ALL 失败

    执行以下行

    hwstamp_ctl -i eth0 -r 1

    SDK 09.00.00.10 中显示的预期行为

    current settings:
    tx_type 1
    rx_filter 1
    new settings:
    tx_type 1
    rx_filter 1

    观察到的行为

    current settings:
    tx_type 1
    rx_filter 12
    SIOCSHWTSTAMP failed: Operation not supported

    这是对受支持功能的更改。 现有软件包无法启动、因为需要该软件包可用、即使不需要所有数据包的时间戳。

     

    2.多个 PTP 服务

    我正在制定测试步骤以在 SK 上复制此内容、并在完成后发布。

    3.数据包缺少时间戳

    只需运行 ptp4l 并选择适当的域:

    ptp4l -E -4 -H -i eth0 -s -l 6 -q -m --domainNumber=0

    您会发现、偶尔会有没有时间戳的 DELAY_REQ 投诉

    SDK 09.00.00.10 中显示的预期行为

    ptp4l[1307.950]: master offset        105 s2 freq    +417 path delay      2637
    ptp4l[1308.914]: master offset       -102 s2 freq    +242 path delay      2648
    ptp4l[1309.926]: master offset        -57 s2 freq    +256 path delay      2648
    ptp4l[1310.941]: master offset        108 s2 freq    +404 path delay      2639
    ptp4l[1311.954]: master offset        -92 s2 freq    +236 path delay      2639
    ptp4l[1312.919]: master offset         33 s2 freq    +334 path delay      2612
    ptp4l[1313.932]: master offset         93 s2 freq    +404 path delay      2617
    ptp4l[1314.945]: master offset        -89 s2 freq    +250 path delay      2659
    ptp4l[1315.958]: master offset         16 s2 freq    +328 path delay      2660
    ptp4l[1316.921]: master offset        -67 s2 freq    +250 path delay      2656
    ptp4l[1317.928]: master offset         45 s2 freq    +342 path delay      2656
    ptp4l[1318.941]: master offset        -52 s2 freq    +258 path delay      2677
    ptp4l[1319.949]: master offset         65 s2 freq    +359 path delay      2677
    ptp4l[1320.960]: master offset          5 s2 freq    +319 path delay      2677
    ptp4l[1321.924]: master offset        -90 s2 freq    +225 path delay      2681
    ptp4l[1322.936]: master offset         63 s2 freq    +351 path delay      2681
    ptp4l[1323.949]: master offset         34 s2 freq    +341 path delay      2681
    ptp4l[1324.959]: master offset         -2 s2 freq    +316 path delay      2685
    ptp4l[1325.922]: master offset        -76 s2 freq    +241 path delay      2684
    ptp4l[1326.933]: master offset        105 s2 freq    +399 path delay      2684
    ptp4l[1327.939]: master offset        -91 s2 freq    +235 path delay      2683

    观察到的行为

    ptp4l[62354.761]: master offset        -24 s2 freq   +1052 path delay      2713
    ptp4l[62355.762]: master offset         78 s2 freq   +1147 path delay      2713
    ptp4l[62356.763]: master offset        -30 s2 freq   +1063 path delay      2713
    ptp4l[62357.630]: port 1 (eth0): received DELAY_REQ without timestamp
    ptp4l[62357.763]: master offset         47 s2 freq   +1131 path delay      2715
    ptp4l[62357.784]: port 1 (eth0): received DELAY_REQ without timestamp
    ptp4l[62358.763]: master offset        -86 s2 freq   +1012 path delay      2715
    ptp4l[62359.148]: port 1 (eth0): received DELAY_REQ without timestamp
    ptp4l[62359.764]: master offset        -43 s2 freq   +1029 path delay      2710
    ptp4l[62360.764]: master offset        147 s2 freq   +1206 path delay      2702
    ptp4l[62361.765]: master offset        -58 s2 freq   +1045 path delay      2704
    ptp4l[62362.765]: master offset        -80 s2 freq   +1006 path delay      2704
    ptp4l[62363.766]: master offset         59 s2 freq   +1121 path delay      2706

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    另一个相关问题:

    PTP v1 是否由于硬件时间戳的更改而不再受支持?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、  

    是否由于硬件时间戳更改而不再支持 PTP v1?

    根据 AM62x TRM、列出了 CPTS 以确保符合 IEEE 1588-2008 (PTPv2) 标准。 它没有说 PTPv1 不再受支持、但我的理解是 CPTS 的设计符合 PTPv2。 由于 i2401 勘误表的变通办法、我认为不再支持 PTPv1。

    一个示例。

    12.3.1.4.7 通用平台时间同步 (CPTS)
    通用平台时间同步 (CPTS) 模块用于促进主机对时间同步操作的控制。 很好
    能够符合精密时钟同步协议的 IEEE 1588-2008 标准。

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    3 中的行为没有任何其他先决条件。 它立即发生,你会看到它与我提供的命令.

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、  

    我正在尝试重现问题。 我最初是带有 SDK 11.0 Linux 的 SK-AM62B-P1 EVM、在尝试完全复制所看到的内容时遇到了一些问题、因此我会再次使用最新的 SDK 11.1 刷写 SD 卡。 我会让你知道我明天会发现什么。

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Daolin:

    如果您看到不同的结果、我认为由于 PTP 主站配置和多播客户端数量等外部因素、可能存在一些差异。 我们可以尝试确保 PTP 连接匹配。

    另外、我现在在复制#2 时遇到了问题。 最近、我一直在 09.00.00.010 上工作、为 i2401 添加了补丁、我的原始测试是在 09.03.06 上进行的、所以我将返回该版本收集更多数据。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、

    如果您看到不同的结果、我认为由于 PTP 主配置和多播客户端数量等外部因素、可能会有一些差异。 我们可以尝试确保 PTP 连接匹配。

    我刚才在带 SDK 11.1 的 AM62x EVM 上尝试了几种不同的 PTP 配置。 出于某种原因、我无法获得具有–4 选项(我认为是 UDP IPv4)的 E2E 模式来生成有意义的输出。 但是、当运行具有–2 选项的 E2E 模式(IEEE 802.3 网络传输)时、我没有看到“DELAY_REQ without stamps“消息、但我看到“Received sync without timestamp“(下面的日志未更新以反映这一点)。  

    我看到了 P2P 模式 P 无时间戳的 DELAY_REQ。 我认为这似乎类似于没有时间戳的 DELAY_REQ、但仅适用于 P2P 而不是 E2E。

    总之、我无法完全复制您看到的内容、但我看到类似的消息、如“ P 不带时间戳的 DELAY_REQ 和“不带时间戳的 SYNC “。

    对我来说没有意义的是、如果您执行“ethtool -T eth0“、时间戳功能表明 CPSW 应该能够支持 勘误权变措施 (https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-6.12.y&id=30b3fe0672f2a97f22d96a863f2a8f2ed6c52a54) 中指定的 HWTSTAMP_FILTER_PTP_V2_EVENT  

    虽然我没有更详细地研究它,我的下一个想法是,如果我们可以看到这个 am65_cpts_find_rx_ts() 是否返回任何有用的: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti/am65-cpts.c?id=30b3fe0672f2a97f22d96a863f2a8f2ed6c52a54#n946 

    日志:

    使用 P2P 模式和 gptpt.cfg 的 AM62x 日志: https://gist.github.com/dao-qiu/dd0fb8bba1c3fbbbe9c954ab06c68a1f

    -->能够看到“接收到的无时间戳 PDELAY_REQ“

    使用不带 gptpt.cfg 的 P2P 模式的 AM62x 日志: https://gist.github.com/dao-qiu/5b2dff3c3d9e48540b1fb6ed3fb12e58 

    -->能够看到“接收到的无时间戳 PDELAY_REQ“

    使用 E2E 模式和–2 选项的 AM62x 日志: https://gist.github.com/dao-qiu/9fdd4762199e753b0bf14ddb2da8e3f5

    --> TI 无法在 E2E 模式下复制“received delay_Req without timestamp“

    使用具有–4 选项的 E2E 模式的 AM62x 日志: https://gist.github.com/dao-qiu/6733f62b2c85dc5f36eea7c9057221f3 

    --> TI 无法通过–4 选项看到任何有意义的输出(UDP IPv4 网络传输)

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Daolin:

    您的 IPv4 似乎根本看不到主中继器。 您可以使用“tcpdump -n dst port 319 或 dst port 320“测试 PTP 数据包。

    我对  am65_cpts_find_rx_ts () 进行了如下分析:

    static u64 am65_cpts_get_rx_ts(struct am65_cpts *cpts, struct sk_buff *skb,
    			       u32 skb_mtype_seqid)
    {
       
       ... Existing function contents ...
    
    
        if(ns){
    		dev_warn(cpts->dev, "Return/del TS for %i", skb_mtype_seqid);
        }else{
            dev_warn(cpts->dev, "TS not found for %i", skb_mtype_seqid);
        }
    
    	return ns;
    }
    

    摘录如下:

    Jul 27 14:06:42 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4280036
    Jul 27 14:06:42 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4215398
    Jul 27 14:06:43 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4215399
    Jul 27 14:06:43 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4279609
    Jul 27 14:06:43 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4280037
    Jul 27 14:06:44 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4215400
    Jul 27 14:06:45 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4279610
    Jul 27 14:06:45 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4280038
    Jul 27 14:06:45 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4215401
    Jul 27 14:06:46 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4280039
    Jul 27 14:06:46 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4279611
    Jul 27 14:06:46 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4215402
    Jul 27 14:06:46 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: TS not found for 4279612
    Jul 27 14:06:47 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4280040
    Jul 27 14:06:47 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4215403
    Jul 27 14:06:47 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4279613
    Jul 27 14:06:48 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4280041
    Jul 27 14:06:48 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: TS not found for 4215404
    Jul 27 14:06:49 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4279614
    Jul 27 14:06:49 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4280042
    Jul 27 14:06:49 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4215405
    Jul 27 14:06:50 r2d2 kernel: am65-cpsw-nuss 8000000.ethernet: Return/del TS for 4280043

    因此、至少 80%的数据包似乎成功返回时间戳。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、

    根据 am65_cpts_find_rx_ts () 的发现、可能是每个 PTP 数据包的条件(在下面的链接中)都不正确、您可能也会快速检查。 我计划明天与开发人员会面、以了解此条件声明的含义。

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/blame/drivers/net/ethernet/ti/am65-cpts.c?h=ti-linux-6.12.y&id=30b3fe0672f2a97f22d96a863f2a8f2ed6c52a54#n915 

    您的 IPv4 似乎根本看不到主中继器。 您可以使用“tcpdump -n dst port 319 或 dst port 320“测试 PTP 数据包。

    我意识到我的问题不是设置 IPv4 地址。 设置完成后、我确实会看到同步发生、但我看到的不是“delay_Req without timestamp“、而是“sync without timestamp“。 虽然与您所看到的不完全相同、由于 DELAY_REQ 和 SYNC 都是 PTP 报文、我认为问题的根源仍然是一些 PTP 报文不会像您所指出的那样接收时间戳。

    实际上、过去我看到同步消息存在此问题、尽管使用的测试设置不同、涉及连接和配置的 3 块板、例如: EVM1(从器件)eth0<>eth0 EVM2(主器件)eth1<>eth0 EVM3(从器件)、设置 EVM2 eth0、eth1 作为开关。  

    root@am62xx-evm:~# ifconfig eth0
    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet6 fe80::1e63:49ff:fe0f:61eb prefixlen 64 scopeid 0x20<link>
        ether 1c:63:49:0f:61:eb txqueuelen 1000 (Ethernet)
        RX packets 202930 bytes 14014449 (13.3 MiB)
        RX errors 0 dropped 57976 overruns 0 frame 0
        TX packets 59280 bytes 4029835 (3.8 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    
    root@am62xx-evm:~# ip addr add 192.168.1.10/24 dev eth0
    root@am62xx-evm:~# ifconfig eth0
    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 192.168.1.10 netmask 255.255.255.0 broadcast 0.0.0.0
        inet6 fe80::1e63:49ff:fe0f:61eb prefixlen 64 scopeid 0x20<link>
        ether 1c:63:49:0f:61:eb txqueuelen 1000 (Ethernet)
        RX packets 202938 bytes 14016223 (13.3 MiB)
        RX errors 0 dropped 57976 overruns 0 frame 0
        TX packets 59290 bytes 4031978 (3.8 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
    
    root@am62xx-evm:~# ping 192.168.1.11
    PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
    64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.566 ms
    64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.365 ms
    ^C
    --- 192.168.1.11 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1053ms
    rtt min/avg/max/mdev = 0.365/0.465/0.566/0.100 ms
    root@am62xx-evm:~# 
    root@am62xx-evm:~# 
    root@am62xx-evm:~# 
    root@am62xx-evm:~# 
    root@am62xx-evm:~# ptp4l -E -4 -H -i eth0 -s -l 6 -q -m --domainNumber=0  
    ptp4l[59806.199]: selected /dev/ptp0 as PTP clock
    ptp4l[59806.206]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[59806.207]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[59806.207]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[59807.379]: port 1 (eth0): new foreign master 3408e1.fffe.80a7ad-1
    ptp4l[59811.379]: selected best master clock 3408e1.fffe.80a7ad
    ptp4l[59811.379]: port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE
    ptp4l[59814.379]: master offset   -1763 s0 freq -18112 path delay    417
    ptp4l[59815.379]: master offset   -1793 s2 freq -18142 path delay    417
    ptp4l[59815.380]: port 1 (eth0): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
    ptp4l[59816.379]: master offset   -1792 s2 freq -19934 path delay    414
    ptp4l[59817.380]: master offset     0 s2 freq -18680 path delay    412
    ptp4l[59818.380]: master offset    533 s2 freq -18147 path delay    412
    ptp4l[59819.380]: master offset    522 s2 freq -17998 path delay    413
    ptp4l[59820.380]: master offset    365 s2 freq -17998 path delay    414
    ptp4l[59821.380]: master offset    201 s2 freq -18053 path delay    417
    ptp4l[59822.380]: master offset     96 s2 freq -18098 path delay    417
    ptp4l[59823.380]: master offset     29 s2 freq -18136 path delay    417
    ptp4l[59824.380]: master offset     2 s2 freq -18154 path delay    415
    ptp4l[59825.380]: master offset    -13 s2 freq -18169 path delay    417
    ptp4l[59826.380]: master offset    -14 s2 freq -18173 path delay    417
    ptp4l[59827.380]: master offset    -10 s2 freq -18174 path delay    417
    ptp4l[59828.381]: master offset     -9 s2 freq -18176 path delay    417
    ptp4l[59829.381]: master offset     -4 s2 freq -18173 path delay    414
    ptp4l[59830.381]: master offset     -3 s2 freq -18174 path delay    414
    ptp4l[59831.381]: port 1 (eth0): received SYNC without timestamp
    ptp4l[59832.381]: master offset     7 s2 freq -18164 path delay    410
    ptp4l[59833.381]: master offset     7 s2 freq -18162 path delay    410
    ptp4l[59834.381]: master offset     4 s2 freq -18163 path delay    409
    ptp4l[59835.381]: master offset     2 s2 freq -18164 path delay    410
    ptp4l[59836.381]: master offset     0 s2 freq -18165 path delay    410
    ptp4l[59837.381]: master offset     -1 s2 freq -18166 path delay    410
    ptp4l[59838.381]: master offset     -7 s2 freq -18173 path delay    410
    ptp4l[59839.381]: master offset     3 s2 freq -18165 path delay    410
    ptp4l[59840.381]: master offset     1 s2 freq -18166 path delay    410
    ptp4l[59841.382]: master offset     4 s2 freq -18163 path delay    410
    ptp4l[59842.382]: master offset     3 s2 freq -18162 path delay    410
    ptp4l[59843.382]: master offset     9 s2 freq -18156 path delay    410
    ptp4l[59844.382]: master offset     7 s2 freq -18155 path delay    411
    ptp4l[59845.382]: master offset     9 s2 freq -18151 path delay    410
    ptp4l[59846.382]: master offset     7 s2 freq -18150 path delay    410
    ptp4l[59847.382]: master offset     8 s2 freq -18147 path delay    411
    ptp4l[59848.382]: master offset     3 s2 freq -18150 path delay    411
    ptp4l[59849.382]: master offset     3 s2 freq -18149 path delay    411
    ptp4l[59850.382]: master offset     0 s2 freq -18151 path delay    411
    ptp4l[59851.382]: master offset     2 s2 freq -18149 path delay    411
    ptp4l[59852.383]: master offset     2 s2 freq -18148 path delay    411
    ptp4l[59853.383]: master offset     4 s2 freq -18146 path delay    411
    ptp4l[59854.383]: master offset     3 s2 freq -18145 path delay    411
    ptp4l[59855.383]: master offset     -2 s2 freq -18149 path delay    411
    ptp4l[59856.383]: master offset     -3 s2 freq -18151 path delay    411
    ptp4l[59857.383]: master offset     -2 s2 freq -18151 path delay    411
    ptp4l[59858.383]: master offset     -1 s2 freq -18151 path delay    411
    ptp4l[59859.383]: master offset     3 s2 freq -18147 path delay    411
    ptp4l[59860.383]: port 1 (eth0): received SYNC without timestamp
    ptp4l[59861.383]: master offset     5 s2 freq -18144 path delay    410
    ptp4l[59862.383]: master offset     6 s2 freq -18141 path delay    410
    ptp4l[59863.383]: master offset     7 s2 freq -18139 path delay    410
    ptp4l[59864.384]: master offset     2 s2 freq -18142 path delay    410
    ptp4l[59865.384]: master offset     3 s2 freq -18140 path delay    410
    ptp4l[59866.384]: master offset     4 s2 freq -18138 path delay    410
    ptp4l[59867.384]: master offset     4 s2 freq -18137 path delay    410
    ptp4l[59868.384]: master offset     4 s2 freq -18136 path delay    410
    ptp4l[59869.384]: master offset     3 s2 freq -18135 path delay    410
    ptp4l[59870.384]: master offset     4 s2 freq -18134 path delay    410

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    今天的小幅更新:

    首先、我在从原始帖子复制问题 2 时遇到问题。 我想我可能被一系列没有时间戳的数据包所迷惑、并假定没有数据包通过时间戳进入第二个 PTP 服务。 当我启动和停止第二个服务时,我最初还看到第一个服务上缺少时间戳的数量发生了变化。 我不再看到这种行为。

    其次、通过一些附加的工具、我显示当  am65_cpts_find_rx_ts() 不返回时间戳时、列表 &cpts->events 为空(或所有事件都已超时)、因为与  skb_mtype_seqid 的比较从未执行。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、  

    感谢您的更新。 在与开发人员交谈后、我们想确定在其他 AM6x 器件上是否也出现了此问题、或者是否仅在 AM62x 上出现此问题。 重点是缩小问题是否真正与软件驱动程序有关、或者是否与硬件有关。 结束这次对话后、我在 AM62Px 上作为 PTP 跟随者进行了测试、发现即使在大约 3 分钟的运行时间后、也不会出现“无时间戳“消息。 我已经确认 AM62Px 也存在 i2401 勘误表;CPSW CPTS 驱动器中实现的权变措施也应该与 AM62x 相同。  

    第二、通过一些附加工具、我发现当  am65_cpts_find_rx_ts() 不返回时间戳时、列表 &cpts->events 为空(或所有事件都已超时) 、因为与 skb_mtype_seqid 的比较从未执行。

    您是否专门引用了关于&CPT->事件的此行?  https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/blame/drivers/net/ethernet/ti/am65-cpts.c?h=ti-linux-6.12.y&id=30b3fe0672f2a97f22d96a863f2a8f2ed6c52a54#n903 

    感谢您指出这一点。 开发人员认为问题仅与 AM62x 有关、这意味着问题可能特定于硬件、因此我来找出下一步是什么、明天再联系您。

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    其他仪器会产生一些有趣的结果。 请注意、对日志记录系统的调用将更改时序并可能影响系统行为。

    Aug 05 13:15:02.102953 r2d2 kernel: TS Q->L 0040d686, 4295050901
    Aug 05 13:15:02.115171 r2d2 ptp4l[1087]: [634.434] port 1 (eth0): received SYNC without timestamp
    Aug 05 13:15:02.168280 r2d2 kernel: TS missing 0040d686, 4295050901

    这些行显示:

    1. am65_cpts_fifo_read() 在  event->list 中将 mtype_seqid=0040d686 的时间戳放置在 jiffies=4295050901 处
    2. ptp4l 报告缺少时间戳
    3. am65_cpts_get_rx_ts() 在 event->list 中未对 mtype_seqid=0040d686 的时间戳进行微调、jiffies=4295050901

    这表示:

    • am65_cpts_get_rx_ts() 调用 am65_cpts_fifo_read()  并且立即找不到刚刚添加到列表中的项目
    • am65_cpts_get_rx_ts() 找不到该项、随后对 am65_cpts_fifo_read() 的中断调用会将其添加到列表中

    第二个似乎不太可能,因为两个事件具有相同的值的 jiffies。 我将进一步调查、以确定何时从列表中删除时间戳、并更好地识别事件序列。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、  

    我将进一步调查、以确定时间戳何时从列表中删除、并更好地识别事件的顺序。

    感谢您对所发现内容的更新。 了解导致删除时间戳的事件序列也有助于我们了解、如果存在一些底层硬件问题、权变措施的软件实现是否真的出了问题(因为对于使用相同 CPSW 驱动程序且具有相同 i2401 勘误表的 AM62Px 而言,此问题似乎未显示)。  

    -道林

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我想我已经找到了一个解析在下面的补丁中丢失的时间戳:

    diff --git a/drivers/net/ethernet/ti/am65-cpts.c b/drivers/net/ethernet/ti/am65-cpts.c
    index 29e0b9ff23bf..cd78519676ab 100644
    --- a/drivers/net/ethernet/ti/am65-cpts.c
    +++ b/drivers/net/ethernet/ti/am65-cpts.c
    @@ -826,7 +826,6 @@ static void am65_cpts_find_ts(struct am65_cpts *cpts)
     
     	spin_lock_irqsave(&cpts->lock, flags);
     	list_splice_init(&cpts->events, &events);
    -	spin_unlock_irqrestore(&cpts->lock, flags);
     
     	list_for_each_safe(this, next, &events) {
     		event = list_entry(this, struct am65_cpts_event, list);
    @@ -837,7 +836,6 @@ static void am65_cpts_find_ts(struct am65_cpts *cpts)
     		}
     	}
     
    -	spin_lock_irqsave(&cpts->lock, flags);
     	list_splice_tail(&events, &cpts->events);
     	list_splice_tail(&events_free, &cpts->pool);
     	spin_unlock_irqrestore(&cpts->lock, flags);
    

    之前未受 spinlock 保护的中间部分将编辑列表。 当与其他功能同时运行时、这显然会干扰列表搜索。 这是不受 spinlock 保护的事件列表的唯一用法。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Matthew、  

    对延迟响应表示歉意。

    之前不受 spinlock 保护的中间部分编辑列表。 当与其他功能同时运行时、这显然会干扰列表搜索。 这是不受 spinlock 保护的事件列表的唯一用法。

    感谢您分享此解决方案。 我使用 AM62x 作为 PTP 跟随者、在几种不同的 PTP 配置上测试了您的补丁、我不再看到“无时间戳“消息。 我将在内部与开发人员讨论、看看这是否是我们可以集成的解决方案作为修复。  

    -道林