i.MX95 19x19 EVK — ptp4l 802.1AS/gPTP Both Boards Becoming Grandmaster in Point-to-Point Setup

kosisochukwu · April 7, 2026, 1:52pm

Hello Toradex Community,

I am working on a point-to-point PTP synchronization setup between two NXP i.MX95 19x19 Verdin EVK boards running a PREEMPT_RT kernel (6.12.34-rt11) built from the NXP Yocto walnascar BSP. IEEE 1588 synchronization using default.cfg works correctly between the two boards. However when I attempt to use 802.1AS (gPTP) both boards become grandmaster and synchronization fails.

Master Config

root@imx95-19x19-verdin:\~# cat /etc/linuxptp/gPTP.cfg
#
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
\[global\]
gmCapable 1
priority1 124
priority2 124
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
tx_timestamp_timeout 100
root@imx95-19x19-verdin:\~# phc2sys -s CLOCK_REALTIME -c /dev/ptp0 -O 37 -m > /var/log/phc2sys.log 2>&1 & ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/gPTP.cfg -m > /var/log/ptp4l.log 2>&1 &
\[1\] 5851
\[2\] 5852
root@imx95-19x19-verdin:\~# ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/gPTP.cfg -m > /var/log/ptp4l.log 2>&1 & phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 37 -m > /var/log/phc2sys.log 2>&1 &^C
root@imx95-19x19-verdin:\~# tail /var/log/ptp4l.log
ptp4l\[422808.421\]: selected /dev/ptp0 as PTP clock
ptp4l\[422808.464\]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l\[422808.465\]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l\[422808.465\]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l\[422811.772\]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l\[422811.773\]: selected local clock 160716.fffe.bf1d7a as best master
ptp4l\[422811.773\]: port 1 (eth0): assuming the grand master role

Slave Config

root@imx95-19x19-verdin:\~# cat /etc/linuxptp/gPTP.cfg
#
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
\[global\]
gmCapable 0
priority1 248
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
tx_timestamp_timeout 100
root@imx95-19x19-verdin:\~# ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/gPTP.cfg -m > /var/log/ptp4l.log 2>&1 & phc2sys -s /dev/ptp0 -c CLOCK_REALTIME -O 37 -m > /var/log/phc2sys.log 2>&1 &
\[1\] 5946
\[2\] 5947
root@imx95-19x19-verdin:\~# tail /var/log/ptp4l.log
ptp4l\[422842.496\]: selected /dev/ptp0 as PTP clock
ptp4l\[422842.548\]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l\[422842.549\]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l\[422842.549\]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l\[422846.297\]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l\[422846.297\]: selected local clock da2eeb.fffe.1a6499 as best master
ptp4l\[422846.297\]: port 1 (eth0): assuming the grand master role

ToradexAI · April 7, 2026, 1:52pm

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Looking at your 802.1AS/gPTP configuration issue, I can see that both boards are becoming grandmaster despite your configuration differences. This is a common problem in point-to-point gPTP setups.

Root Cause Analysis

The issue occurs because both boards are experiencing ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES, which means they’re not receiving announce messages from each other. In 802.1AS, when a device doesn’t receive announce messages within the timeout period, it assumes the grandmaster role regardless of its priority settings.

Troubleshooting Steps

1. Verify Network Connectivity

First, ensure your Ethernet connection is properly established:

Check that both boards can ping each other
Verify the Ethernet link is up and running at the expected speed
Test with standard IEEE 1588 to confirm basic PTP functionality works

2. Check 802.1AS Multicast Address

Your configuration uses the correct 802.1AS multicast address 01:80:C2:00:00:0E(1), but verify that both network interfaces can send/receive multicast traffic to this address.

3. Adjust Timeout Values

Try increasing the announce receipt timeout to allow more time for message exchange:

syncReceiptTimeout 6

4. Verify Transport Specific Field

Ensure both configurations have the same transportSpecific 0x1 value, which is correct for 802.1AS(1).

5. Debug Message Exchange

Add verbose logging to see the actual message exchange:

ptp4l -i eth0 -p /dev/ptp0 -f /etc/linuxptp/gPTP.cfg -m -l 7

Alternative Configuration Approach

Since you mentioned IEEE 1588 works correctly, you might want to leverage Toradex’s TSN testing approach. The Toradex documentation shows that their standard Yocto Linux BSP includes linuxptp tools for IEEE 802.1AS clock synchronization testing(1).

For Toradex modules, you can install the necessary tools in the Yocto environment by adding to your local.conf(1):

IMAGE_INSTALL_append = " iproute2-tc"

Hardware Considerations

Since you’re using i.MX95 Verdin EVK boards, ensure you’re using the correct device tree configuration. The documentation shows specific device tree requirements for different image versions(2).

For the latest release images, use:

setenv fdtfile imx95-19x19-verdin-lt8912.dtb

Next Steps

Start with one board configured as master with higher priority (lower values)
Start the slave board first, then the master
Monitor the logs for announce message reception
If issues persist, test with a managed switch that supports 802.1AS

The key is ensuring proper announce message propagation between the devices in your point-to-point setup.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

rudhi.tx · April 9, 2026, 5:12pm

HI @kosisochukwu,

I am not familiar with implementing PTP; however, I did some research to find any information. I don’t find any documentation specifically from NXP on implementing PTP Master-slave configuration. However, I find this guide from TI on PTP master - slave configuration examples. Could you please check it out: 3.2.2.11.3.2.2.1. PTP — Processor SDK AM64X Documentation