• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 4080 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux/AM5718: Multiple PTP instances on dual interfaces of PRU ETH

Paritosh Dixit
Intellectual 720 points
Part Number: AM5718

Tool/software: Linux

SDK: Linux RT SDK 5.02

Device: AM571x IDK

We tried to run PTP daemon on both interfaces of PRU ETH. When both interfaces are connected and receiving PTP messages, none  of the two PTP daemon work. It works only when other interfaces is removed:

On interface eth2, ptp4l daemon is started. At this point of time, eth3 is not connected.

root@am57xx-evm:~# ptp4l -2 -P -f oc-eth2.cfg -s -m

ptp4l[1840.355]: selected /dev/ptp2 as PTP clock
ptp4l[1840.410]: port 1 (eth2): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1840.412]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1840.843]: port 1: new foreign master 001d7f.fffe.104ec2-1
ptp4l[1842.843]: selected best master clock 001d7f.fffe.104ec2 on port 1
ptp4l[1842.844]: port 1 (eth2): LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1843.850]: master offset -71744 s0 freq -6449 path delay 587
ptp4l[1844.850]: master offset -71821 s1 freq -6526 path delay 589
ptp4l[1845.850]: master offset -53 s2 freq -6579 path delay 591
ptp4l[1845.851]: port 1 (eth2): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[1846.850]: master offset 12 s2 freq -6530 path delay 590
ptp4l[1847.850]: master offset -29 s2 freq -6567 path delay 593
ptp4l[1848.850]: master offset -45 s2 freq -6592 path delay 592
...
ptp4l[1881.849]: master offset 5 s2 freq -6548 path delay 589
ptp4l[1882.849]: master offset 15 s2 freq -6537 path delay 587
ptp4l[1883.849]: master offset 27 s2 freq -6520 path delay 589
ptp4l[1884.824]: port 1: multiple peer responses                                                          <--------------------------- This is when eth3 is connected.
ptp4l[1884.824]: port 1: rogue peer delay response
ptp4l[1884.824]: port 1 (eth2): SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1900.942]: port 1 (eth2): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1901.066]: port 1: rogue peer delay response
ptp4l[1901.067]: port 1 (eth2): LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1917.182]: port 1 (eth2): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1917.306]: port 1: rogue peer delay response
ptp4l[1917.306]: port 1 (eth2): LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

On interface eth3: ptp4l daemon was started together with daemon on eth2, but network cable on eth3 was disconnected.

root@am57xx-evm:~# ptp4l -2 -P -f oc-eth3.cfg -s -m
ptp4l[1851.388]: selected /dev/ptp2 as PTP clock
ptp4l[1851.450]: port 1 (eth3): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1851.452]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1851.454]: port 1: link down
ptp4l[1851.455]: port 1 (eth3): LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1851.510]: selected best master clock 70ff76.fffe.1c0ee6
ptp4l[1868.611]: port 1: link up
ptp4l[1868.670]: port 1 (eth3): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1868.685]: port 1: rogue peer delay response
ptp4l[1868.686]: port 1 (eth3): LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1884.800]: port 1 (eth3): FAULTY to LISTENING on INIT_COMPLETE

  • 0
    TI__Guru** 101660 points

    Hello Paritosh,

    Our HSR/PRP expert is out of office at the moment, so support will be limited until then.

    There may be limitations to what PRP can do on PRU ethernet. Please see the TI documentation links in your post HSR/PTP Timeout. Another thing to check is that whatever the PRU ethernet ports are connected to is properly isolating the ports. 

    Regards,

    Nick

  • 0
    TI__Mastermind 30536 points

    Paritosh,

    As the documentation describes here, the PTP clock can only be provided on one interface (eth2/eth3) per PRU/ICSS instance at a time.

  • 0 in reply to RonB
    TI__Guru*** 125430 points
    Paritosh,

    I think there might be a workaround. Your goal is to only have one PTP clock ultimately, right? In other words, you want to choose the best clock of the two that are available and use that one right? This can actually be achieved using a boundary clock configuration. Normally boundary clock requires external connections of the 1PPS signals, but since we're talking about a boundary clock implementation using a single ICSS, that's not required in this case.

    Can you post your eth2.cfg file?

    Brad
  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points
    Paritosh,

    Try something like this for your cfg:

    [global]
    sanity_freq_limit 0
    step_threshold 0.000002
    tx_timestamp_timeout 10

    logMinPdelayReqInterval 0
    logMinDelayReqInterval 0
    logSyncInterval 0
    logAnnounceInterval 0

    priority2 128

    twoStepFlag 1
    summary_interval 0
    fault_reset_interval 1

    [eth2]
    boundary_clock_jbod 1
    egressLatency 726
    ingressLatency 186
    delay_mechanism P2P
    network_transport L2
    fault_reset_interval 0

    [eth3]
    boundary_clock_jbod 1
    egressLatency 726
    ingressLatency 186
    delay_mechanism P2P
    network_transport L2
    fault_reset_interval 0

    Please send the updated console output.

    Thanks,
    Brad
  • 0 in reply to Brad Griffis
    Intellectual 720 points

    Hi Brad,

    I tried this PTP config on AM572x IDK’s eth2 and eth3. From the log messages, it seems to be working, with two exceptions:

    1. There are serious error messages. We need to understand significance and impact of them..
    2. Accuracy test on Bridge HW on both ports should confirm these results.

     

    Detailed config and logs are in the attached document:

    Thanks,

    Paritoshptp4l log on TI AM572x IDK.docx

  • 0 in reply to Paritosh Dixit
    TI__Mastermind 30536 points

    Paritosh,

    I'm sorry for the delay in getting back to you. We've tried to respond to your comments in the attached log and I hope this addresses your questions. In short, we do not recommend to force the BC to be slave. We only support one independent master with the two ports being synchronized to it and BCMA choosing the best one based on priority.

    /cfs-file/__key/communityserver-discussions-components-files/791/4747.ptp4l-log-on-TI-AM572x-IDK.docx

    I hope this is helpful to you.