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.

AM5716: 1pps input support without BC

Part Number: AM5716

The latest Linux processor SDK version 6 supports 1PPS signals on both GMAC and PRU HSR/PRP ports. The test setup for 1PPS measurements using IDK is well documented. But it explains 1PPS inputs (latch) for PTP BC (Boundary Clock) only when, say, GMAC clock can sync to PRU clock or vice verse, and BC driver controls the direction.

In my setup I do not need the BC. I want to have ordinary clock PTP master on any of interfaces (GMAC or PRP/HSR) which is driven by external GPS 1PPS signal: GPS 1PPS -> PRU/GMAC 1PPS latch. This configuration is not documented.

Standard Linux way is to route 1PPS via GPIO (or other port pins). It is hardware independent, but it uses GPIO interrupts and involves kernel. This will have unacceptable jitter. So a hardware 1PPS processing using timers is much better, but is this supported? Will 1PPS inputs work if fed to latch inputs to sync PTP clocks without BC driver? I do not need to control which 1PPS is active (what BC driver does). But I am not sure if this configuration is possible and guaranteed to work.

  • Hello Oleg,

    I am sorry for the delayed response. As an FYI for readers, our 1PPS documentation for PTP is here: Generating 1 PPS. We do not explicitly document latching in a 1PPS signal there, but the dts files do make it look like we support your use case.

    Take a look at one of the pps dtso files (e.g. in your Linux SDK under arch/arm/boot/dts/ti/am571x-idk-pps.dtso). Inside &mac, we have a pps_timer (which is for outputting a PPS signal) and latch_timer (which is for latching in an external PPS signal). pinctrl-names "pwm" and "ref" allow us to have up to two PPS output signals, and "latch" should allow us to latch in an external PPS (using latch_timer to timestamp the signal instead of GPIO interrupts).

    Give me a couple of days to clarify how to latch in external PPS signals, and use those as the clock master for your Ethernet interfaces.

    Regards,

    Nick

  • Yes, I saw that, thanks!

    Using my custom board, I am currently able to generate both 1PPS outputs from CPTS and IEP timers. To enable them both at the same time (for time shift measurement purposes) I had to patch ptp_bc.c driver, so it allows both active. Now I am interested in enabling the latch option to, for instance, route CTPS 1PPS output to IEP 1PPS input and see if they sync.

    I found that extts_enable write-only pseudo-file controls if the clock uses external latch input. But unlike pps_enable file, this one does not allow to write 1 to it. I've been looking into it, but any help is appreciated.

  • For other readers: kernel source has documentation for PTP sysfs: Documentation/ABI/testing/sysfs-ptp. This explains what to write to extts_enable: channel number followed by 0/1 to disable/enable. For single supported channel, the number is 0.

    I wrote "0 1" for IEP clock, and when 1PPS is routed to latch0 input, the iep_get_latch_ts function is called per each pulse. Unfortunately, 1PPS outputs stil are not in sync. Either ptp daemon is necessary to sync whole timecounters, or maybe I still missing something. Still searching...

  • Hello Oleg,

    We support is the PPS/PTP_CLK_REQ_EXTTS (External timestamp) feature for CPTS/IEP. The IEP/CPTS will record the timestamp of the external pulse, and report it to the Linux PPS stack to be retrieved by the user mode program.

    I think the actual PPS synchronization is done at the LinuxPTP phc2sys for BC operation. Still getting clarification on non-BC usecase.

    Regards,

    Nick

  • Yes, I successfully reproduced the TI test setup to sync CPTS timers of two boards via PTP and then IEP timer from CPTS using phc2sys. All 3 PPS pulses are in sync with 10-45 ns difference.

    For GPS setup it requires an external multiplexor (to support both BC and GPS PPS) and driver modification. The multiplexor is currently supported by the BC driver if configured in device tree (CPTS, PRU1, PRU2, UNUSED inputs) to select the master clock for EXTTS sync. I am going to use the 4th input to feed the GPS PPS to the system. Then I should be able to sync either CPTS or IEP clock from another one, or sync both clocks from the external PPS from GPS. I did not look yet what modifications are necessary to phc2sys and/or other drivers/apps to support it. BC driver definitely requires an option to select the 4th input (currently unused).

    I'm going to test it myself, but would be great if TI supports this use case in the code out of the box.

  • Hello Oleg,

    The PPS portion of our drivers is still under development, so we appreciate any feedback you have.

    I am still trying to get a clearer idea of what is going on in our current software. I will have more information next week.

    Regards,

    Nick

  • Hello Oleg,

    Are you trying to sync the AM57x clocks with the GPS master clock (e.g., send GPS clock value to AM57x over a serial interface + PPS measurement)? Or do you just want the clocks to have a constant (but unknown) offset from the GPS master clock (just PPS measurement)?

    I do not know of a currently existing standard Linux PTP way of taking in a rough estimate of the base time in the GPS master clock, and then getting the precise GPS master clock value from the PPS signal. But it should be doable.

    Regards,

    Nick

  • Hello Oleg,

    I am assuming you resolved your issue. If not (or if you have any feedback for us on adding functionality to the drivers going forward), please feel free to reply!

    Regards,

    Nick

  • I am currently on 2 week vacation, but the issue is not resolved.

    I need to sync AM57xx hardware PTP clocks with GPS absolute time. I need to have absolute precise timestamps on few isolated devices few miles away from each other. I am planning to use GPS with 1PPS to sync internal PTP clocks and get absolute timestamps of events which can be compared later (say, in logs).

    Linux has options to use GPS with 1PPS source to sync using NTPD (https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html) or Chrony. This works and can sync Linux system time driven by NTPd. But I need to do the same to sync hardware PTP clocks from the same GPS 1PPS input AND GPS absolute date/time. I do not know yet if this can be applied to ptp4linux without patching the code. But this looks like quite usual use case and would be weird if it will not be supported out of the box by TI PTP tools/drivers.

  • And I can, of course, use NTPd to sync the Linux system time from GPS/PPS, then use phc2sys to sync PTP clocks from Linux time. But using 1PPS from GPS via, say, GPIO input means high jitter (kernel interrupts, etc) and inability to provide stable time source. Using direct GPS to PTP clock PPS sync should resolve this issue and provide stable clocks.

  • Hello Oleg,

    Thank you for the additional information. I am out of office for the rest of this week, but I will get back to you next week.

    Regards,

    Nick

  • Hello Oleg,

    it will be another day or so before I can get you a response. Will reply soon.

    Regards,

    Nick

  • Hello Oleg,

    It does not look like the out-of-the-box TI PTP software supports your PPS latch usecase at this point in time. (where the usecase is: 1) take in a general GPS time from another input, e.g. RS-232. Then 2) latch in a PPS input to 3) fine-tune the IEP or CPTS clock to match the master clock. The IEP or CPTS clock can now be used as PTP master for other clocks). I suspect this is related to the fact that TI does not currently test or support the GPS sync Linux tools you mentioned earlier (NTPD, chrony).

    One unverified suggestion for how this might be able to be implemented:

    * Connect the GPS PPS output to the PPS latch of the IEP/CPTS you want to use as PTP master.

    * Connect the gps "time of day" signal somewhere else

    * User ptp application reads the "time of day" through the gps kernel driver and sets the IEP / CPTS clock time to match (crude sync)

    * IEP / CPTS uses the "crude sync" time to timestamp the PPS from the gps and reports timestamp to userspace

    * ptp application calculates the fine-tuned adjustment and passes the adjustment back to the IEP / CPTS clock (adjusted frequency, offset, etc)

    * IEP / CPTS clock may now be used as PTP master time

    Regards,

    Nick