Enable PTP Support of R8125 By Default

[rxdu]

Hello, I'm currently using NanoPC-T6. The onboard R8125 ethernet has PTP support (with hardware timestamping) but it's not enabled by default. I noticed a few other RK3588-based boards also use the same chip for ethernet. I was wondering if it's possible to enable this by default so that there is no need to re-compile the kernel or image just for this feature. Other boards such as Raspberry Pi and Jetson all have this PTP enabled by default so I suppose it won't be too strange to do this.

This feature requires changes in the following two options:

https://github.com/Joshua-Riek/linux-rockchip/blob/linux-5.10-gen-rkr6/drivers/net/ethernet/realtek/r8125/Makefile#L45-L46

[Joshua-Riek]

Sure, I'll do some testing tonight to make sure it does not cause any issues. This kernel can be weird.

[rxdu]

Thanks for your consideration. I did some tests on PTP with NanoPC-T6 in the past few days.

• It seems the existing version of r8125 driver (not sure about the version) is not working correctly with PTP. The behavior is that even though the PTP client (an ouster Lidar in my case) seems to have synchronized with the master (r8125 on nanopc), the sensor data I get from the client always has a non-constant offset.
• I also tried to use the latest r8125 driver (9.011.01) from the official website, but even the normal network connection is not stable. The network hung after a while and I had to re-plug the ethernet cable to recover it.
• The most successful test was with driver version 9.010.01 (which I got from this repo https://github.com/awesometic/realtek-r8125-dkms with commit d506c2fa1f3b62ad336c238dce18fb64fa1fd99b, since I cannot find the link to download older versions from realtek). No change of code was made and I only changed the two PTP options to "y" in the makefile. Everything seems to work fine so far. I will test it for longer and see how reliable it is over a long time.

Honestly, I'm not sure about the root cause of the issue and I don't have sufficient knowledge of the network driver to figure it out. So what I did was mainly testing different versions.

[Joshua-Riek]

Hmmm, I will need to look into this further, I'm cautious about making kernel changes like this.

[rxdu]

Hmmm, I will need to look into this further, I'm cautious about making kernel changes like this.

Totally agree. I noticed the driver was only integrated into the kernel not long ago: https://github.com/Joshua-Riek/linux-rockchip/commit/2944e15740e55b64f0a5dc40978acf929795ea2c It would be great if you could find some time to look into it further.

[rpmocchet]

Hmmm, I will need to look into this further, I'm cautious about making kernel changes like this.

I'm basically on the same situation. Using NanoPC-T6 and in need of PTP functionality enabled. In order to use it, i'm rebuilding realtek driver modifying the settings as rxdu mentioned, using 9.012.03 version instead. Tried with most recent realtek driver version (9.013.02) but I had some wierd behaviours. Nowadays I'm doing some tests in order to have a stable driver version with PTP enabled. Testing both 9.012.03 and 9.013.02 versions.

It would be much easier and productive to me if we have access to a build with the PTP functionality already enabled.

[Joshua-Riek]

I thought this was done already, if not send a pull request.

[rxdu]

Hmmm, I will need to look into this further, I'm cautious about making kernel changes like this.

I'm basically on the same situation. Using NanoPC-T6 and in need of PTP functionality enabled. In order to use it, i'm rebuilding realtek driver modifying the settings as rxdu mentioned, using 9.012.03 version instead. Tried with most recent realtek driver version (9.013.02) but I had some wierd behaviours. Nowadays I'm doing some tests in order to have a stable driver version with PTP enabled. Testing both 9.012.03 and 9.013.02 versions.

It would be much easier and productive to me if we have access to a build with the PTP functionality already enabled.

Version 9.010.01 has been working fine on my boards so far. How about the 9.012.03 and 9.013.02 you've tested? My main issue with 9.010.01 was that I didn't find the source code from the official source. If a newer version works, we can try to integrate the newer one. Otherwise, I will try to search for the source of 9.010.01 again.

[rpmocchet]

Version 9.010.01 has been working fine on my boards so far. How about the 9.012.03 and 9.013.02 you've tested? My main issue with 9.010.01 was that I didn't find the source code from the official source. If a newer version works, we can try to integrate the newer one. Otherwise, I will try to search for the source of 9.010.01 again.

So far so good with 9.012.x. My plans is to test the latest version next week. Probably i did some wrong configuration on conf file for linuxptp services when tried some days before.

About 9.010.x I've only found on github link that you mentioned above, but unfortunately I couldn't build it on my linux env. Got some function parameters errors.

The versions that I have been working I downloaded from Realtek oficial download page: https://www.realtek.com/Download/List?cate_id=584

[rxdu]

Version 9.010.01 has been working fine on my boards so far. How about the 9.012.03 and 9.013.02 you've tested? My main issue with 9.010.01 was that I didn't find the source code from the official source. If a newer version works, we can try to integrate the newer one. Otherwise, I will try to search for the source of 9.010.01 again.

So far so good with 9.012.x. My plans is to test the latest version next week. Probably i did some wrong configuration on conf file for linuxptp services when tried some days before.

About 9.010.x I've only found on github link that you mentioned above, but unfortunately I couldn't build it on my linux env. Got some function parameters errors.

The versions that I have been working I downloaded from Realtek oficial download page: https://www.realtek.com/Download/List?cate_id=584

I will also try to find some time to test the latest version. It would be best if it works so that we can integrate the latest one to this project. Let's try to get this done this time.

[ewaldc]

How are you testing ptp (ptp4l config files, one step/two step, master/slave system types, kernel versions)? I am in the process of finalizing a rewrite of the 8125 driver (fixed a number of defects along the way and nearly doubled the performance) and currently testing PTP without much success. My knowledge of PTP is quite limited, hence struggling to fully understand the PTP driver code without HW documentation. As I understand it currenty, the driver annouces support for all HW filters, but always programs the same PTP control bits (enable all filters?). It would help to know the proper ptp4l master/slave c cammands to make more sense of the TCP dump data. Thanks in advance.

[rxdu]

I use an Ouster Lidar to test the PTP function. I have a note about PTP setup here: https://notes.rdu.im/system/network/time-sync-using-ptp

I don't know how the maintainer of this repository tests all the drivers.

[ewaldc]

@rxdu, thanks so much for your help! I had seen your page, but have not been succesful to execute it on the r8125. For example, when I run phc2sys -w -s CLOCK_REALTIME -c enP3p49s0 on my Orange Pi 5+, I get valid destination clock must be selected. But the bigger issue are the errors I get with ptp4l. The slave sees the master, but immediately posts foreign master not using PTP timescale. That does not seem right. I have attached my configs and log files. The master is a Orange Pi 5+ running Joshua's Ubuntu Noble (version 1025) and the slave is an Intel server also on Noble 24.04 (e1000), both systems are directly coupled to a 2.5GB switch. Master is started with ptp4l -i enP3p49s0 -l 7 -m -H -q -f /etc/linuxptp/ptp4l.conf Slave is started with ptp4l -l 7 -f /etc/linuxptp/ptp4l.conf -i eno1

ptp4l_server.zip ptp4l_slave.zip I have made the mods as per your page, except slaveOnly is now clientOnly and not using systemd. I have not filled in the master MAC addresses for ptp_dst_mac (is it needed?). Ptp4l version is 4.0 On the r8125 kernel side, I see no issues:

[   16.230419] r8125 0003:31:00.0 enP3p49s0: r8125: PTP initialized (master)
[   16.291067] r8125 0004:41:00.0 enP4p65s0: r8125: PTP initialized (master)
[129083.629425] r8125 0003:31:00.0 enP3p49s0: rtl8125_set_tstamp: rx_filter:12
[129487.379668] r8125 0003:31:00.0 enP3p49s0: rtl8125_set_tstamp: rx_filter:12

Filter value 12 means HWTSTAMP_FILTER_PTP_V2_EVENT (calls to rtl8125_set_tstamp).

Hence my question: how have you (succesfully) tested the r8125 driver? I appreciate any help you can provide.

[rxdu]

I have been using the 22.04 release and haven't had time to upgrade to 24.04 Noble yet.

At the very end of "/etc/linuxptp/ptp4l.conf", have you added the lines

# at very bottom of the file
boundary_clock_jbod 1
[eth0]

I'm not sure what changes have been made to the linuxptp package that shipped with Ubuntu Noble. But with the version in Ubuntu Jammy, these two lines should be necessary. Have you tried this? Remember to change the interface name (e.g. eth0) to the actual one in your system.

And a quick search also leaded me to this page: https://unix.stackexchange.com/questions/754755/system-time-synchronization-between-two-hosts-using-linuxptp

Not sure if you have the same issue on your client side.

Anyway, maybe the above two are something you can check again. I will need to find some time to set up my hardware to reproduce the result. I haven't got time to work on this lately.

[ewaldc]

I have dropped the device files from the config files since I pass them on the command line with the -i option. You can see in both log files that the correct devices are being used (eno1 on the slave side and enP3p49s0 on the master). I forget to mention that I had disabled NTP on the slave using timedatectl set-ntp off. Have now also disbled NTP on the master, no change. Thanks for the suggestion. No need to upgrade to 24.02, I can compile the 22.04 version of ptp4l on 24.04. I am guessing that it's more important to have a known good combination of slave/master config. As long as I find the source code for some working r8125 driver, I can compare the code changes. There is a similar problem on the RPI 5...

[rxdu]

I see. You can find the kernel + driver I have been using with my NanoPC-T6 here:

https://github.com/rxdu/linux-rockchip/tree/linux-5.10-gen-rkr6-ptp

And the build scripts:

https://github.com/rxdu/ubuntu-rockchip/tree/v1.28-ptp

[ewaldc]

Thanks again! I looked at your repo (drivers/ptp, commits) but could not really find out what changes you had to make at the kernel level to get PTP to work besides the r8125 driver. I know you mentioned that the default Jammy kernel wasn´t working for you with PTP, and have succesfully tested awesometic's r8125 driver version 9.010.01 (-1 and -2 are equal wrt PTP). I have based my rewrite of the r8125 driver on the same https://github.com/awesometic/realtek-r8125-dkms/commits/master/ driver but based it on the most recent version (9.013.02-2) which has indeed PTP related changes.
Will try to see if the 9.010.01 version of ptp.c provides success and will compare to the 9.013.02-2 version that I am using. Did you make any other changes besides adopting awesometic's r8125 driver (config file, kernel) ?

[rxdu]

The only change I needed to make was to enable the P2P support in the makefile of the r8125 driver. No change was made to other parts of the kernel or filesystem.

[ewaldc]

Thanks for confirming my findings. Tried 9.010.01 (both versions) and it is not working, both as a whole and also when just leveraging the PTP code sections:

ptp4l[10886.515]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[10886.515]: port 1 (enP3p49s0): received link status notification
ptp4l[10886.515]: interface index 2 is up
ptp4l[10892.814]: port 1 (enP3p49s0): announce timeout
ptp4l[10892.814]: port 1 (enP3p49s0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[10892.814]: selected local clock c0742b.fffe.fec6f1 as best master
ptp4l[10892.814]: port 1 (enP3p49s0): assuming the grand master role
ptp4l[10892.815]: port 1 (enP3p49s0): master tx announce timeout
ptp4l[10892.815]: port 1 (enP3p49s0): setting asCapable
ptp4l[10893.814]: port 1 (enP3p49s0): master sync timeout
ptp4l[10894.814]: port 1 (enP3p49s0): master sync timeout
ptp4l[10894.824]: timed out while polling for tx timestamp
ptp4l[10894.824]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[10894.824]: port 1 (enP3p49s0): send sync failed
ptp4l[10894.824]: port 1 (enP3p49s0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[10894.824]: waiting 2^{4} seconds to clear fault on port 1 (enP3p49s0)
ptp4l[10910.824]: clearing fault on port 1 (enP3p49s0)

As I look at the code, this version can´t work with 6.x kernels.

Versions 9.013.02 and 9.012.03 are the same wrt PTP. These versions start OK, until received DELAY_REQ without timestamp occurs. Could be an issue on the e1000e slave or with ptp4l v4.x (e.g. this issue) though...

[ewaldc]

Some progress. Compiling linuxptp 4.4 and setting ptp_minor_version 0 in ppt4l.conf made the received DELAY_REQ without timestamp error disappear. V4.4 includes the compatibility patch which introduces this new config variable ptp_minor_version (defaulting to 1). The Realtek 8125 HW (like RPI4) can not stamp packets that have a non-zero PTP_MINOR version. Next step is to get rid of these slave messages:

ptp4l[372466.012]: port 1 (eno1): have SYNC 127, expecting FOLLOW_UP but got SYNC 128, dropping
ptp4l[372466.399]: port 1 (eno1): delay timeout

At this time, with my limited PTP skills, I can not make sense of this... According to wireshark, the master sends the correct sequence of Sync and Follow up message as UDP multicast, and answers DELAY_REQ with DELAY_RESP. Somehow the slave is not seeing the FOLLOW_UP messages. PTP_wireshark.txt.zip