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]