daniel-p-carvalho opened a new pull request, #20148:
URL: https://github.com/apache/nuttx/pull/20148
## Summary
Why change is necessary (fix, update, new feature)?
Getting `apps/netutils/ptpd` hardware-syntonized to a real,
GPS-disciplined PTP Grandmaster (Toradex Colibri iMX7 running
`linuxptp`'s `ptp4l`, IEC/IEEE 61850-9-3 P2P profile) against an
STM32F4Discovery required several pieces of kernel/driver support that
didn't exist yet: hardware TX timestamping (RX timestamping already
existed but had an ordering bug), a way for the PTP daemon to trim the
MAC's own hardware clock frequency and phase (not just the software
`CLOCK_REALTIME`), and a couple of unrelated bugs that only surfaced
once the board was driven hard enough by this workload (a tickless
timer race, a network self-transmit loopback false positive, and a
gap in `CONFIG_SCHED_TICKLESS` + `CONFIG_CLOCK_TIMEKEEPING` wall-time
slewing). This PR is the kernel/driver side; the PTP daemon side
(peer-delay support, ioctl consumption) is a companion, not-yet-opened
`apache/nuttx-apps` PR building on the already-open #3779.
What functional part of the code is being changed?
- `arch/arm/src/common/stm32/stm32_eth_m3m4_v1.c` (+ `Kconfig.eth`):
hardware TX timestamping, direct hardware-counter RX/TX timestamp
delivery, `SIOCS_PTP_ADJFREQ`/`SIOCS_PTP_ADJPHASE` support,
self-transmit reception disable, RX timestamp/`pkt_input()` ordering
- `net/netdev/netdev_ioctl.c` + `include/nuttx/net/ioctl.h`: three new
socket ioctls (`SIOCG_TX_HW_TIMESTAMP`, `SIOCS_PTP_ADJFREQ`,
`SIOCS_PTP_ADJPHASE`)
- `net/pkt/*`: self-transmit loopback filter false-positive fix
- `arch/arm/src/common/stm32/stm32_tickless_m3m4_v1.c`: TIM2
compare-match race fix
- `sched/clock/clock_timekeeping.c`, `sched/sched/sched_processtickless.c`:
drive wall-clock adjtime slewing from the tickless tick handler
- `drivers/timers/Make.defs`: build path for PTP clock drivers
How does the change exactly work (what will change and how)? Twelve
commits, each independently described in its own message:
1. `drivers/timers: Add TMRDEPPATH/TMRVPATH for PTP clock drivers.`
2. `arch/arm/stm32: Convert RX hardware timestamp before pkt_input().`
— fixes every packet-socket RX timestamp being off by one frame
3. `net/pkt: Require matching length for self-transmit loopback filter.`
4. `arch/arm/stm32: Disable reception of self-transmitted frames.`
— sets `ETH_MACCR_ROD`, no-op in full-duplex
5. `sched: Drive wall-clock adjtime slewing from the tickless tick handler.`
— builds on top of already-merged upstream fixes for the
`adjtime()` clamp sign/consumption bug (5db3aa9e93, e37509e00a);
this adds the missing periodic driver for `CONFIG_SCHED_TICKLESS`
6. `arch/arm/stm32: Fix TIM2 compare-match race in tickless timer driver.`
— could hang any blocking wait depending on a tickless wakeup
7. `net/netdev: Add SIOCG_TX_HW_TIMESTAMP socket ioctl command.`
8. `arch/arm/stm32: Support hardware transmit timestamping.`
9. `net/netdev: Add SIOCS_PTP_ADJFREQ socket ioctl command.`
10. `arch/arm/stm32: Support PTP hardware frequency trim via
SIOCS_PTP_ADJFREQ.`
11. `net/netdev: Add SIOCS_PTP_ADJPHASE socket ioctl command.`
12. `arch/arm/stm32: Support PTP hardware phase alignment via
SIOCS_PTP_ADJPHASE.`
13. `fix(stm32_eth): deliver direct hardware counter timestamps for PTP.`
— RX/TX timestamps for `CONFIG_STM32_ETH_TIMESTAMP_RX`/`_TX` now
reflect the MAC's own hardware counter directly instead of being
synthesized against `CLOCK_REALTIME` (which starts at an arbitrary
boot-time phase when `CONFIG_STM32_ETH_PTP_RTC_HIRES` is not set),
letting a PTP daemon actually phase-lock the hardware counter (and
therefore the physical PPS output pin) to a master
## Impact
- New ioctls (`SIOCG_TX_HW_TIMESTAMP`, `SIOCS_PTP_ADJFREQ`,
`SIOCS_PTP_ADJPHASE`) are additive; no behavior change for existing
callers.
- `stm32_eth_m3m4_v1.c` RX/TX timestamp semantics change only for
boards with `CONFIG_STM32_ETH_TIMESTAMP_RX`/`_TX` enabled without
`CONFIG_STM32_ETH_PTP_RTC_HIRES` (this basic PTP core is shared by
several STM32 F1/F2/F4-family Ethernet MACs).
- `ETH_MACCR_ROD` is now set unconditionally; verified no-op in
full-duplex (the only mode available on the hardware used to test
this), behavior changes only for half-duplex users of this driver.
- `net/pkt` loopback filter change only tightens an existing
false-positive-prone check (additive length comparison).
- `CONFIG_SCHED_TICKLESS` + `CONFIG_CLOCK_TIMEKEEPING` combination:
wall-clock adjtime slewing now actually progresses; no effect
outside that specific Kconfig combination.
- STM32 tickless driver (`stm32_tickless_m3m4_v1.c`): fixes a race
that could hang indefinitely; affects all users of that tickless
timer driver family.
## Testing
HIL bench: STM32F4Discovery (custom out-of-tree board
`stm32f4discovery-ext`, STM32F407VGT6, DP83848C RMII PHY on an
Ethernet baseboard) running as PTP slave via `apps/netutils/ptpd`,
against a real GPS-disciplined PTP Grandmaster (Toradex Colibri iMX7 +
X-NUCLEO-GNSS1A1 GNSS module, `linuxptp`'s `ptp4l`, IEC/IEEE
61850-9-3 P2P delay-mechanism profile) as master.
Verified with a digital oscilloscope comparing the GPS Grandmaster's
1PPS output against the STM32's own hardware-generated `ETH_PPS_OUT`
signal (`PB5`): before this series, the STM32's PPS edge landed at an
arbitrary, permanently-frozen phase offset from the master's edge;
after, it phase-locks onto the master's edge following the daemon's
initial clock jump and stays aligned. Also queried
`pmc -u -b 0 "GET PORT_STATS_NP"` on the Grandmaster to confirm
`tx_Pdelay_Resp`/`rx_Pdelay_Req` (and, for the E2E path validated by
#3779, `Delay_Req`/`Delay_Resp`) counters incrementing as expected.
Host: Ubuntu 24.04, `arm-none-eabi-gcc` toolchain, built and flashed
`stm32f4discovery-ext:ethraw` (custom out-of-tree board config, not
part of this PR) via NuttX's standard `make`/`make flash` flow.
--
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]
