AM3359 and PROCESSOR-SDK-LINUX-AM335X: PTP (IEEE1588)

I would update my customer status.

According to my customer, they found a data path that the master clock from the Ethernet was fed to the PTP daemon, then the Linux system clock was updated.
But its accuracy didn't satisfy them. Their point is is the utilization of IEEE1588 hardware.

Q4. Does the Linux or Linux-RT SDK utilizes the IEEE1588 hardware for an accurate timestamp ?

My customer wants to have as much as accurate timestamp to log non-Ethernet events like GPIO inputs. So they hope:
- Ethernet incoming master clock data update a timer hardware in the AM3359.
- The timer counts-up by itself.
- The latest time data is served to customer application.

-n

Biser,

We are still waiting for your reply.

Could you describe the accuracy issue that the customer is seeing and which PTP daemon they are using? Which version of the TI RT processors SDK are they using?

Schuyler,

My customer is waiting for a long time.

I hesitate to change our point without answer.

(Repeat) Q4. Does the Linux or Linux-RT SDK utilizes the IEEE1588 hardware for an accurate timestamp ?

Now they are using Linux-NonRT.

Your reply would be 'no', therefore the question was expanded to Linux-RT.

Schuyler,

I would try to answer to your questions.


> the accuracy issue that the customer is seeing

It would be difficult to explain as an issue, but let me try.
Their application is a logger. It detects a GPIO state change and log with its time stamp.
The accuracy requirement is as much as accurate for the AM3359 and Linux-NonRT combination.


> which PTP daemon they are using?

They don't necessarily use PTP daemon. Just studied.
It is not sure the daemon which they studied. I think one in the TI Linux-NonRT SDK.


> Which version of the TI RT processors SDK are they using?

Their SDK is the latest Linux Non-RT.



Customer expectation:

- Ethernet incoming time value is fed to a dedicated clock resource.
The 'CPSW_3G' is expected to be the one.
(This point was Q1.)

- The dedicated clock resource counts up by itself to serve a smoothly changing value.
(This point was Q2.)

- When customer application asks the time value, a stack read from the hardware register and responds every time.
(This point was Q3.)


- The time value doesn't go through the PTP daemon or Linux system clock. They think it is important for a better accuracy.




*
Your solution would be appreciated, but today I was requested to explain the current implementation. (Is there such a mechanism or not.)
And the due date was set to your today. (Next Japanese noon.)

Some kind of ptp application deamon is required to manage the clock sync with a grand master clock. This sounds like the customer requirement which is external means of clock reference. There is the open source ptpd2 daemon provided in the TI SDK (both RT and non RT) that looks to only use SW timestamping. Another open source ptplinux package does use the cpts HW time stamping and preliminary testing shows improvement over software timestamping.

In general it appears that customers may start with an open source ptp application deamon but depending on their resolution requirements have written their own stacks.

The cpts provides the low level support to the Linux kernel 1588 support for hardware time stamping support. It is not designed to manage the necessary network transactions with a grand master clock. The ptp application daemon uses the kernel to send packets that determine several factors necesary for syncing the clocks as close as possible.

I agree that gpio does need to go through the ptp daemon. But the timestamp generated for the hardware event will need to be referenced against the system clock.

The next challenge is the time capture based on the gpio being triggered. This will depend greatly on the resolution required by the customer. Unfortunately there is not an external event on the am335x that can be used to generate a TS push on the cpts directly. The only way at the moment we see how to do this is with a PRU application that pushes the event to the cpts upon gpiog triggering. We have not tried this yet so we do not have an idea on what the ultimate clock jitter would be.