Ethernet hardware PTP support not working

[rogergreen2003]

I have been making several tests to validate the use of the MA35D1 to transport very low latency audio (<= 1ms) over ethernet, which needs a high reliable clock synchronization, hardware assisted method, using IEEE1588 protocol (PTP).

Using the latest 5.10 linux kernel from OpenNuvoton, and the 10/100 ethernet port of the NuMaker-IoT-MA35D1-A1 board (eth1), the output of ethtool is:

/ # ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
        hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
        software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
        hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
        software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
        software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
        hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off                   (HWTSTAMP_TX_OFF)
        on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
        none                  (HWTSTAMP_FILTER_NONE)
        all                   (HWTSTAMP_FILTER_ALL)
        ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
        ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
        ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
        ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
        ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
        ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
        ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
        ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
        ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)

Which is correct: it shows that RX and TX HW TIMESTAMP is available on this interface. But running ptp4l, it doesn't synchronize to other masters if launched as slave, and other slaves don't synchronize to it if launched as master.

After some more verbose debugging, It seems that there is a problem with the reception of PTP events in the driver, but I don't know how to fix it because I haven't the complete technical information about this IP module.

The driver is based on the stmmac implementation of STMicroelectronics, which is used in a lot of other devices, and we are sure the PTP works fine on some of them, as in the STM32MP1.

Could someone try to fix this issue, please?

[rogergreen2003]

Finally, I have found where is the problem when using PTP on this platform: rx multicast filtering is not working.

By default, multicast filtering is used to avoid processing all multicast traffic, so only the joined multicast addresses should be filtered in hardware. This filter uses a hash capability of the stmmac driver.

The problem comes when looking the HW Feature Register: bit 4 (HASSEL) is 0, which means that this implementation lacks the HW multicast filtering. It can be seen easily running cat /sys/kernel/debug/stmmaceth/eth0/dma_cap | grep -i "Hash Filter:"

    Hash Filter: N

PTP implementation used in typical low latency audio protocols (DANTE, RAVENNA) uses multicast addressing, so it fails on this platform.

The solution, then, is easy: to disable the HW filter of stmmac with ifconfig eth0 allmulti

[ychuang3]

We have also been debugging the PTP issue for a while. Thank you for the information you provided, which has also resolved the problem we've been experiencing with PTP not functioning properly. After setting 'ifconfig allmulti,' our PTP tests are now functioning correctly. It works.

Best Regards, Jacky Huang