Troubleshooting PTP Hardware Timestamping on Jetson Orin NX

Problem Details

An application requiring IEEE 1588 Precision Time Protocol synchronization on a Jetson Orin NX module fails at the first check: ethtool -T eth0 reports no hardware timestamping support on the on-board Ethernet interface. The platform under test is JetPack 5.1.1, L4T 35.3.1. A second engineer independently confirmed the same behavior on the same class of developer board after selecting the module specifically for its expected PTP capability.

The vendor response to the report was a single sentence: "Software PTP is not supported on Orin." That statement is ambiguous and must not be read as a complete answer. Two mutually exclusive readings exist:

Root Cause Analysis

On Linux, IEEE 1588 hardware timestamping is only usable when every layer below reports capability. Missing any one of them produces exactly the symptom seen here — ethtool -T listing only software modes.

1. MAC timestamping unit present and enabled. The Ethernet MAC must contain a 1588 timestamp block and the block must be clocked and released from reset.
2. Device tree describes the timestamp clock. The MAC node must supply the PTP reference clock and any timestamp-related properties the driver expects. If the node omits them, most Linux MAC drivers silently register the interface without a PTP hardware clock (PHC).
3. Driver registers a PHC. The driver must call into the kernel PTP clock subsystem, creating /dev/ptpN and returning a valid clock index from the ETHTOOL_GET_TS_INFO ioctl.
4. Kernel config includes the PTP subsystem. CONFIG_PTP_1588_CLOCK must be built in or as a module; a defconfig without it removes the ioctl path entirely.
5. PHY path does not break timestamps. A PHY-side timestamper, if used, must be bound; RGMII delay and MDIO issues will not remove timestamping but will corrupt accuracy.

In this case the reported failure is at layer 3 or above: the interface is up and passing traffic, but the timestamping information block is empty. That is consistent with either a driver that never registers a PHC or a kernel without the PTP subsystem — and consistent with the vendor's position that the feature is not offered on this platform.

Diagnostic Procedure

Run these in order on the target. Record the exact output; it is the evidence you will need if you escalate to the module vendor.

1. Query timestamping capabilities.

   ethtool -T eth0

   A PTP-capable interface reports hardware-transmit, hardware-receive, hardware-raw-clock, a PTP Hardware Clock: index >= 0, and non-empty Hardware Transmit Timestamp Modes / Hardware Receive Filter Modes. A non-capable interface reports only software-transmit, software-receive, software-system-clock and PTP Hardware Clock: none.
2. Check for a PHC character device.

   ls -l /dev/ptp*
   

   No node means no registered hardware clock, regardless of what any documentation claims.
3. Confirm the kernel PTP subsystem exists.

   zcat /proc/config.gz 2>/dev/null | grep -E 'PTP_1588|NETWORK_PHY_TIMESTAMPING'
   grep -r ptp /proc/modules

   If /proc/config.gz is absent, check the config file shipped with your kernel source tree instead.
4. Read driver messages at bring-up.

   dmesg | grep -iE 'eth0|ptp|1588|timestamp'

   Drivers that support 1588 normally log PHC registration. Absence of any PTP line, or an explicit "PTP not supported" message, closes the question at the driver level.
5. Identify the exact driver and interface.

   ethtool -i eth0

   Capture driver name, driver version, firmware version, and bus info. Vendor support cannot act on a report without these.
6. Test with linuxptp directly.

   ptp4l -i eth0 -m -H
   

   -H forces hardware timestamping. If the capability is missing, ptp4l exits immediately with an ioctl/timestamping error rather than degrading silently. That failure message is a clean, quotable artifact for a support ticket.

Solution Paths

Choose based on what step 1-6 returned and on your accuracy budget.

External timestamping options when the SoC MAC cannot do it

1. Add a PTP-capable NIC on PCIe or USB 3.x. A discrete NIC with its own 1588 timestamp unit registers its own PHC, independent of the SoC MAC. Verify with the same ethtool -T check on the new interface before committing. Confirm the NIC's Linux driver is present in your L4T kernel or buildable against it.
2. Use a hardware PPS discipline. Terminate PTP on a separate device (industrial switch with boundary-clock function, or a dedicated PTP-to-PPS converter) and feed 1PPS plus a serial or GPIO time-of-day message into the Jetson. Discipline the system clock with a PPS-aware daemon. This decouples the accuracy of your time base from the SoC MAC entirely.
3. Timestamp in the peripheral, not the CPU. If the requirement is correlating sensor data rather than disciplining the OS clock, move the timestamp into the camera/sensor trigger domain and use the Jetson only for logging. This is usually the lowest-risk redesign.

Verification

After applying a fix or a fallback, verify quantitatively — do not accept "ptp4l started without error" as proof.

1. Confirm capability, not just process start. ethtool -T <iface> must show hardware-transmit, hardware-receive, and a valid PHC index.
2. Watch ptp4l convergence. With -m, ptp4l prints periodic lines containing master offset, freq, and path delay. A healthy hardware-timestamped slave settles to a small, stable offset with a slowly varying frequency correction. Large or oscillating offsets indicate asymmetric delay, a non-transparent switch in the path, or software timestamping in disguise.
3. Check state transitions. The port must reach SLAVE (or MASTER) and stay there. Repeated UNCALIBRATED to SLAVE cycling points to announce timeouts or packet loss, not timestamping.
4. Discipline the system clock and verify it. Run phc2sys to slew CLOCK_REALTIME from the PHC, and confirm the reported offset stays bounded across a long soak, not just at startup.
5. Measure against an independent reference. The only conclusive test is a physical one: output a periodic pulse from the target and from the grandmaster domain, and compare the edges on a scope or a time-interval counter. Log the peak-to-peak deviation over the full operating temperature and network-load profile.
6. Soak under load. Software timestamping degrades sharply with CPU and interrupt load. Repeat the measurement with the application's real workload running; a result taken on an idle board is not representative.

Escalation Package

If you take this back to the module vendor, submit all of the following in one message so the question cannot be deflected:

• Exact module part number, carrier board, and revision
• BSP identification — in this case JetPack 5.1.1 / L4T 35.3.1 — plus uname -a
• Full ethtool -i and ethtool -T output for the interface
• ls -l /dev/ptp* result
• Filtered dmesg for the interface and PTP subsystem
• The exact ptp4l -H failure message
• One direct question: "Does this module part number expose IEEE 1588 hardware timestamping on this interface in any released BSP, yes or no, and if yes, in which release?"

A yes/no answer against a specific part number is the deliverable. Anything less leaves the schedule risk open.

FAQ