arch/arm/stm32h7: timestamp the transmitted frames in hardware

[daniel-p-carvalho]

Summary

The STM32H7 MAC can capture a timestamp for every transmitted frame, but the driver only timestamped received frames (#20212). A PTP daemon using the peer-to-peer delay mechanism needs the transmit time of its Pdelay_Req from the hardware.

This PR adds STM32_ETH_TIMESTAMP_TX for the STM32H7, the option that #20148 defines for the legacy STM32 driver, delivered through the generic SO_TIMESTAMPING mechanism of the network stack (#20161): when a frame is flagged for timestamping, the driver keeps a copy of it, sets the timestamp enable bit in its descriptor and, when the transmission is done, reads the timestamp from the descriptor and loops the copy back to the AF_PACKET socket, where recvmsg(..., MSG_ERRQUEUE) returns it. The MAC writes the timestamp over the address of the buffer in the descriptor, so the driver keeps the buffer of these descriptors.

It builds on #20148 and #20212, which are merged, so it is a single commit now.

Impact

• Everything new is under STM32_ETH_TIMESTAMP_TX (default n, needs STM32_ETH_PTP and NET_TIMESTAMP), so boards that do not enable it are not affected. The dependency of the option is widened to include the STM32H7 and STM32H5.
• The timestamps are raw values of the counter of the MAC, as for reception, so the consumer has to use /dev/ptp0 as its clock.
• The apps side, ptpd reading the transmit timestamp from the error queue, is netutils/ptpd: hardware TX timestamps via MSG_ERRQUEUE and egress latency compensation nuttx-apps#3791, which builds on netutils/ptpd: IEEE 1588 P2P delay mechanism, hardware clock phase-lock and outlier rejection nuttx-apps#3782.

Testing

Built for a custom board with an STM32H753 and a DP83848 PHY, with STM32_ETH_TIMESTAMP_TX and STM32_ETH_TIMESTAMP_RX, on the current master, without errors or warnings. ./tools/checkpatch.sh -g upstream/master..HEAD passes.

On hardware, against a GNSS-referenced ptp4l Grandmaster using the IEC/IEEE 61850-9-3 profile, over AF_PACKET, with ptpd -2 -s -H -p /dev/ptp0 -B -P -i eth0 from apache/nuttx-apps#3782 and the transmit timestamps of apache/nuttx-apps#3791:

• The peer delay was 9.0 to 9.4 us in every measurement, the same as the STM32F4 driver of arch/arm/stm32: hardware TX timestamping via SO_TIMESTAMPING #20148 against the same Grandmaster (9.27 us).
• A run of 8.2 hours: 2824 samples of the daemon, none failed, with the clock source valid all the time. The phase difference measured by the daemon averaged 0.94 us (standard deviation 0.32 us, between -1.9 and +4.1 us), with no trend along the run. The drift was 17.3 ppm and stable, and the peer delay averaged 9.5 us.
• The PPS outputs of the STM32H7 and of the STM32F4 board, measured on an oscilloscope against the same Grandmaster, differed by about 20 us at first and by about 1 us in a later measurement.

The end-to-end mechanism, master mode and a longer run were not tested.

[github-actions]

MemBrowse Memory Report

No memory changes detected for:

• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• s698pm-dkit
• stm32-nucleo-f103rb

[xiaoxiang781216]

@daniel-p-carvalho please fix the conflict