• 状态 Resolved
  • 已锁定 已锁定
  • 回复 37 回复
  • 订户 0 订户
  • 视图 54 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] AM3357：基于 AM3357 的定制板上的 PTP 同步失败

admin
Guru**** 2893300 points

Other Parts Discussed in Thread: AM3357

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1601282/am3357-ptp-synchronization-failure-on-am3357-based-custom-board

器件型号： AM3357

我在基于 AM3357 处理器的定制电路板上遇到 IEEE 1588 PTP 同步问题。 该系统配置有一个用作 PTP 主时钟的外部主时钟、而定制电路板用作 PTP 从时钟。 PTP 支持所需的所有内核配置和驱动程序选项均已启用。 我评估了硬件时间戳（基于 MAC/PHY）和软件时间戳模式；但是、在这两种情况下、从节点都无法实现与主时钟的同步。

我正在使用的.cfg 文件如下：

image.png

以下日志是在测试期间捕获的、在硬件和软件时间戳模式下是相同的。

image.png

以下是主时钟的设置：

image.png

感谢 TI 的技术支持帮助我调试此问题并在 AM3357 平台上实现正确的 PTP 运行。

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

    嗨、pooja、

    我们的专家不在办公室、请期待回复延迟。

    此致、

    Dilna K

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

    您好：

    我可以获得有关此问题的任何更新吗？

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

    您好、

    线程所有者将在 2 月 17 日的一周内停止工作。 如果您在这周内没有收到更新、请 ping 通该线程。

    感谢您的耐心。

    此致、
    Harshith

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

    您好：

    我可以获得有关此问题的任何更新吗？

    此致、

    Pooja.

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

    你好 Pooja,

    对此处的延迟深表歉意。 我终于回到办公室了。

    您在 AM335x 上运行的是哪个版本的 Linux？ 请注意、在 AM335x Linux SDK 9.1 或 9.3 (Linux 内核 6.1) 上、我们不支持 PRU 以太网

    我将能够在最新的 AM335x Linux SDK 11.2 (Linux 内核 6.12) 上提供 PRU 以太网支持。 您可以在 Foundational_Components Linux_Drivers 的以下文档中找到更多文档：https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/SDK/PRU-ICSS/PRU-ICSS/Linux/ PRU-ICSS_Ethernet.html

    如果您使用的是较旧的 Linux SDK 版本、我仍然会尝试发表评论、但 Linux 内核 5.10 和更早版本现在太旧了、我们无法在论坛上提供支持。

    此致、

    Nick

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

    您好、Nick、

    目前、我正在使用 SDK 6.3 (Linux 内核 4.19) 、并计划迁移到 SDK 11.02（内核 6.1）。

    在 SDK 6.3 中 ethtool -T eth1、当运行时、软件时间戳功能列为受支持。 但是、当我尝试使用软件时间戳时、同步失败、无法按预期工作。

    在 SDK 11.02tisdk-default-image-am335x-evm-11.02.05.02.rootfs.wic.xz() 中、运行 ethtool -T eth1 显示不支持软件时间戳。

    对于定制电路板、我 只需要软件时间戳。

    我想了解：

    1. 需要在 SDK 11.02（内核 6.1）中进行哪些更改才能启用软件时间戳支持？

    2. 为什么在 SDK 6.3（内核 4.19）中软件时间戳在中显示为支持时仍然失败 ethtool？

    此致、

    Pooja.  

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

    你好 Pooja,

    为了进行说明、SDK 11.2 使用 Linux 内核 6.12、而不是 Linux 内核 6.1。 PRU 以太网在 Linux 内核 6.1 上不起作用。

    我们来谈谈软件时间戳和硬件时间戳  

    为什么您特别需要软件时间戳而不是硬件时间戳？ 硬件时间戳处理始终会为您提供更准确的结果、它在 CPSW（通过 CPTS 模块）和 PRU 子系统（通过 IEP 计时器）中提供。

    当在处理器引脚上接收到以太网数据包时、它会被读取到以太网外设（CPSW 或 PRU 以太网）中。 如果使用硬件时间戳、则会立即为数据包添加时间戳。 无延迟、无抖动。 这在与 PTP 主设备通信时应始终提供最佳结果。

    接收到数据包后、CPSW 外设或 PRU 内核将以太网数据包传递到网络协议栈。 如果您使用软件时间戳、则在 Linux ARM 内核上运行的网络栈是为数据包设置时间戳的栈。 由于您无法精确控制 Linux 何时调度网络堆栈在 ARM 内核上运行、因此您无法精确控制软件时间戳发生的时间。 因此、从数据包实际到达处理器引脚开始、您的时间戳值将具有未知的延迟。 我还希望延迟值  从一个时间戳到下一个时间戳具有更多的抖动、因为从数据包加载到供 Linux 使用的 FIFO 与 Linux 实际切换上下文以使用上下文之间的时间间隔将不同。

    此致、

    Nick

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

    您好、Nick、

    软件时间戳是我们产品的一项要求、这也是我们使用软件时间戳的原因。 但是、该软件在 SDK 11.2（内核 V6.12）中似乎不可用。 您能就此为我们提供帮助吗？

    此致、

    Pooja.

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

    你好 Pooja,

    现在、我们忽略硬件时间戳/软件时间戳区分

    我认为我们遇到了通信问题。  Linux 关心的都是为 PTP 生成时间戳。 Linux 不关心时间戳是来自 CPTS 还是 IEP 计数器的非常精确的时间戳、还是 Linux 驱动程序的不太精确的时间戳。 Linux 中的软件时间戳设计为备份、仅在处理器没有更准确的硬件时间戳源时使用。 如果您的产品特别需要您使用不太准确的时间戳,我会非常惊讶。

    首先、 您使用的是哪种以太网接口？  

    您是否使用 CPSW 或 PRU 以太网？

    其次、 请提供失败测试的完整引导日志、以及通过测试的完整引导日志

    还请分享：

    1) 在引导日志中包括诸如“uname -A“的信息,以确认您用于测试用例的 Linux 版本

    2) 用于测试的 oc.cfg 文件

    此致、

    Nick

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

    您好、Nick、

    据我所知、在 PRU 子系统中 、IEP 计时器处理硬件时间戳、因此不需要额外的硬件。 如果我弄错了、请纠正我。

    我们已 将 PRU-ICSS 配置为使用 PRUHSR。  但是、我们在添加 PTP 支持时遇到问题。

    您能否阐明固件是否 am335x-pru0-pruhsr-fw.elf am335x-pru1-pruhsr-fw.elf 为数据包生成时间戳？

    此致、

    Pooja Nagda.

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

    您好、Nick、

    root@am335x-EVM：~# uname -A
    Linux AM335x-EVM 6.12.49-ti-g1a86d36433ea #1 SMP 抢占周五 11 月 14 日 06：06：38 UTC 2025 armv7l GNU/Linux

    请查找日志：

    dmesg.txt

    PTP_software_timestamp.txt

    PTP_hardware_timestamp.txt

    ptp_slave.txt

    此致、

    Pooja Nagda.   

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

    你好 Pooja,

    感谢您附加日志。 请给我几天时间与开发人员联系。 如果我在下周中没有回复、请 ping 通该线程。

    此致、

    Nick

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

    来自开发团队的反馈

    是的。 PTP HSR RED-OC+PTP TC 和 PTP PRP RED-OC 在 AM335x 上进行了测试、其功能与 6.3 SDK 类似。  存在一个 SDK 打包错误 — ptp4l 版本 4.1 与 SDK 11.2 打包、该 SDK 11.2 不支持 HSR/PRP 冗余。 用户必须重新编译并使用以下分支中的 ptp4l：[TI-linuxptp-v0.3-am57xx-bc](https://git.ti.com/cgit/processor-sdk/linuxptp/log/?h=ti-linuxptp-v0.3-am57xx-bc)。

     正确的 ptp4l 版本为：

    root@am335x-evm：~/scripts ti_am335n#./ptp4l -v3.0-00212-g82a7888-dirty

    可在以下位置找到示例 ptp4l 配置文件：https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/ptppt.html#redundancy-hsr-prp“ Industrial_Protocols_

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

    感谢您的更新。 TI 是否有计划修复 SDK11 封装错误以包含 ti-linuxptp-v0.3-am57xx-bc？

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

    我们尝试了该版本、但它在采用 HSR 硬件卸载+ PTP 的 ICEv2 EVM 上无法正常工作。

    请参阅  AM3359 中的日志：每个 Linux SDK 上的 PRU 以太网支持 

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

    您好、Nick、

    请提供更新。 我们尝试了开发团队建议的版本、但它不适用于采用 HSR 硬件卸载+ PTP 的 ICEv2 EVM。

    此致、

    Pooja Nagda.

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

    您好 Pratheesh、

    我们使用两个 AM335x ICEv2 EVM 尝试了上述设置、并注意到 ptp4l 版本存在差异。 您使用的版本是 v3.0-00212-g82a7888-dirty、而在我们的 EVM 上、版本是 v3.0-00212-g82a7888。 这种差异能否成为 PTP 不能为我们服务的原因？

    请检查随附的日志。

    PTP_master_logs.txt

    PTP_slave_logs.txt

    此致、

    Pooja Nagda.

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

    嗨、Pooja、  

    ptp4l 版本的差异（显示“脏“后缀）归因于为交叉编译而对 Makefile 进行的修改。 这些局部更改会导致版本字符串中出现“dirty“指定。 我附加了 ptp4l 二进制文件以供您参考。

    要进一步解决此问题、您能否执行以下步骤并与我们分享结果：

    • 捕获主机流量：请使用以下命令从 HSR 接口捕获主机流量： 
      • tcpdump -i hsr0
    • 如果可行、还请直接从网线捕获数据包（使用网络分路器）、以分析实际的 PTP 报文流。
    • 我提供了我们编译的 ptp4l 版本供您测试。 此外、您能否分享您当前的 ptp4l 二进制文件、以便我们可以检查它是否存在任何差异或问题？
    • 接口时间戳添加：请在每个网络接口上运行以下命令以验证时间戳支持 
      • ethtool -T hsr0

    e2e.ti.com/.../ptp4l

    BR
    Jc.

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

    尊敬的 Jayachandra：

    您能否将您的本地更改（“脏“后缀）推送到 https://git.ti.com/cgit/processor-sdk/linuxptp 、以便我们可以在最终阶段再次使用 Yocto 进行编译和验证？

    BR/Chencheng

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

    您好 Jayachandran、

    正如晨成前面提到的、您能否推送本地更改（“脏“后缀）、以便我们在结束时验证它们？

    此致、

    Pooja Nagda.

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

    嗨、Pooja、

    显示为“rty“的 ptp4l 版本是因为我们修改了 Makefile 以启用交叉编译。 此本地修改会导致版本被标记为 Dirty。

    问题：Makefile 中是否需要进行交叉编译更改？

    替代方法：您仍然可以通过克隆存储库并直接在 DUT 内运行 ptp4l make install 来执行本机编译。

    BR
    Jc.

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

    尊敬的 Jayachandran：

    由于我们在 x86 上运行 Yocto、因此确实需要交叉编译。

    您能否在交叉编译更改时提供 git commit 或补丁？

    提前感谢！

    BR/Chencheng

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

    我们   在这里使用这个交叉编译器是 Makefile 补丁

    e2e.ti.com/.../cross_5F00_compiler_5F00_for_5F00_ptp.patch

    BR
    Jc.

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

    好的、感谢您提供了补丁。 这似乎是不 relavate 的。

    只是为了再次确认,您正在使用的版本是 COMMIT 82a78889f84830aaafdece92432b26203aec21d4 是正确的?

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

    尊敬的 Chencheng：  

    是的、这是正确的 SHA

    BR
    Jc.

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

    再次大家好、

    之前、我们在此处遇到日志问题：

     关于：AM3359：每个 Linux SDK 支持 PRU 以太网 

    现在、 我认为  linuxptp/PRUSS-FW/TI-kernel 存在 Y2038 问题。


    它与 Y2038（2038 年）兼容性标志 转换 `struct timespec` 从 32 位时间转换为 32 位架构 (ARMv7) 上的 64 位时间表示相关、与自定义 TI 内核/PRUSS-FW ioctl/CMSG API 冲突。

    以下是为什么问题发生在 Yocto Scarthgap 工具链上但不在 EVM 上本地的具体技术细分。

    ### 1. 根本原因： `_TIME_BITS=64`


    在 Yocto Y2038（使用 glibc 2.39+的 Scarthgap）中、大多数软件包都是使用 μ`TARGET_CFLAGS`进行全局编译 的、其中包含：
    `-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64`μ s

    该标志将 userspace `time_t`的大小 从 32 位整数更改为 64 位整数、因此它将 `struct timespec` 从 8 字节扩展到 16 字节。

    在标准 ICEv2 EVM 基础系统上进行本地构建时、很可能会回到默认的旧 `_TIME_BITS=32`μ s、其中 `struct timespec` 为 8 字节。

    ### 2. `SO_RED_TIMESTAMPING`的 API 细分

    在 `linuxptp` `sk_red_receive()`中、处理 HSR PTP 时间同步的函数 以 μ `sk.c` s 为单位。 当内核套接字传递消息事件时、它包含一个冗余时间戳控制消息 (`SO_RED_TIMESTAMPING`)、这是一个树外 Texas Instruments 自定义内核扩展。

    在 `sk.c`μ s 内、该函数显式检查返回的硬件时间戳的大小：

    ```c
    // sk.c : sk_red_receive()
    if (SOL_SOCKET == level && SO_RED_TIMESTAMPING == type) {
    if (cm->cmsg_len < sizeof(*rts) * 3) {
    pr_warning("short SO_TIMESTAMPING message");
    return -1;
    }
    rts = (struct timespec *) CMSG_DATA(cm);
    }
    ```μ s

    **在 Yocto 下（64 位时间）**：
    `rts` 计算为三个 _64-Bit_ `struct timespec`s 的数组。
    计算： `3 * 16 字节= 48 字节`。

    **TI 内核驱动程序**：
    因为 `SO_RED_TIMESTAMPING` （自定义 ID 81）不是标准化上游、所以通用内核套接字层和 glibc 对它有**无知识**。 `SO_TIMESTAMPING_NEW/SO_TIMESTAMPING_OLD`电容器不会像通常针对 Δ R 那样消除结构差异。 请参阅[Linux时间戳]。 因此、TI 内核模块直接注入传统的 32 位结构数组、权重总计 `3 * 8 字节= 24 字节`μ s。

    `cmsg_len` 计算结果为 24 字节（加上标头开销）。 `sk_red_receive` 需要 48 字节。
    `` 24 < 48 ̊ C、则检查失败、打印：
    ```μ s
    33: ptp4l[99.031]: short SO_TIMESTAMPING message
    ```μ s

    ###3. 级联故障

    `sk_red_receive()` `return -1`μ s 达到 `port_recv()`μ s、因此根 PTP 任务 `port.c`（以 μ s 为单位）会收到错误和日志：
    ```μ s
    34: ptp4l[99.032]: port 1: recv message failed
    ```μ s

    由于冗余链路端口无法正确解析其时间戳有效载荷、因此内部冗余回退状态会超出范围、打印：
    ```μ s
    35: ptp4l[99.032]: hsr0: No red dispatch port
    ```μ s

    ###临时解决方法

    `SO_RED_TIMESTAMPING`自定义 TI 内核模块只知道如何以 μ s为单位谈论 32 位时序、因此我们 **必须** `linuxptp` 使用 32 位时间表示进行编译 μ s、以强制用户空间和内核空间之间的 ABI 兼容性。 因此、 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 编译 linuxptp 的 TI fork 时、我们必须完全删除``。

    但是、这不是一个长期解决方案。 因为 32 位时序 在 Y2038 之后不起作用。 我认为 TI 应 更新 linuxptp/TI-kernel/PRUSS-FW、以在所有 32 位 SoC（如 AM335x）上支持 64 位时序。
  • 0
    TI__Guru**** 2893300 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、

    但是、这不是一个长期的解决方案。 因为 32 位时序 在 Y2038 之后不起作用。 我认为 TI 应 更新 linuxptp/TI-kernel/PRUSS-FW、以在所有 32 位 SoC（如 AM335x）上支持 64 位时序。

    PRUSS FW (PRUICSS)->向 TI PRUSS 驱动程序提供了带翻转计数器的 IEP 时间戳=>无需更改

    PRUSS 驱动程序 (ARM)->将上述 IEP 时间戳转换为 64 位 time_struct - 48 位 secs 和 32 位 ns =>无需更改

    TI-kernel ->需要检查

    LinuxPTP ->需要检查

    我们将检查 TI-kernel/LinuxPTP 和恢复。

    BR
    Jc.

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

    我得到了同行团队的回应。 自 9.x SDK 以来、“Core“内核中修复了 Y2038 问题  

    请参阅 https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/09_03_05_02/exports/docs/linux/How_to_Guides/Target/How_to_fix_y2k38.html

    9.x 中的文件系统“不“符合相同的要求（内核 Yocto 问题）。 因此、建议使用 11.x SDK、其对所有这些都具有 Yocto。 https://www.ti.com/tool/PROCESSOR-SDK-AM335X

    正在使用哪个 SDK？ 您能试用 11.x SDK 吗？

    BR
    Jc.

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

    我们使用的是 TI 官方 meta-ti BSP 标签层 11.02.12

    https://git.yoctoproject.org/meta-ti/tag/?h=11.02.12

    如果您不知道如何使用 Yocto、可以使用您拥有的 TI SDK（高于 9.x）在 ICEv2 EVM    上运行、并在 EVM 上对 git.ti.com/.../linuxptp 进行本机编译、但只需添加编译标志`-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64`、就 会看到错误short SO_TIMESTAMPING message““及其所有级联错误。

    BR/Chencheng

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

    我们能够在 HSR 中重现该问题。 此修复方法仅适用于 HSR PTP 路径。 PRP-PTP 和 EMAC-PTP 不受影响、不需要任何更改。

    应用以下修复程序、重建 6.12 内核、然后重新测试 PTP — 此更改就位后，问题不再出现。  

    注意：这与 Y2038 无关。 这是一个处理 GAP、其中 64 位时间结构未在内核内的 HSR 代码路径中使用。

    确保使用以下编译器标志构建 PTP4L：

    D_TIME_bits=64
    D_file_offset_bits=64

    net/socket.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/socket.c b/net/socket.c
index 82fa17931..9f530fe23 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1003,7 +1003,11 @@ void __sock_recv_redinfo_timestamp(struct msghdr *msg, struct sock *sk,
         empty = 0;
 
     if (!empty) {
-        struct scm_timestamping tss1;
+        /* 
+         * If ptp application is build with 64 bit TIME_BITS and FILE_OFFSET_BITS 
+         * In order to support y2k38 rollover 64 bit secs and nsecs timestamps will be required
+         */
+        struct scm_timestamping64 tss1;
         int i;
 
         for (i = 0; i < ARRAY_SIZE(tss.ts); i++) {

    BR
    Jc.

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

    谢谢 JC。 我将生成一个构建文件并进行验证。

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

    您好：

    我当前在同步系统时钟时遇到 PTP 问题CLOCK_REALTIME()。

    ptp4l 进程成功锁定到主 (GM) 时钟。 当我使用检查 PHC 时间时 phc_ctl /dev/ptp0 get、它将返回正确的时间。

    但是、当尝试使用以下命令同步系统时钟时：
    phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 0 -m
    报告的偏移量非常大。

    这表明 CLOCK_REALTIME 没有更新 Thu Jan 1 00:00:24 1970,并保持在,这解释了大约 56 年的大偏移。

    作为故障排除步骤、我使用 date 命令手动设置系统时间、使其更接近报告的时间 phc_ctl。 尽管如此、所报告的偏移量 phc2sys 仍然很高。

    PTP_GM_logs.txt

    PHC2SYS_CLOCK_REALTIME.txt

    pmc -u -b 0 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
063a33.fffe.fec2f3-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 11
ingress_time 1776859953134749050
*** +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity 502df4.fffe.3a5df2

    pmc -u -b 0 "GET CLOCK_DESCRIPTION"

sending: GET CLOCK_DESCRIPTION
        063a33.fffe.fec2f3-1 seq 0 RESPONSE MANAGEMENT CLOCK_DESCRIPTION 
                clockType             0x8000
                physicalLayerProtocol IEEE 802.3
                physicalAddress       06:3a:33:fe:c2:f3
                protocolAddress       3 06:3a:33:fe:c2:f3
                manufacturerId        00:00:00
                productDescription    ;;
                revisionData          ;;
                userDescription       
                profileId             00:1b:19:00:02:00
        063a33.fffe.fec2f3-2 seq 0 RESPONSE MANAGEMENT CLOCK_DESCRIPTION 
                clockType             0x8000
                physicalLayerProtocol IEEE 802.3
                physicalAddress       00:00:00:00:00:00
                protocolAddress       3 00:00:00:00:00:00
                manufacturerId        00:00:00
                productDescription    ;;
                revisionData          ;;
                userDescription       
                profileId             00:1b:19:00:02:00
        063a33.fffe.fec2f3-3 seq 0 RESPONSE MANAGEMENT CLOCK_DESCRIPTION 
                clockType             0x8000
                physicalLayerProtocol IEEE 802.3
                physicalAddress       00:00:00:00:00:00
                protocolAddress       3 00:00:00:00:00:00
                manufacturerId        00:00:00
                productDescription    ;;
                revisionData          ;;
                userDescription       
                profileId             00:1b:19:00:02:00

    此致、

    Pooja Nagda.

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

    嗨、Pooja、  

    我们正在研究它、一旦我有更新、我将回复您。  

    BR
    Jc.

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

    您好 Jayachandran、

    您的终端是否有任何更新？

    此致、

    Pooja Nagda.

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

    嗨、Pooja、

    我们已确认 git.ti.com 的 TI LinuxPTP 2.0 正常工作。

    但是、我们仍然需要确定它在 当前分支上失败的原因。 在我们对根本原因进行故障排除时、我将提供更新信息。

    BR
    Jc.

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

    该问题的根本原因在于 phc2sys 使用 gettimex64 发出请求时如何随 IEP 时间戳读取系统时间。

    背景：

    • SYSOFF_BASIC 和 SYSOFF_EXTENDED 是两种不同的偏移同步模式。
    • SYSOFF_EXTENDED 期望在读取 IEP/PHC 时间之前和之后捕获系统时间、然后使用这两个读数的平均值作为 phc2sys 中的偏移量。
    • 在较旧的 6.3 SDK 中、内核和 PTPv2 都不支持 SYSOFF_EXTENDED—它始终作为 SYSOFF_BASIC 进行处理。

    问题：
    在采用 PTPv3 的较新 SDK 内核中、支持多种偏移方法 、并在不同层中引入了相应的 API 更改 — 从而暴露了这种差距。

    diff --git a/drivers/net/ethernet/ti/icssg/icss_iep.c b/drivers/net/ethernet/ti/icssg/icss_iep.c
index a09a2797d..168d447fc 100644
--- a/drivers/net/ethernet/ti/icssg/icss_iep.c
+++ b/drivers/net/ethernet/ti/icssg/icss_iep.c
@@ -383,7 +383,13 @@ static int icss_iep_ptp_gettimeex_v1(struct ptp_clock_info *ptp,
     u64 ns;
 
     mutex_lock(&iep->ptp_clk_mutex);
+    /*populate the pre and post IEP/PHC read system timestamp into sts struct*/
+    ptp_read_system_prets(sts);
+
     ns = timecounter_read(&iep->tc);
+
+    ptp_read_system_postts(sts);
+
     *ts = ns_to_timespec64(ns);
     mutex_unlock(&iep->ptp_clk_mutex);

    修补后、重新编译内核。 PTP4L 纸叠没有变化。

    BR
    Jc.

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

    谢谢 JC。 我将生成一个构建文件并进行验证。