AM6442: PTP slave on PRU

Linux is fine for running a PTP slave as long as the network packets are hardware-timestamped with the required precision (which is obviously prerequisite in any case).  The code running in linux userspace doesn't really have any real-time requirements, it's just exchanging network packets and computing the offset and frequency ratio between the master's PTP clock and the local timestamping clock.

And I'm not super familiar with the am64xx but it looks like its CPTS (the PTP network packet timestamping module) and associated linux driver have the ability to adjust the CPTS timebase itself to track PTP time (as opposed to just tracking the offset and frequency ratio in software) and generate PPS outputs from it in hardware.

The only issue with this architecture is there's no way for PRU to read the CPTS timebase, although it's probably possible to route a compare event or pps signal from CPTS to PRU. If you do need PRU to be able to work with PTP time directly then you'll want a different approach that allows you to explicitly obtain the offset and frequency ratio between PTP time and some hardware timer/counter that's directly readable by PRU. This is a bit more effort but it's actually what we do on the AM335x for our use case, so I can provide more details if needed.

Ah wait, are you talking about ethernet implemented in PRUSS (using its MII_G_RT module) as opposed to using the normal ethernet subsystem (CPSW)? Because that would be a different story since that doesn't involve CPTS, instead PRU would be responsible for acquiring packet timestamps. I'm not familiar with the PRU ethernet firmware capabilities but there seem to be a bunch of previous discussion threads about it, e.g. this thread mentions support for PTP in it, and this thread also discussed PPS output (it started out about CPSW but then drifted to using PRU ethernet).

Hello Matthijs,
Thanks for jumping in! I always appreciate your input on these threads, I've learned a lot from you over the years.

Hello Leon,
When using the PRU cores to implement a networking protocol, typically the PRU subsystem acts as if it is a peripheral on the chip that is handling the networking communication - however, the networking stack still gets handled by another core on the processor that is controlling the PRU subsystem. A single PRU_ICSSG subsystem can be controlled by either Linux on the A53 cores, or by MCU+ running on the R5F cores.

let's clarify exactly what you are looking for here

1) When you say "generate PPS signal for my entire system", are you referring just to the ability to send a PPS signal from the core that controls the PRU_ICSSG, out of a processor pin to be received by other devices that are outside of the AM64x? Or are you trying to synchronize all the different cores INSIDE of the AM64x to be on the same timebase?

2) When you say "our required real-time constraint", are you talking about how close the PTP time on the AM64x is to the time in the clock master? Or are you talking about something else, like the processor's ability to respond to a real-time event within a specific time window?

Here are some initial links that might be interesting to you 

For information about HSR/PRP and PTP when an R5F core is controlling the PRU_ICSSG, look at the Industrial Communications SDK:
https://www.ti.com/tool/download/INDUSTRIAL-COMMUNICATIONS-SDK-AM64X
https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am64x/09_00_00_03/docs/api_guide_am64x/ICSS_TIMESYNC.html
https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am64x/09_00_00_03/docs/api_guide_am64x/EXAMPLES_INDUSTRIAL_COMMS_HSR_PRP_DEMOS.html

For information about HSR/PRP when Linux controls the PRU_ICSSG:
for timeline, see https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1250741/am6442-linux-hsr-prp-ptp-support-on-pru-icssg-cpsw-cpsw3g
For current features in SDK 9.1, see https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_01_00_08/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/HSR_Offload.html

Regards,

Nick

Hello Matthijs, hello Nick,

Yes, I plan to use the PRUSS, where either HSR or PRP will be running.

The plan is to get the PPS signal out on a pin for other hardware parts on our own board, as well as to use it in the remote cores of the SoC.

The mentioned real-time constraint concerns the accuracy of the synchronization. When several of our devices are attached to the same network, their clocks must be synchronized with a difference of max. a few microseconds.

Thank you for the links, I checked them out, which raised other issues.

Kind regards

Leon

Leon Rigoni said:

The mentioned real-time constraint concerns the accuracy of the synchronization. When several of our devices are attached to the same network, their clocks must be synchronized with a difference of max. a few microseconds

Yes I understand, but my point was that this synchronization accuracy doesn't really impose real-time constraints on the PTP implementation apart from the packet timestamping. For given network conditions the synchronization accuracy of a PTP implementation primarily depends on the accuracy of the packet timestamps and how well the clock tracking algorithm is able to filter out jitter. So as long as the timestamping is done by hardware or PRU, the PTP daemon itself is delay-tolerant (within reason of course) and can be implemented whereever it is most convenient, which is almost certainly not on PRU.