I am using Robert Nelson’s omap-image-builder to create an image with the linux-image-5.10.65-ti-rt-r24 kernel. Looking at the ti-linux-kernel-dev/patches/ti_sdk_am3x_release_defconfig file, I see that the kernel was built with HW timestamping not set (# CONFIG_NETWORK_PHY_TIMESTAMPING is not set). Is there an existing way to use the omap-image-builder to kick off a build of the kernel where I can patch this configuration to set this value? Or is it best to include the ti-linux-kernel-dev repo as a submodule and kick off a build of that before running the omap-image-builder? Is there any other configurations needed to enable this feature?
HI @MMetelko sadly no not really a good way…
Best to do a merge request here; Pull requests · RobertCNelson/ti-linux-kernel-dev · GitHub
But, i’m looking at it right now…
Build testing:
diff --git a/patches/defconfig b/patches/defconfig
index df96363..f9ef848 100644
--- a/patches/defconfig
+++ b/patches/defconfig
@@ -1034,7 +1034,8 @@ CONFIG_IPV6_SEG6_BPF=y
CONFIG_NETLABEL=y
# CONFIG_MPTCP is not set
CONFIG_NETWORK_SECMARK=y
-# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
+CONFIG_NET_PTP_CLASSIFY=y
+CONFIG_NETWORK_PHY_TIMESTAMPING=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=m
@@ -3198,10 +3199,6 @@ CONFIG_PPS_CLIENT_GPIO=m
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
-
-#
-# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
-#
# end of PTP clock support
CONFIG_PINCTRL=y
diff --git a/version.sh b/version.sh
index 1a4d950..8ba324c 100644
--- a/version.sh
+++ b/version.sh
@@ -42,7 +42,7 @@ KERNEL_REL=5.10
KERNEL_TAG=${KERNEL_REL}.65
kernel_rt=".65-rt53"
#Kernel Build
-BUILD=${build_prefix}27.1
+BUILD=${build_prefix}27.2
#v5.X-rcX + upto SHA
#prev_KERNEL_SHA=""
Merged: config: enable CONFIG_NETWORK_PHY_TIMESTAMPING · RobertCNelson/ti-linux-kernel-dev@9dc3956 · GitHub
Regards,
Hi @RobertCNelson,
Thanks!! I will switch to 5.10.65-ti-rt-r28 release. Is there any particular reason this was not originally enabled in the image? Just curious. We are doing time sensitive work and appreciate having the HW timestamping available.
Hi @MMetelko , i’d have to look into our git history… But the 5.10.x branch was branched from our 5.4.x branch, so if there was any build issues early on, it would have got disabled… Thus now someone noticed it was disabled. 
Regards,
Hi @RobertCNelson,
Thank you so much for your quick response on this! It is a pleasure to work with you virtually.
and 5.10.65-ti-rt-r28 is now available in the repo.
Regards,
Hi @RobertCNelson ,
I think the CONFIG_PTP_1588_CLOCK flag also needs to be set. Here is what I am currently getting with the 5.10.65-ti-rt-r28 kernel.
ptp4l -i eth0 -m
ptp4l[1138.778]: interface 'eth0' does not support requested timestamping mode
failed to create a clock
ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none
I found “PPS signal setup on BeagleBone Black platform” reference (which is older, but hopefully still relevant) that indicates the following kernel configurations:
The linux kernel has to be compiled with the following configuration parameters:
CONFIG_PPS=y (required)
PTP_1588_CLOCK=y (required)
CONFIG_NETWORK_PHY_TIMESTAMPING=y (optional - not used in BeageBone Black)
The first parameter enables the PPS subsystem in the kernel, the second adds support for
PTP clocks as character devices (e.g /dev/ptp0 - -this represent the HW clock in the Ethernet
controller on the BeagelBone), and finally the third allows timestamping of the network
packets by PHYs (this can be more accurate compared to MAC time stamps, however it
introduces some other difficulties, like communication with the PHY or timestamp - packet
association… ).
@RobertCNelson Would you like me to fork RobertCNelson/ti-linux-kernel-dev to create a new kernel with the CONFIG_PTP_1588_CLOCK=y? Or is it best for you to make this change?
Kindest regards,
Mary
Hi @MMetelko sorry, been hacking on a lot of stuff lately, forgot to reply:
5.10.65-ti-r29 has that config enabled:
Regards,
@RobertCNelson Thanks, now I know to look for the change before bugging you again. I truly appreciate it. I will integrate that with our system and test it out.
When I tested 5.10.65-ti-r29 kernel image, I was still not able to see the HW timestamping enabled. I found TI’s Processor SDK Linux page that discussed Kernel Drivers - specifically Common Platform Time Sync (CPTS) module. This indicates that another configuration was needed: CONFIG_TI_CPTS=y. I built a local copy of the ti-linux-kernel-dev (branch ti-linux-rt-5.10.y) modifying that configuration to enable it. Then I tested the changes and it works I now get the following (desired output):
$ ethtool -T eth0
Time stamping parameters for eth0:
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)
Would you mind creating a new kernel release for 5.10-ti-rt that includes this flag? Then I can go back to using the automated build approach that you use (omap-image-builder).
Thanks in advance,
@MMetelko
@MMetelko thanks for testing! enabled: config: enable CONFIG_TI_CPTS · RobertCNelson/ti-linux-kernel-dev@366f936 · GitHub
just be available in a few hours…
Edit: and now pushed out!
Regards,
I have built ti-linux-rt-5.10.y/Debian 11 following Debian: Getting Started with the BeagleBone Black and boot it on my BBE. Unfortunately same issue:
debian@beaglebone:~$ ethtool -T eth0
Time stamping parameters for eth0:
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)
I’m wondering why there is a zero “PTP Hardware Clock: 0” instead of a “none”. I checked defconfig file and CONFIG_TI_CPTS is set to y.
Is this something related only to BBE?
The 4.14 linux on the eMMC of the recently purchased BBE shows the same issue.
if you want “none”… disable CONFIG_TI_CPTS…
Regards,
Well, I would prefer a “1”, but thanks for the explanation 
So what can be the reason for the zero?
I checked the same SD card (ti-linux-rt-5.10.y/Debian 11) on a BBB, same result: 0 as well as with the eMMC 4.9.56-ti-r70 on the BBB.
Excuse me, but I was convinced that the BBB resp. BBE had a PHC, doesn’t it?
Sorry i’m not an expert on PTP…
debian@bbb-pwr01-ser09:~$ uname -r
4.19.94-ti-r73
debian@bbb-pwr01-ser09:~$ ethtool -T eth0
Time stamping parameters for eth0:
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)
debian@bbb-pwr01-ser09:~$ udevadm info /dev/ptp0
P: /devices/platform/ocp/4a100000.ethernet/ptp/ptp0
N: ptp0
L: 0
E: DEVPATH=/devices/platform/ocp/4a100000.ethernet/ptp/ptp0
E: DEVNAME=/dev/ptp0
E: MAJOR=249
E: MINOR=0
E: SUBSYSTEM=ptp
Pretty sure… PTP Hardware Clock: 0 → /dev/ptp0… the 0 is just the first reference…
debian@bbb-pwr01-ser09:/sys/class/ptp$ tree
.
└── ptp0 -> ../../devices/platform/ocp/4a100000.ethernet/ptp/ptp0
1 directory, 0 files
debian@bbb-pwr01-ser09:/sys/class/ptp$ cd ptp0
debian@bbb-pwr01-ser09:/sys/class/ptp/ptp0$ tree
.
├── clock_name
├── dev
├── device -> ../../../4a100000.ethernet
├── max_adjustment
├── n_alarms
├── n_external_timestamps
├── n_periodic_outputs
├── n_programmable_pins
├── power
│ ├── async
│ ├── autosuspend_delay_ms
│ ├── control
│ ├── runtime_active_kids
│ ├── runtime_active_time
│ ├── runtime_enabled
│ ├── runtime_status
│ ├── runtime_suspended_time
│ └── runtime_usage
├── pps_available
├── subsystem -> ../../../../../../class/ptp
└── uevent
3 directories, 18 files
Regards,
Thank you so much Robert!
Silly me. I interpreted the zero as being the amount of PHCs, but that’s silly, as one Ethernet device would have either none or one PHC. Now also the “none” being different to “0” makes absolutely sense.
I get the same output as you. All is fine.
Sorry for bugging you.