Resolving Marvell AQC113C Hardware Timestamp Failures

The number that matters is the transmit-timestamp delivery time. When the driver does not return a timestamp before ptp4l finishes polling, the port reports timed out while polling for tx timestamp, send sync failed, and then changes from MASTER to FAULTY. This is timing, not an interface-index problem: PTP Hardware Clock: 0 identifies /dev/ptp0.

Common fixes that miss the timestamp failure

Several reasonable-looking changes target the wrong layer:

Timestamp path and driver boundary

Hardware PTP requires an unbroken path through the timestamping hardware, kernel driver, socket timestamp API, PHC device, and ptp4l. Normal packet traffic can work at a reported link speed of 10000 while the timestamp path fails. Camera and lidar data therefore prove link operation and throughput, but not timestamp delivery.

The installation reports a Jetson AGX Orin running Linux 5.10.120-tegra. It also reports nvethernet, while a boot message identifies Aquantia AQR113C 6810000.ethernet:00 and says No AQR phy_mode setting in DT. That distinction matters: an SoC Ethernet MAC with an external PHY is not the same driver topology as a discrete PCIe AQC113C NIC. The MAC driver owns the network interface in the former case; the PHY is managed through the kernel PHY layer. The atlantic driver applies to the supported PCIe NIC device model.

Resolve the AQC113C-versus-AQR113C identity before changing drivers. Read the bound driver with ethtool -i lan1, inspect the device path with readlink /sys/class/net/lan1/device/driver, and check whether the Ethernet controller appears as a PCIe function. If the active hardware is an AQR113C PHY attached to the integrated MAC, correcting its device-tree properties is a board integration task; replacing the MAC driver with atlantic is not the repair.

Driver generations also expose controls differently. An AQtion 2.5.5 build exposed aq_enable_ptp, while the described upstream 6.1 atlantic implementation force-enabled PTP and did not expose that module parameter. The absence of aq_enable_ptp therefore does not prove that hardware timestamping is disabled. Development changes tested mainly with the Gen 1 AQC107 also require separate validation on the Gen 2 AQC113C.

Symptoms, quantities, and causes

Baseline capture and topology decision

Capture one baseline before changing the kernel, firmware, device tree, profile, or timeout. This prevents several simultaneous changes from hiding the actual correction.

1. Run ethtool -T lan1. The working capability advertisement includes SOF_TIMESTAMPING_TX_HARDWARE, SOF_TIMESTAMPING_RX_HARDWARE, SOF_TIMESTAMPING_RAW_HARDWARE, PHC index 0, TX modes HWTSTAMP_TX_OFF, HWTSTAMP_TX_ON, and HWTSTAMP_TX_ONESTEP_SYNC, plus the listed PTP receive filters.
2. Run ethtool -i lan1 and inspect the sysfs driver link. Record the driver and bus topology rather than relying on a driver name found elsewhere in dmesg.
3. Review the boot log for the exact controller or PHY identity. Reconcile AQC113C with the reported AQR113C message.
4. If No AQR phy_mode setting in DT remains, compare the deployed device tree with the board vendor’s supported description for that Ethernet port. A live 10 Gb/s link does not prove that every timestamp-related MAC/PHY property is correct.
5. Record the linuxptp revision, configuration file, complete ptp4l log, and any NIC firmware version reported by the supported driver or manufacturer utility. Use the firmware version only after confirming the actual controller identity.

Controlled recovery procedure

1. Restore the driver and device-tree combination that makes lan1 appear and pass traffic. Avoid forcing atlantic onto the device-tree interface until the inventory confirms a supported PCIe NIC.
2. Use the current linuxptp source build that produced stable operation in this installation. Start with the known baseline command:

   sudo ptp4l -i lan1 -f /etc/linuxptp/default.cfg -m

3. Run the test once without jetson_clocks. Record every TX timestamp timeout and port-state transition.
4. As a diagnostic, repeat with --tx_timestamp_timeout 30. A 30 ms window should cover most properly delayed timestamps in the tested scenario. If the timestamp still never arrives, pursue the driver, firmware, or timestamp path rather than continually increasing the timeout.
5. Run sudo jetson_clocks and repeat the identical ptp4l test. This utility raises and stabilizes supported Jetson performance clocks, reducing latency variation caused by dynamic clock scaling. It does not create timestamping capability, but an overnight successful run after enabling it shows that timing and scheduling sensitivity deserve investigation.
6. Separate the two changes that preceded the successful overnight test: the newer linuxptp build and jetson_clocks. Test old versus new linuxptp at the same clock state, then test clocks off versus on with the same binary and configuration.
7. Start phc2sys only after ptp4l remains in its intended state without TX timestamp timeouts. Select source and sink from the clock architecture rather than copying a command blindly.

Profile and clock-direction decisions

With default.cfg, the node entered LISTENING, reached ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES, selected its local clock as best master, and assumed the grandmaster role. It then failed when its Sync transmission did not receive a TX timestamp. That sequence isolates the immediate failure after master selection.

With automotive-master.cfg, entering MASTER directly and not choosing a best master is normal. The automotive profile uses explicit master selection rather than the default best-master voting behavior. Configure every participant for compatible transport, domain, delay mechanism, message intervals, and fixed role before interpreting a missing election as a fault.

The command phc2sys -w -s CLOCK_REALTIME -c lan1 -m -O 0 names CLOCK_REALTIME as the source and lan1 as the destination. That direction can fit a PC acting as time master, where the NIC PHC follows system time. If the PC is instead a PTP slave and the system clock must follow the synchronized NIC PHC, reverse the source and destination. Confirm the required offset between the selected timescales before retaining -O 0; the sensor data reports current_utc_offset 37 while also marking current_utc_offset_valid as 0.

Verification under sensor load

1. Repeat ethtool -T lan1 and confirm that the PHC and advertised hardware TX/RX modes remain present.
2. Run ptp4l through multiple Sync intervals. There must be no timed out while polling for tx timestamp, send sync failed, or transition to FAULTY.
3. Query CURRENT_DATA_SET. The installation requires the magnitude of offsetFromMaster to remain below 250000 ns. A large negative meanPathDelay still indicates invalid timing data even if the port says SLAVE.
4. Check the sensor status. A valid run must advance ingress_time, produce a measured master_offset, and identify the intended grandmaster rather than leaving gm_present false.
5. Repeat the test with all cameras and lidars carrying their normal traffic. Compare timeout counts, offsets, and path-delay stability with and without jetson_clocks.
6. Run overnight only after the short test passes. Save the kernel log, ptp4l log, clock state, configuration, driver identity, firmware version, and load conditions for the entire run.

FAQ