IEEE 802.1AS Transparent Clock not working on STM32MP257 ETHSW (TTTech DEIP): correctionField stays 0 on forwarded Sync/Follow_Up

[Tommy1234]

Environment

• Board: ATK-DLMP257B (STM32MP257), ST official Yocto image (X-LINUX-TSNSWCH)
• Kernel 6.6.48
• deptp 2.5.2 (Flexibilis DE-gPTP Edge daemon)
• Driver: edgx_pfm_lkm (TTTech EDGE Platform Host Interface Driver)

Goal

Configure the on-board switch as an IEEE 802.1AS Peer-to-Peer Transparent Clock, so that forwarded Sync/Follow_Up frames carry the residence time in their correctionField.

Configuration (factory default, unmodified)

 

<Interface name="sw0p2"><profile>gptp</profile><mode>tc</mode><delay>p2p</delay></Interface>
<Interface name="sw0p3"><profile>gptp</profile><mode>tc</mode><delay>p2p</delay></Interface>
<Basic><one_step_clock>0</one_step_clock></Basic>

deptp.service is active. deptp_tool --get-tc-port-dataset returns valid data (faulty false, peer-mean-path-delay ≈ 145 ns), while deptp_tool --get-port-dataset returns error rejected — confirming that deptp is actually running in TC mode.

Topology

GM (PC) — sw0p2 [board] sw0p3 — Slave (PC). Both endpoints run linuxptp 4.0 with network_transport L2, delay_mechanism P2P, transportSpecific 1, and -H (hardware timestamping). The measured P2P path delay is stable at 152 ns ± 1.

Observations

1. Simultaneous captures on both sides of the board, matched by sequenceId: the same Sync/Follow_Up frames (seq 19246–19252) were captured at both ingress and egress, and the correctionField is byte-for-byte identical — all zero (20 frames, 00 00 00 00 00 00 00 00).
2. The board's CPU only ever sees Pdelay (249 frames each on sw0p2 and sw0p3, all PdelayReq/PdelayResp/PdelayRespFU). Forwarded Sync/Follow_Up never reach the CPU at all.
3. The correction path itself is alive: after setting <output_delay>1000</output_delay>, the board's own outgoing Pdelay_Req carries corr=65536 (1 ns) — but in the same capture, the forwarded Sync/Follow_Up still show 0.
4. The kernel repeatedly logs EDGX-BR-CORE: edgx_com_ts_find_tx(): TX timestamp lost (~8/s, matching deptp's Pdelay_Req rate), with a corresponding ptp_port_pdelay_measurement: Missing timestamps on the deptp side.

Already tried — none of these change the result

• <one_step_clock>1</one_step_clock>
• syncmode="1588" in /etc/modprobe.d/edgx_sw_core.conf (dmesg confirms Synchronisation mode (syncmode): 1588 after reboot; correctionField still 0)
• One-step vs. two-step (flag 0x0000 / 0x0200) × transportSpecific 0 / 1 — all four combinations
• <profile>ptp</profile>: rejected — deptp exits with status 1; <mode>BC</mode>: libptp.so.0 only exports PTP_PORT_TYPE_OC / PTP_PORT_TYPE_TC, so there is no boundary clock support
• Frames sent to 01:80:C2:00:00:0E are not forwarded by the board (5 injected, 0 received at the far end)
• Full strings scan of /boot/6.6.48/kernel/**/*.ko for residence|correctionField|transparent clock: zero matches. In edgx_pfm_lkm.ko the only PTP-related strings are syncmode and timestamp.

Questions

1. Does the STM32MP2 ETHSW support an 802.1AS transparent clock (residence-time correction) on the forwarding path?
2. If yes, what is the correct configuration? Is this feature implemented in the deptp 2.5.2 / edgx_pfm_lkm shipped in X-LINUX-TSNSWCH?
3. If not, is it planned for a future release?

Contact

[e-mail]

[Christophe Guibout]

Hello ​@Tommy1234,

deptp is supposed to handle onestep PTP, but the TTTech switch driver doesn’t support this, and returns (-ERANGE). Today, only Tx_OFF/Tx_ON ((two-step) are implemented:

The edgx_pfm_lkm kernel driver rejects the request — edge_com_ts.c::edgx_com_ts_cfg_set() :

switch (cfg.tx_type) {
case HWTSTAMP_TX_OFF:
case HWTSTAMP_TX_ON:
    pts->hwts_cfg.tx_type = cfg.tx_type;
    break;
default:
    return -ERANGE;   => because HWTSTAMP_TX_ONESTEP_SYNC not handled
}

 

We raised a ticket to TTTech, and I will keep you in touch as soon as they reply.

BR,

Christophe

[Tommy1234]

Thank you very much for your detailed explanation. I have already tested PTP in two-step mode. However, the correctionField still does not populate the residence time and peer delay values. My main concern is that the value in the correctionField of the transparent clock remains zero all the time, which is what I am struggling with.

[Christophe Guibout]

Hello ​@Tommy1234,

Here are more explanations, hope it will help:

802.1AS doesn't define a transparent clock. 
It specifies a PTP Relay which is like boundary clock (has port states) but does the corrections in a way that from a synchronization point of view it looks like a transparent clock.
 
Related to this, only valid configuration for 802.1AS interface in DE-PTP is:
<Interface name="sw0p2">
<profile>gptp</profile>
<mode>ordinary</mode>
<delay>p2p</delay> // or common_p2p
</Interface>
 
The timestamp in 802.1AS is taken at the external ports, and there is no IP support to inject timestamps to the sent sync frames at the external ports. One-step timestamp support in IP is only supported at port 0 (port towards cpu) and this cannot be used in 802.1AS profile.
 
Residence time correction is handled in SW (DE-PTP) in 2-step mode, which is also the default option in 802.1AS standard uses. (one-step sync mode for 802.1AS-2020 is an optional mechanism, this we don't support)