Linux PTP Instructions in DRIVE SW manual fail

Hello,

I followed the manual to set up PTP Time Synchronization, however, when I get to the Linux ptp4l step it fails with the result,

ptp4l[68696.679]: config item (null).assume_two_step is 1
ptp4l[68696.679]: config item (null).check_fup_sync is 0
ptp4l[68696.679]: config item (null).tx_timestamp_timeout is 1000
ptp4l[68696.679]: config item (null).clockClass is 248
ptp4l[68696.679]: config item (null).clockAccuracy is 254
ptp4l[68696.679]: config item (null).offsetScaledLogVariance is 65535
ptp4l[68696.679]: config item (null).productDescription is ';;'
ptp4l[68696.679]: config item (null).revisionData is ';;'
ptp4l[68696.680]: config item (null).userDescription is ''
ptp4l[68696.680]: config item (null).manufacturerIdentity is '00:00:00'
ptp4l[68696.680]: config item (null).domainNumber is 0
ptp4l[68696.680]: config item (null).slaveOnly is 0
ptp4l[68696.680]: config item (null).twoStepFlag is 1
ptp4l[68696.680]: config item (null).priority1 is 254
ptp4l[68696.680]: config item (null).priority2 is 254
ptp4l[68696.680]: config item (null).gmCapable is 0
ptp4l[68696.680]: config item (null).gmCapable is 0
ptp4l[68696.680]: config item (null).clock_servo is 0
ptp4l[68696.680]: config item (null).time_stamping is 1
ptp4l[68696.688]: ioctl SIOCETHTOOL failed: No such device
ptp4l[68696.689]: config item (null).free_running is 0
ptp4l[68696.689]: config item (null).time_stamping is 1
ptp4l[68696.689]: config item (null).time_stamping is 1
ptp4l[68696.689]: selected /dev/ptp0 as PTP clock
ptp4l[68696.696]: ioctl SIOCGIFHWADDR failed: No such device
failed to generate a clock identity

I was wondering if anyone else has seen this error, or has successfully gotten PTP to work following the instructions in the manual page.

I am using DRIVE SW 8.0.

Dear sassydai,

Please refer to the following link for your topic.

I don’t think that link is what I am trying to do. The link seems to be about sync the Xavier time to internet NTP to access the internet. However, I want to use PTP to sync the Xavier time to the Aurix MCU gPTP server. I followed the instructions for “Time Synchronization between AURIX™ and the SoC Using gPTP” in the manual and it did not work.

Dear sassydai,

Could you please try to run below commands on Linux?

timedatectl set-ntp 0
./phc2sys -s /dev/ptp0 -w -S 1.0 -O 0 &
./ptp4l -f ./gPTP_slave.cfg -p /dev/ptp0 -i eth0 -m -l 7

When I get to the ptp4l command, I get this message:

ptp4l[432820.530]: selected /dev/ptp0 as PTP clock
ptp4l[432820.530]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[432820.531]: port 1: get_ts_info not supported
ptp4l[432820.588]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[432820.588]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[432820.588]: port 1: setting asCapable
ptp4l[432820.762]: port 1: new foreign master 000319.fffe.000001-1
ptp4l[432820.778]: port 1: peer port id set to 00044b.fffe.af6b57-1
ptp4l[432821.088]: port 1: delay timeout
ptp4l[432821.162]: selected best master clock 000319.fffe.000001
ptp4l[432821.162]: running in a temporal vortex
ptp4l[432821.162]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[432821.162]: PI servo: sync interval 0.125 kp 1.306 ki 0.130583
ptp4l[432821.293]: port 0: setting asCapable
ptp4l[432821.562]: port 1: received pdelay_req msg with unexpected peer port id 000319.fffe.000001-1
ptp4l[432821.588]: port 1: delay timeout
ptp4l[432821.778]: port 1: peer port id set to 00044b.fffe.af6b57-1
ptp4l[432822.088]: port 1: delay timeout
ptp4l[432822.589]: port 1: delay timeout
ptp4l[432822.662]: port 1: received pdelay_req msg with unexpected peer port id 000319.fffe.000001-1
ptp4l[432822.778]: port 1: peer port id set to 00044b.fffe.af6b57-1
ptp4l[432823.089]: port 1: delay timeout
ptp4l[432823.589]: port 1: delay timeout

the lines starting from received pdelay_req msg with unexpected peer port id 000319.fffe.000001-1 repeat endlessly for several minutes until I killed the program.

Hi sassydai,

I think I might know what the issue is. But first, could you kindly provide your Aurix firmware version?

Open up your Aurix shell (usually /dev/ttyUSB3 if you plugged in your debug cable before any other USB device was enumerated). Send the command “version”.

There’s a workaround that’s applicable for certain Aurix firmware versions. I just want to be sure you have the version I think you do.

Thanks,

Sean

This is the version.

shell> version
Info: Executing cmd: version, argc: 0, args: 
SW Version: DRIVE-V5.0.13-E3550-EB-Aurix-With3LSS-3.01.05
Compilation date: Nov 12 2018, 11:33:03
Command Executed

Thanks!

Ok, great, just as I thought. Please try this workaround. You might have to run these commands as “sudo.”

# First, go to https://www.epochconverter.com
# and convert any arbitrary human readable date/time 
# to epoch time format - this will be a decimal 
# value so be sure to convert it to hex

# On Aurix shell

## Check current epoch time
date
## Set epoch time 
date 0x[epoch in hex format]
## Confirm the time you set above
date 
## Enable gPTP
gptpon

# On Tegra shell

## Read system time
date
## Take down br0.200
ifconfig br0.200 down
## Create a new VLAN to communicate with Aurix
ip link add link eth0 name eth0.200 type vlan id 200
## Set ip addr of eth0.200 (x.x.x.28 if Tegra A, x.x.x.29 if Tegra B)
ifconfig eth0.200 10.42.0.28 
ifconfig eth0.200 up
## Follow the normal procedure
cd ~/drive-t186ref-linux/samples/nvavb/daemons
timedatectl set-ntp 0
./phc2sys -s /dev/ptp0 -w -S 1.0 -O 0 &
./ptp4l -f ./gPTP_slave.cfg -p /dev/ptp0 -i eth0.200 -m  -l 7
## Verify system time is synced (might need a separate terminal)
date

Also, I noticed something in your logs:

ptp4l[432821.562]: port 1: received pdelay_req msg with unexpected peer port id 000319.fffe.000001-1

This line suggests that you have more than two PTP devices on your network. I’m assuming this means that you’re trying to sync both Xavier A and Xavier B with Aurix. If this is the case, then please add the “-D” flag to the ptp4l command:

./ptp4l -f ./gPTP_slave.cfg -p /dev/ptp0 -i eth0.200 -m  -l 7 -D

This issue is fixed in the upcoming Aurix firmware version. This workaround will no longer be needed.

Please try this out and let me know if it works for you!