Ok I will take it from the start.
After the timestamp patching on kernel the things not going too well as I expected.
On kernel 5.10 ti rt the timestamp is still not enabled (maybe be buggy).
Capabilities:
** hardware-transmit**
** software-transmit**
** hardware-receive**
** software-receive**
** software-system-clock**
** hardware-raw-clock**
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
** off**
** on**
Hardware Receive Filter Modes:
** none**
** ptpv2-event**
On kernel 5.4 ti rt it seems to be activated the timestamps, but the performance is the same as 5.10 ti rt. So in reality might not be activated.Also the HW timestamp can not be started at all,only Software timestamp is working.
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)**
** ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)**
On kernel 4.19 ti rt the things are a bit better, the timestamps seems to be activated with some better performance but again not to be ok. Also some clocks are activated also.
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)**
** ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)**
** ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)**
With all the kernel when I start ptp4l the ptp0 clock can not be activated or read on bullseye. On buster can be read without any problem.
The latency from the PTP receiver to the BBB is drifting real bad. It is above 0.5ms and on some occasions it completely lose the packets either with HW or software timestamping. I have tried also the free running mode, it is a little better but not correct.
Also when having Unicast delay requests it drops the packets with an error received DELAY_REQ without timestamp on all kernels.
I tried PTP v1 also which can not be started at all and give me the error:
ptp4l[1276.027]: driver rejected most general HWTSTAMP filter
ptp4l[1276.035]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range
ptp4l[1276.039]: port 1: INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
and this is also with tx_timestamp_timeout 400
In conclusion something is not working correct on kernel (drivers or modules) or something is not enabled or need update. I think some investigation should be done. The device has the possibilities but it seems not be working as expected. The same test has be done with BBB industrial with same results. The best solution as it is now is with 4.19 ti rt kernel.
Maybe to be tried is also with
nohz=off
on kernel config to disable the ticks on idle and provide the highest accuracy, if this can be configure on kernel for test.
Regards.