daniel-p-carvalho opened a new pull request, #3782: URL: https://github.com/apache/nuttx-apps/pull/3782
**Depends on #3779** (not yet merged). This branch is built on top of `fix/ptpd-e2e-delay-drift`, so the diff below includes that PR's 4 commits until it merges into `master` - only the last 6 commits below are new to this PR. Companion kernel/driver-side changes (hardware TX timestamping, `SIOCS_PTP_ADJFREQ`/`SIOCS_PTP_ADJPHASE` ioctls) are in [apache/nuttx#20148](https://github.com/apache/nuttx/pull/20148). ## Summary Why change is necessary (fix, update, new feature)? `apps/netutils/ptpd` only implemented the E2E delay mechanism (`Delay_Req`/`Delay_Resp`). The IEC/IEEE 61850-9-3:2016 profile (the target profile for substation automation) requires the P2P (peer-delay) mechanism instead, so a real GPS-disciplined Grandmaster running that profile (Toradex Colibri iMX7 + `linuxptp`'s `ptp4l`) could not be synchronized against without first switching it to E2E for testing purposes (which is how #3779 was validated). This PR adds P2P support and, together with apache/nuttx#20148, lets the PTP hardware counter - and therefore the physical PPS output pin - actually phase-lock onto the master instead of getting stuck at a fixed offset after the first sync. What functional part of the code is being changed? `apps/netutils/ptpd/ptpd.c`, `apps/netutils/ptpd/ptpv2.h`, `apps/include/netutils/ptpd.h`, `apps/system/ptpd/ptpd_main.c` - the PTP client path, delay-mechanism selection, and hardware clock discipline. How does the change exactly work (what will change and how)? 1. `Fix Delay_Resp consumption by sendmsg and use canonical path delay.` - prep fix in the existing E2E path before adding P2P. 2. `Implement IEEE 1588 peer-to-peer (P2P) delay mechanism.` - `Pdelay_Req`/`Pdelay_Resp`/`Pdelay_Resp_Follow_Up` message types, `-P` CLI flag (mutually exclusive with `-E`), a `PTP_DELAY_NONE`/`_E2E`/`_P2P` config enum replacing the old `bool delay_e2e`, requester and responder logic, and dispatch in the RX loop. Verified against IEEE 1588-2019 clause 11.4.2: the two-step responder always operates as the standard's "Option B" (actual t2/t3 carried in the timestamp fields, not the `correctionField`), and the requester's two-step path reconstructs t2/t3 by adding the received `correctionField`, so the `meanPathDelay = ((t4-t1) - (t3-t2)) / 2` formula closes correctly against a peer using either Option A or Option B. The one-step requester path matches clause 11.4.2(d)(3) directly. `delayAsymmetry` compensation (optional in the standard) is not implemented - not applicable to the bench's symmetric electrical link. 3. `Warn when P2P is selected without CONFIG_SCHED_TICKLESS.` - P2P's independent, physical-link-rate `Pdelay_Req` cadence needs tickless timing precision to be meaningful; warn instead of silently degrading. 4. `Query hardware TX timestamp via SIOCG_TX_HW_TIMESTAMP.` - consumes the ioctl added in apache/nuttx#20148 so `Pdelay_Req`'s t1 (and the E2E path's `Delay_Req` t1) reflect the actual hardware TX time instead of a pre-send software estimate. 5. `Drive PTP hardware frequency trim via SIOCS_PTP_ADJFREQ.` - consumes the ioctl from apache/nuttx#20148 so the local clock's frequency-drift estimate also disciplines the MAC's own hardware counter, not just software `CLOCK_REALTIME`. 6. `Phase-lock the MAC's PTP hardware counter to the master.` - the real fix behind the PPS-offset bug found while validating this on the HIL bench: the initial clock jump omitted `path_delay_ns` from both the `CLOCK_REALTIME` step and the hardware phase nudge (`SIOCS_PTP_ADJPHASE`), so the hardware counter (and PPS edge) landed at, and then stayed at, an arbitrary permanent offset. The jump now targets the master's timestamp directly when hardware timestamping is enabled (`local_timestamp` lives in the hardware counter's own free-running epoch, not `CLOCK_REALTIME`, so subtracting it was never meaningful), and `SIOCS_PTP_ADJFREQ` now carries a phase-proportional term (not just frequency drift) so the hardware counter keeps converging between jumps instead of only matching the master's rate. ## Impact - New `-P` CLI flag for `ptpd`, mutually exclusive with `-E`; existing `-E`/no-flag behavior unchanged. - `struct ptpd_config_s.delay_e2e` (bool) becomes `delay_mechanism` (enum `PTP_DELAY_NONE`/`_E2E`/`_P2P`) - source change for anything constructing this struct directly (in-tree, only `ptpd_main.c` does). - Hardware timestamping / `SIOCS_PTP_ADJFREQ`/`SIOCS_PTP_ADJPHASE` paths are all gated behind `state->config->hardware_ts` and the corresponding `#ifdef SIOCG_TX_HW_TIMESTAMP` / `#ifdef SIOCS_PTP_ADJFREQ` / `#ifdef SIOCS_PTP_ADJPHASE`; no effect on targets without apache/nuttx#20148 or without hardware timestamping enabled. ## Testing Same HIL bench as apache/nuttx#20148: STM32F4Discovery (`stm32f4discovery-ext` custom board) as PTP slave against a real GPS-disciplined Grandmaster (Toradex Colibri iMX7 + X-NUCLEO-GNSS1A1, `linuxptp`'s `ptp4l`, IEC/IEEE 61850-9-3 P2P profile). - `ptpd -2 -s -S -r -B -P -i eth0` on the Discovery; `ptpd -t <pid>` shows `path_delay_ns` populating via the P2P path. - `pmc -u -b 0 "GET PORT_STATS_NP"` on the Grandmaster confirms `tx_Pdelay_Resp`/`rx_Pdelay_Req` incrementing. - Oscilloscope: the Discovery's hardware `ETH_PPS_OUT` (`PB5`) phase- locks onto the Grandmaster's 1PPS edge after the daemon's initial clock jump and stays aligned, instead of freezing at a fixed offset. Host: Ubuntu 24.04, `arm-none-eabi-gcc` toolchain, `stm32f4discovery-ext:ethraw` custom out-of-tree board config. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
