Linux/TMDXIDK5728: PTP issue

The software team have been notified. They will respond here.

Hi,

For discussion alignment purposes there is ptp4l testing done as part of the SDK release. The link below shows how the ptp4l was tested on the TI platforms.

processors.wiki.ti.com/.../Linux_Core_CPSW_User's_Guide

The command line used was this:
./ptp4l -E -4 -H -i eth0 -s -l 7 -m -q -p /dev/ptp0

The key difference between your setup and the TI docuemtation is the e2e vs. p2p choice. Is there a preference for p2p? I will check into the possible the delay selection might have with the driver.

Can you please describe you setup for testing? Are you using a TI evm or a custom board? You mentioned using the 4.01 SDK, if using the TI board are you using the pre-built images from the SDK?

Best Regards,
Schuyler

Hi Schuyler

As I wrote in the caption I'm using a TMDXIDK5728. I tried also TMDXIDK5718. I'm using pre-built SDK 4.01

Setup is IDK connected to Meinberg GMC.

I found no hint "P2P in IPv4 transport is not working". Yes, we use P2P.

BR, Chris

Hi Chris,

I wanted to verify that the P2P is supported in the driver so I discussed with a development member and he confirmed that it is. Here is a command line suggestion as well as a config file parameter.


With a recent changes to the driver in August this year to fix the "tx_timestamp_timeout" a parameter has to be added.


ptp4l -E -2 -H -i eth0 -l 6 -m -q -p /dev/ptp0 -f ptp.cfg

root@am335x-evm:~# cat ptp.cfg
[global]

tx_timestamp_timeout 400

This is something you tried I know in your setup, but could you please try your test again with this command line and the addition to the config file?

Best Regards,
Schuyler

Nice, but as a said initially, P2P with L4 does not work, and even when adding the line request it does not.

Croot@am57xx-evm:~# ./ptp4l -ieth0 -m -P -4 -f ptp_def.cfg
ptp4l[78961.274]: selected /dev/ptp0 as PTP clock
ptp4l[78961.288]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[78961.289]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[78961.290]: port 1: link up
ptp4l[78962.689]: timed out while polling for tx timestamp
ptp4l[78962.689]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[78962.689]: port 1: send peer delay request failed
ptp4l[78962.712]: port 1: LISTENING to LISTENING on FAULT_DETECTED (FT_UNSPECIFIED)

-c

Hi Chris,

The development team member is able to reproduce the issue that you are seeing. We will have to do more investigating, it looks like the HW is having an issue with the address 224.0.0.107 which is the default when -P is -4.

Unfortunately most of the people including myself will be out until the first of January. After I am able to discuss with additional HW team members I will respond to this thread.

Regards,
Schuyler

Hi Chris,

We are still looking at an internal HW question we have. Is this still an issue for you?

Best Regards,
Schuyler

Hi Schuyler

Yes, the issue persists.

I'm now in preliminary testing the PTP BC (with SDK 4.2) and the problem appears now and then as well. I'm using exclusively IPv4 transport and alternatively of E2 and P2P.

Two examples:

1)

ptp4l[4762.019]: timed out while polling for tx timestamp

ptp4l[4762.019]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug

ptp4l[4762.019]: port 1: send sync failed

ptp4l[4762.019]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

2)

ptp4l[89.021]: timed out while polling for tx timestamp

ptp4l[89.021]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug

ptp4l[89.021]: port 1: send peer delay response failed

ptp4l[89.021]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

I use TI recommended setting:

tx_timestamp_timeout 10

Regards, Chris

HI Chris,

We might have a workaround that might work for you, could you set bit 7 which is Port 1 Time Sync Unicast Enable in the P1_CONTROL register located at 0x4848 4200 using devmem2?

Bit 15 in this same register is Port 1 Time Sync Destination IP Address 107 enable does not appear to have an affect that we are trying to understand.

Best Regards,
Schuyler