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.

[参考译文] AM3359:每个 Linux SDK 支持 PRU 以太网

Guru**** 2826755 points

Other Parts Discussed in Thread: AM3359

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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1621689/am3359-support-for-pru-ethernet-on-each-linux-sdk

《Thread 中讨论的其他器件:AM3359》

您好、Nick 和 Chander、

您能否说明这些更改是否正确?

https://github.com/TexasInstruments/processor-sdk-doc/commit/d41f1430cd3ee2a06dfaf8bfa5db94ca3ddc2ac1

Descope PRU-ICSS Ethernet for AM335x and AM437x
Descope PRU-ICSS Ethernet for AM335x and AM437x by removing all the
documentation related to PRU-ICSS ethernet on these platforms.

Fixes: LCPD-37129
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>

https://github.com/TexasInstruments/processor-sdk-doc/commit/d2ef813bd8160c4a6b9984dd67577acbbaf835a9

PRU-ICSS: Remove HSR/PRP support from AM3/AM4
HSR/PRP with PRU-ICSS offload was descoped for AM335x & AM437x starting in Linux
Processor SDK 7.3 as per SITREQ-141. However, the Linux SDK 7.3 documentation
was not updated.

This commit adds HSR/PRP descope to the AM335x & AM437x release notes. It removes
the HSR/PRP Industrial Procotols page from the AM335x & AM437x SDK builds. Note
that the HSR/PRP Industrial Protocols page is still needed for the AM57x (GEN) SDK
build, so source/linux/Industrial_Protocols.rst still contains
Industrial_Protocols_HSR_PRP. This is expected to add a build warning to the
AM335x & AM437x builds.

The PTP Industrial Protocols page also references PRU-ICSS HSR/PRP. This commit
adds a "Features not supported" section detailing that PRU-ICSS HSR/PRP is not
supported on AM335x & AM437x. This commit also removes specific references to
AM335x & AM437x from PRU-ICSS HSR/PRP sections within the PTP Industrial
Protocols page.

Signed-off-by: Nick Saulnier <nsaulnier@ti.com>

 这意味着什么? 在运行 PRUETH/PRUHSR/PRUHSR 时、自 v9 以来、SDK 上的 PTP 硬件或软件时间戳都不能正常运行? 此范围在 SDK v11 中是否仍然有效?

此致、

Chencheng

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

    您好、Chencheng、

    问得好。 让我澄清一下:

    功能

    我们在 AM335x 和 AM437x 上支持“通用以太网“双 EMAC 或 100M FD 的单 EMAC。

    我们还支持一些工业网络协议、其中栈在 Linux 上运行、然后 PRU 子系统将处理工作从 Linux 操作系统转移。 与使用 CPSW 以太网+ Linux 相比、这可以使用 PRU 以太网+ Linux 实现更好的 HSR 和 PRP 性能。 有关该版本支持的协议的更多信息、请参阅  
    https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/Industrial_Protocols.html

    SDK 6.3 也是 AM335x 和 AM437x 上的最后一个 TI-RTOS 版本。 还有其他仅在 TI-RTOS 上运行的工业网络协议。 TI 没有计划在将来发布另一版本的 TI-RTOS。  
    https://www.ti.com/tool/PRU-ICSS-INDUSTRIAL-SW 

    7.3 中的更高版本  

    我们放弃了对 PRU 子系统上的 AM335x 和 AM437x Linux +工业网络协议的支持。 我们 在 100M FD 上支持 AM335x 和 AM437x“通用以太网“双 EMAC 或单 EMAC

    所有样片  

    我们 在 100M FD 上支持 AM335x 和 AM437x“通用以太网“双 EMAC 或单 EMAC

    和 SDK 9.3 中找到  

    我们在 AM335x 和 AM437x 上不支持任何类型的 PRU 以太网

    11.2 中的描述  

    我们在 AM335x 和 AM437x 上重新添加了对 PRU 以太网的支持、并在 Linux 上重新添加了一些工业网络协议。 我们升级了通用 PRU 以太网驱动程序、因此我预计 PRU 以太网应该在未来版本的 Linux 内核中继续受到支持。

    详细信息:

    PRU 以太网 — 双 emac 和单 emac(新功能)
    https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/Foundational_Components Linux_Drivers PRU-ICSS_Ethernet.html

    *双 emac 和单 emac
    * 10M FD/HD、100M FD/HD
    *支持 PTP

    PRU 以太网 — 交换机(全新!)
    https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/Foundational_Components tiarm/PRU-ICSS/PRU-ICSS/PRU-ICSS/PRU-ICSS_Ethernet.html#two-port-ethernet-switch Linux_Drivers

    可卸载到 PRU 内核的 Linux HSR(自 SDK 6.3 以来首次支持)
    https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/Foundational_Components Network/Kernel/Network/HSR_Offload.html Kernel_Drivers

    Linux PRP、可卸载到 PRU 内核 (自 SDK 6.3 以来首次支持)
    https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/11_02_05_02/exports/docs/linux/Foundational_Components Network/Kernel/Network/PRP_Offload.html Kernel_Drivers 

    此致、

    Nick

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

    对于将来的读者、这个 e2e 主题已从线程中分离出来
    AM3359:SD 卡构建的 Processor SDK Linux v11.02 (RT-Linux) 未引导 

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

    您好、Nick、

    再次感谢您的答复。

    以下是基本的“是/否“问题:

    如果我们采用 TI Linux RT V6.12 (Scarthgap 11.02.x) 运行 PRUHSR/PRUPRP(硬件卸载)而不是 PRUETH(您在 SDK 11 中提到的新特性)、那么 PTP(硬件时间戳或软件)是否仍受支持?

    BR/Chencheng

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

    您好、Chencheng、

    RT Linux + AM335x?

    首先、请注意、我们不会发布 AM335x Linux SDK 11.2 的 RT Linux 版本、因为在我们开发该软件版本时、针对 32 位处理器的 RT Linux 支持并未上传到 Linux 内核 6.12 中。

    64 位处理器的 RT Linux 支持合并了 Linux 内核 6.12 的主线。

    对于内核 6.12 之前的每个 Linux 内核、RT Linux 支持作为一组需要应用于上游内核之上的修补程序保留在一个单独的存储库中。 因此、TI 将这些 RT 补丁应用到了我们的 ti-linux-kernel 分支、优化了性能等、并将该代码用于 RT Linux SDK。

    RT Linux 工程仍在进行中、有 32 位 RT 补丁可应用于 ti-linux-kernel。 我甚至可以告诉您一个未经测试的 ti-linux-kernel 分支机构、在 2025 年夏天、另一个 TI 团队在该分支机构应用了这些补丁。 请记住,我无法保证我们的性能,因为我们没有在我们的最终验证和优化,所以你会希望在你自己的测试和验证严格.

    如果您有兴趣详细讨论 AM335x 上的 RT Linux、请创建新的 e2e 主题、我们可以在此继续讨论。

    您可以执行 HSR + PTP 或 PRP + PTP 吗?  

    好的问题、我自己没有试过。 给我一天左右的时间来研究这个问题。 如果星期四或星期五未回复、请 ping 通该线程。

    此致、

    Nick

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

    您好、Nick、

    感谢您抽出宝贵时间进一步了解。

    更准确地说、我想在 AM335x 上测试这个确切的版本: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-rt-linux-6.12.y-arm32&id=1379a8eb9786e78509f67ff8eac658bde5ddc66d

    根据 ICSS、我认为 TI Linux 和 TI RT Linux 之间的 Linux 内核驱动程序完全相同、因为我比较了驱动程序源代码`git diff --stat ti-linux-6.12.y ti-RT-linux-6.12.y-arm32 - drivers/net/ethernet/ti/icssm``、``ti-linux-6.12.branch 和 arm32-arm32`没有变化。

    如果它没有经过正式测试或验证,你能给正式测试的 repo 分支和修订吗?

    您还能帮助对以下情景进行观察吗?

    支持硬件卸载的 HSR + PTP(软件时间戳)

     2.带硬件卸载的 HSR + PTP(硬件时间戳)

    3、 无硬件卸载的 HSR + PTP(软件时间戳)

     4.无硬件卸载的 HSR + PTP(硬件时间戳)  

    具有硬件卸载+ PTP(软件时间戳)的 PRP

     具有硬件卸载+ PTP(硬件时间戳)的 PRP  

    7.无硬件卸载的 PRP + PTP(软件时间戳)

    8.无硬件卸载的 PRP + PTP(硬件时间戳)  

    您还能说明 ICSS-PRU 固件更新:

    https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/ti-pruss?h=ti-linux-firmware-6.12.y&id=a3b3ee294b0a0a7a605982accb250cb1ca8fdb96

    ti-pruss: Update AM3/4 PRU HSR and PRP firmwares
    Update AM3/4 PRU HSR/PRP firmwares to version 3.00.00.
    
    This firmware fixes below issues:
    - HSR: Performance & Setup: Performance test with 4-IDK setup, IO modules
    sync failure with PTP, PTP packets transfer, MAC filter for RAW interfaces
    - Data Integrity: Corruption of memory, Ping working with corrupted HSR tag,
    Incorrect LAN information in tagged frames with pru
    - PRP: Protocol Handling: Destination MAC check for unicast packets,
    Host duplicate detection with PTP packets, Ping not working from
    SAN without RED-box
    - System Issues: emac_rx_packet crash, Paging issue during network storm,
    - Unique rxc count increment, Remove backward compatibility for storm prevention
    Common Issues (Affecting Both HSR/PRP):
    - Memory & Counter Issues: txMcast Counter increment for supervision/PTP frames
    - Memory map resource conflicts, Underflow handling,
    - rxMisAlignment errors, Firmware locks during cable pull
    Enhancement: TX optimization, Enhanced MAC filter
    
    ef084d57f342dc531427e1c3e00a770f  ti-pruss/am335x-pru0-pruhsr-fw.elf
    ec21b5760cdbb6eb0fa0a0c32f658139  ti-pruss/am335x-pru0-pruprp-fw.elf
    2d1545880d8e58a743dd93a888439c58  ti-pruss/am335x-pru1-pruhsr-fw.elf
    431bc278311b49d519b2a7832a411f78  ti-pruss/am335x-pru1-pruprp-fw.elf
    ef084d57f342dc531427e1c3e00a770f  ti-pruss/am437x-pru0-pruhsr-fw.elf
    ec21b5760cdbb6eb0fa0a0c32f658139  ti-pruss/am437x-pru0-pruprp-fw.elf
    2d1545880d8e58a743dd93a888439c58  ti-pruss/am437x-pru1-pruhsr-fw.elf
    431bc278311b49d519b2a7832a411f78  ti-pruss/am437x-pru1-pruprp-fw.elf
    
    Based on tag: REL.PRU-ICSS-HSR-FW_03.00.00
    
    Signed-off-by: Jayachandran Rameshbabu <j-rameshbabu@ti.com>
    

    这种 Linux 固件更改对我们的用户意味着什么?

    提前感谢!

    BR/Chencheng

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

    您好 Chengheng、

    硬件与软件时间戳  

    请查看我在这里与您团队的另一位成员进行的讨论。 请从 2 月 20 日的回复开始、并阅读之后的回复:
    关于:AM3357:基于 AM3357 的定制板上的 PTP 同步故障

     如果您想对此主题进行其他讨论、请创建一个新的 e2e 主题并咨询我、以便我们能让此主题专注于您的原始问题。  

    ti-RT-linux-6.12.y-arm32 呢?  

    这就是我在谈到的分支机构、当时我说“未经测试的 ti-linux-kernel 分支在 2025 年夏季期间、另一个 TI 团队在该分支应用了这些补丁“。 开发团队尚未在 AM335x 上完全验证此代码。 1) 我不确定 RT 补丁是否自 2025 年夏季以来更新、如果是、我不知道另一个团队是否重新应用了 RT 补丁;2) 如果 RT 补丁出现 问题、TI 应用团队将无法支持调试和修复问题(即,该分支“不受支持“)。

    有关更多背景、请参阅此主题:  关于 AM4378:支持 AM4378 SoC 的状态  

    那么、AM335x/AM437x 上的 HSR + PTP 或 PRP + PTP 呢?  

    这是一个非常复杂的话题,我还在深入探究。 其中一些信息可能不正确 — 如果是,我将在稍后尝试更正。 但以下是我对 2026年3月4日 的理解:

    linuxptp 不是特定于 TI 的驱动程序、而是 Linux 社区代码。 因此、如果 linuxptp 的 Linux 维护人员决定从该工具中放弃对 HSR 和 PRP 的支持、这不是 TI 控制的事情。

    早在 Linux SDK 6.3 中、支持 PRU 卸载的 HSR 和 PRP 确实适用于 PTP、至少适用于 AM57x 上的某些版本的 linuxptp。 这些文档似乎表明 AM335x 和 AM437x 也支持此参考设计、但从技术上讲、开发人员编写了 AM57x 页面、但忘记说 AM335x 和 AM437x 不支持部分或全部功能。 请注意、存在一些限制、记录在 SDK 文档中。 到目前为止,我还不知道 Linux SDK 6.3/Linux 内核 4.19 使用了哪些版本的 linuxptp 代码
    https://software-dl.ti.com/processor-sdk-linux/esd/docs/06_03_00_106/AM335X/linux/Industrial_Protocols_PTP.html

    我的理解是、随着时间的推移、linuxptp 工具的 Linux 维护人员不再支持 HSR 和 PRP、我们现在正在提交代码补丁以将 HSR 和 PRP 支持添加回 linuxptp。 如果我们能够将其合并到中、那么我们将能够在最新版本的 linuxptp 工具上重新添加对 HSR 和 PRP + PTP 的支持、适用于带有 PRU-ICSS 固件的 AM335x 和 AM437X 以及带有 PRU_ICSSG 固件的 AM64x。

    我确实可以看到 2025 年 9 月软件调试的说明、该调试在 AM335x 上调试 HSR + PTP。 问题似乎已修复、该修复方法是您在提交日志中找到的标题为“HSR: Performance & Setup“(HSR:性能和设置)的问题。 似乎有人在 AM335x SDK 11.2 上成功完成了带 PRU 卸载+ PTP 的 AM335x HSR。 缺少的信息是 Linux 内核 6.12 所使用的 linuxptp 版本 — 根据我目前掌握的信息,我预计他们没有使用最新的 linuxptp v4.4。 除了 linuxptp 下载中当前可用的修补程序之外、他们可能还需要对 linuxptp 进行额外的修补程序。

    此致、

    Nick

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

    您好、Nick、

    感谢您的努力。

    让我们忘记 TI Linux (ti-linux-6.12.y) 与 TI RT Linux (ti-rt-linux-6.12.y-arm32) 的相关信息。 对我来说、他们的 ICSS 内核模块具有相同的源代码。 而且、我也可以在它们之间轻松切换代码库。

    感谢您在 RE:AM3357 定制板上的 PTP 同步故障方面的回应

    我也同意大家的看法、PTP 硬件时间戳是一个更好的解决方案。 我们应该旨在使 HSR/PRP 硬件卸载都可以使用 PTP 硬件时间戳。

    不幸的是,这对我来说不起作用。 而 Pooja 在 RE:AM3357:基于 AM3357 的定制板上发生 PTP 同步故障时不起作用

    我们合作、但我们的地理位置不同。 我还没有 AM3359 ICEv2 EVM、我正在获取一个。

    让我从我的观察中向您提供一些更多的意见:

    linuxptp  IS a. TI 特定的 时的驱动器 SDK 6

    您有 自己的 linuxptp 分支:
    这就是 HSR/PRP 硬件卸载功能在 SDK 6 中使用“linuxptp"的“的原因。
    但是、自 2019 年以来、它尚未更新、也未被 SDK 11 (meta-ti Scarthgap 标签 11.02.x) 使用。
    对于 SDK 11、请切换到上游 linuxptp。 在 Scarthgap 上、它是 4.1 版:
    SDK 11 包含与以下哈希值完全匹配的 PRU Linux FW:

    https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/ti-pruss?h=ti-linux-firmware-6.12.y&id=a3b3ee294b0a0a7a605982accb250cb1ca8fdb96

    这意味着 PRU-ICSS-HSR 11 使用 REL.SDK-FW_03.00.00  

    但是、我找不到任何适用于 HSR/PRP 硬件卸载+ PTP 的设置。

    BR/Chencheng

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

    您好、Chencheng、

    感谢您提供的附加语境。

    我仍在联系开发人员、他们在 Linux 内核 6.12 上添加了适用于 AM335x 的 Linux HSR/PRP 驱动程序以进行确定

    1) 他们测试的内容是否准确(例如,ti-linux-firmware 注释不清楚使用哪个操作系统以及使用哪个版本的操作系统进行验证)

    2) 如果他们在 HSR 上测试了 PTP、测试什么版本的工具、是否需要额外的修补程序等

    3) 这是否会被认为是“生产就绪“,或者如果它可能需要额外的开发和调试在您的身边使用

    如果我在下周中没有回复、请 ping 通该线程。

    此致、

    Nick

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

    您好、Nick、
    我遵循了 Pratheesh 的反馈:AM3357:基于 AM3357 的定制板上的 PTP 同步失败 

    并将  ti-linuxptp-v0.3-am57xx-bc 集成到我们的平台中。

    ptpt.cfg:

    [global]
    sanity_freq_limit 0
    step_threshold 0.00002
    tx_timestamp_timeout 20
    
    domainNumber 0
    priority1    128
    priority2    128
    slaveOnly    0
    
    twoStepFlag                  1
    summary_interval             0
    doubly_attached_clock        1
    
    [hsr0]
    redundancy                   1
    delay_mechanism              P2P
    network_transport            L2
    
    [eth0]
    redundancy                   1
    redundancy_master_interface  hsr0
    redundancy_slave_number      1
    
    logAnnounceInterval          0
    logSyncInterval              0
    logMinPdelayReqInterval      0
    announceReceiptTimeout       3
    syncReceiptTimeout           2
    
    delay_mechanism              P2P
    network_transport            L2
    egressLatency                726
    ingressLatency               186
    fault_reset_interval         0
    
    [eth1]
    redundancy                   1
    redundancy_master_interface  hsr0
    redundancy_slave_number      2
    
    logAnnounceInterval          0
    logSyncInterval              0
    logMinPdelayReqInterval      0
    announceReceiptTimeout       3
    syncReceiptTimeout           2
    
    delay_mechanism              P2P
    network_transport            L2
    egressLatency                726
    ingressLatency               186
    fault_reset_interval         0
    

    不过、当我们以 Redbox + PTP 主时钟运行 HSR 设置时:

    root@pm540:~# ptp4l -f /etc/iec61850-ptp-hsr.cfg -m
    ptp4l[104.311]: selected /dev/ptp0 as PTP clock
    ptp4l[104.314]: HSR master (port 1): slave1 eth0, slave2 eth1
    ptp4l[104.314]: HSR slave1 eth0 (port 2): master hsr0, paired slave2 eth1
    ptp4l[104.315]: HSR slave2 eth1 (port 3): master hsr0, paired slave1 eth0
    ptp4l[104.315]: HSR master (port 1): slave1 eth0, slave2 eth1
    ptp4l[104.315]: HSR slave1 eth0 (port 2): master hsr0, paired slave2 eth1
    ptp4l[104.316]: HSR slave2 eth1 (port 3): master hsr0, paired slave1 eth0
    ptp4l[104.319]: port 1 (hsr0): INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[104.320]: red port 2 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[104.322]: red port 3 (eth1): INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[104.323]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[105.195]: short SO_TIMESTAMPING message
    ptp4l[105.195]: port 1: recv message failed
    ptp4l[105.195]: hsr0: No red dispatch port
    ptp4l[105.195]: short SO_TIMESTAMPING message
    ptp4l[105.195]: port 1: recv message failed
    ptp4l[105.195]: hsr0: No red dispatch port
    ptp4l[106.195]: short SO_TIMESTAMPING message
    ptp4l[106.195]: port 1: recv message failed
    ptp4l[106.195]: hsr0: No red dispatch port
    ptp4l[106.195]: short SO_TIMESTAMPING message
    ptp4l[106.195]: port 1: recv message failed
    ptp4l[106.196]: hsr0: No red dispatch port
    ptp4l[106.197]: port 3: new foreign master 502df4.fffe.3a5df2-1
    ptp4l[106.198]: port 2: new foreign master 502df4.fffe.3a5df2-1
    ptp4l[107.195]: short SO_TIMESTAMPING message
    ptp4l[107.195]: port 1: recv message failed
    ptp4l[107.195]: hsr0: No red dispatch port
    ptp4l[107.195]: short SO_TIMESTAMPING message
    ptp4l[107.195]: port 1: recv message failed
    ptp4l[107.197]: hsr0: No red dispatch port
    ptp4l[107.613]: port 3: announce timeout 0
    ptp4l[107.614]: red port 3 (eth1): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
    ptp4l[107.614]: selected best master clock 7e3646.fffe.5a2b4e
    ptp4l[107.614]: selected local clock 7e3646.fffe.5a2b4e as best master
    ptp4l[107.614]: port 3: assuming the grand master role
    ptp4l[108.195]: short SO_TIMESTAMPING message
    ptp4l[108.196]: port 1: recv message failed
    ptp4l[108.196]: hsr0: No red dispatch port
    ptp4l[108.196]: short SO_TIMESTAMPING message
    ptp4l[108.196]: port 1: recv message failed
    ptp4l[108.196]: hsr0: No red dispatch port
    ptp4l[108.200]: port 2: announce timeout 0
    ptp4l[108.200]: red port 2 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
    ptp4l[108.201]: selected best master clock 7e3646.fffe.5a2b4e
    ptp4l[108.201]: selected local clock 7e3646.fffe.5a2b4e as best master
    ptp4l[108.201]: port 2: assuming the grand master role
    ptp4l[108.201]: port 3: assuming the grand master role
    ptp4l[109.195]: short SO_TIMESTAMPING message
    ptp4l[109.195]: port 1: recv message failed
    ptp4l[109.196]: hsr0: No red dispatch port
    ptp4l[109.196]: short SO_TIMESTAMPING message
    ptp4l[109.196]: port 1: recv message failed
    ptp4l[109.197]: hsr0: No red dispatch port
    ptp4l[110.195]: short SO_TIMESTAMPING message
    ptp4l[110.196]: port 1: recv message failed
    ptp4l[110.196]: hsr0: No red dispatch port
    ptp4l[110.196]: short SO_TIMESTAMPING message
    ptp4l[110.196]: port 1: recv message failed
    ptp4l[110.197]: hsr0: No red dispatch port
    ptp4l[111.196]: short SO_TIMESTAMPING message
    ptp4l[111.196]: port 1: recv message failed
    ptp4l[111.196]: hsr0: No red dispatch port
    ptp4l[111.196]: short SO_TIMESTAMPING message
    ptp4l[111.196]: port 1: recv message failed
    ptp4l[111.198]: hsr0: No red dispatch port
    ptp4l[112.196]: short SO_TIMESTAMPING message
    ptp4l[112.196]: port 1: recv message failed
    ptp4l[112.196]: hsr0: No red dispatch port
    ptp4l[112.196]: short SO_TIMESTAMPING message
    ptp4l[112.196]: port 1: recv message failed
    ptp4l[112.196]: hsr0: No red dispatch port
    ptp4l[113.196]: short SO_TIMESTAMPING message
    ptp4l[113.196]: port 1: recv message failed
    ptp4l[113.196]: hsr0: No red dispatch port
    ptp4l[113.196]: short SO_TIMESTAMPING message
    ptp4l[113.196]: port 1: recv message failed
    ptp4l[113.196]: hsr0: No red dispatch port
    ptp4l[114.196]: short SO_TIMESTAMPING message
    ptp4l[114.197]: port 1: recv message failed
    ptp4l[114.197]: hsr0: No red dispatch port
    ptp4l[114.197]: short SO_TIMESTAMPING message
    ptp4l[114.197]: port 1: recv message failed
    ptp4l[114.197]: hsr0: No red dispatch port
    ptp4l[114.198]: selected best master clock 502df4.fffe.3a5df2 on port 3
    ptp4l[114.199]: selected best master clock 502df4.fffe.3a5df2
    ptp4l[114.199]: red port 2 (eth0): MASTER to PASSIVE_SLAVE on RS_PSLAVE
    ptp4l[114.199]: updating UTC offset to 37
    ptp4l[114.200]: red port 3 (eth1): MASTER to UNCALIBRATED on RS_SLAVE
    ptp4l[114.200]: selected best master clock 502df4.fffe.3a5df2 on port 2
    ptp4l[114.201]: selected best master clock 502df4.fffe.3a5df2
    ptp4l[114.201]: updating UTC offset to 37
    ptp4l[114.201]: red port 2 (eth0): PASSIVE_SLAVE to UNCALIBRATED on RS_SLAVE
    ptp4l[114.202]: red port 3 (eth1): UNCALIBRATED to PASSIVE_SLAVE on RS_PSLAVE
    ptp4l[115.196]: short SO_TIMESTAMPING message
    ptp4l[115.197]: port 1: recv message failed
    ptp4l[115.197]: hsr0: No red dispatch port
    ptp4l[115.198]: short SO_TIMESTAMPING message
    ptp4l[115.198]: port 1: recv message failed
    ptp4l[115.199]: hsr0: No red dispatch port
    ptp4l[116.196]: short SO_TIMESTAMPING message
    ptp4l[116.197]: port 1: recv message failed
    ptp4l[116.198]: hsr0: No red dispatch port
    ptp4l[116.198]: short SO_TIMESTAMPING message
    ptp4l[116.199]: port 1: recv message failed
    ptp4l[116.199]: hsr0: No red dispatch port
    ptp4l[116.202]: port 2: rx sync timeout 1
    ptp4l[116.202]: selected best master clock 502df4.fffe.3a5df2 on port 3
    ptp4l[116.202]: selected best master clock 502df4.fffe.3a5df2
    ptp4l[116.202]: red port 2 (eth0): UNCALIBRATED to PASSIVE_SLAVE on RS_PSLAVE
    ptp4l[116.202]: updating UTC offset to 37
    ptp4l[116.202]: red port 3 (eth1): PASSIVE_SLAVE to UNCALIBRATED on RS_SLAVE
    ptp4l[117.196]: short SO_TIMESTAMPING message
    ptp4l[117.198]: port 1: recv message failed
    ptp4l[117.198]: hsr0: No red dispatch port
    ptp4l[117.199]: short SO_TIMESTAMPING message
    ptp4l[117.199]: port 1: recv message failed
    ptp4l[117.199]: hsr0: No red dispatch port
    ptp4l[118.197]: short SO_TIMESTAMPING message
    ptp4l[118.198]: port 1: recv message failed
    ptp4l[118.198]: hsr0: No red dispatch port
    ptp4l[118.199]: short SO_TIMESTAMPING message
    ptp4l[118.199]: port 1: recv message failed
    ptp4l[118.199]: hsr0: No red dispatch port
    ptp4l[118.203]: port 3: rx sync timeout 1

     PTP 永远不会同步。

    Pooja 还使用 SDK 11 + ti-linuxptp-v0.3-am57xx-bc 在 ICEv2 EVM 上运行了相同的设置。 我们得到了完全相同的行为。

    您能否再次向开发人员咨询这些新发现?

    谢谢& BR,

    Chencheng

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

    您好、Chencheng、

    对此处延迟的回复表示歉意。 我要把这个线程交给处理另一个线程的人
    AM3357:基于 AM3357 的定制板上的 PTP 同步失败 — 处理器论坛-处理器 — TI E2E 支持论坛

    此致、

    Nick