Orin Time Sync
Orin Time Sync has multiple components as described below in diagram. It consist of:
PTP Support in Orin
As per the supported PTP topology, One of the Tegra MAC and its associated PHC needs to get synchronized with external Grand Master clock. Once synchronized this MAC PHC (PTP hardware counter) works as a base for:
- All the Tegra internal clocks which needs to be synchronized or to be correlated as per the use-case.
- All the software component requiring the current PTP time in system.
AVNU PTP Support
./ptp4l -f automotive_slave.cfg -i mgbe2_0 -p /dev/ptp<X> -m
// where:
// /dev/ptp<X> - PTP dev node associated with the mgbe2_0
For device connected on EQOS another daemon instance can be started
with following command in server mode. To identify <x>
, use the
ethtool -T [Interface ID]
command. If ethtool is not installed
on the host and DUT, use the sudo apt install ethtool
command to
install.
./ptp4l -f automotive_master.cfg -i eqos_0 -p /dev/ptp<X> -m
// where:
// /dev/ptp<X> - PTP dev node associated with the eqos_0
AUTOSAR TSync PTP Support
/ #Server Mode
cd /opt/nvidia/drive-linux/samples/nvavb/daemons/
sudo ./gptpTsync <interface> -F autosar_cfg.ini -INITPDELAY 0 -OPERPDELAY 0 -INITSYNC -3 -OPERSYNC -3 -S -V -GM
// #client Mode
cd /opt/nvidia/drive-linux/samples/nvavb/daemons/
sudo ./gptpTsync <interface> -F autosar_cfg.ini -INITPDELAY 0 -OPERPDELAY 0 -INITSYNC -3 -OPERSYNC -3 -S -V -N -A
// where:
// <iface> : Interface name i.e eqos_0, mgbe0_0, mgbe1_0 on which PTP is supposed to be started. It could be a VLAN interface above the primary interface.
/*
# Time secure TLV related data
# Specification for 10.2.4 EthTSynGlobalTimeFollowUpDataIDList, Also refer ECUC_EthTSyn_00030
# Provide 16 data element values in decimal
# _Provide value in decimal value only(not in hexadecimal)_ */
FollowUpDataIdList = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
/*
# Time secure TLV CRC_Time_Flags for CRC calcuation in master mode.
# Refer CRC_Time_Flags from SWS_EthTSyn_00065
# Following values to be 'OR'ed to create flag as per requirement
# BitMask 0x01 [messageLength]
# BitMask 0x02 [domainNumber]
# BitMask 0x04 [correctionField]
# BitMask 0x08 [sourcePortIdentity]
# BitMask 0x10 [sequenceId]
# BitMask 0x20 [preciseOriginTimestamp]
# Value provided in below config will be 'AND' with 0x3F to consider only valid bits
# _Provide value in hex format only_ */
EthTSynCrcTimeFlagsTxSecured = 0x37
/*
# Status TLV related data
# if SyncToGateWay is set, SGW with SyncToSubDomain will be set. Otherwise, SyncToGTM will be set.
# Valid values 0 and 1
# _Provide value in decimal value only(not in hexadecimal)_ */
SyncToGateWay = 0
/*
# User data TLV number of bytes UserDataLength
# this value should be 1 >= UserDataLength <= 3 */
UserDataLength = 1
/*
# User data TLV Related data
# Provide user byte of size uint8_t with space separated, i.e UserByte = UserByte_0 UserByte_1 UserByte_2
# _Provide value in decimal value only(not in hexadecimal)_ */
UserByte = 0 0 0
/*
# CRC validation mode for slave
# CRC_IGNORED and CRC_VALIDATED */
EthTSynRxCrcValidated = CRC_VALIDATED
/*
# Static Pdelay setting.
# Set to 1 to disable path delay calculation using Pdelay_req, Pdelay_resp, Pdelay_respfup.
# and use EthTSynGlobalTimePropagationDelay as static Link delay.
# Setting it to 1 will also make daemon to ignore path delay messages received.
# Set 0 to enable path delay calculation using Pdelay_req, Pdelay_resp, Pdelay_respfup
# and ignore EthTSynGlobalTimePropagationDelay.
# _Provide value in decimal value only(not in hexadecimal)_ */
UseStaticPdelay = 0
/*
# Static Delay in nanosecond will be used when UseStaticPdelay is set to 1
# Default value of 0 will be used if UseStaticPdelay set and below field is not populated.
# _Provide value in decimal value only(not in hexadecimal)_ */
EthTSynGlobalTimePropagationDelay = 20000000
/*
# Option to enable and disable processing and transmit of sub-TLV's.
# Set values to 1 enable and 0 to disable
# Time secure sub-TLV
# _Provide value in decimal value only(not in hexadecimal)_ */
EthTSynTLVFollowUpTimeSubTLV = 1
/* # Status sub-TLV */
EthTSynTLVFollowUpStatusSubTLV = 1
/* # User dats sub-TLV */
EthTSynTLVFollowUpUserDataSubTLV = 1
Other PTP Profiles in Orin
DRIVE OS Linux supports IEEE 802.1AS profile. Support for this profile is limited to the software stack running in Tegra/Orin i.e., no support in switches. This means this profile can not be enabled on Ethernet MACs, which are directly connected to the switches on the DRIVE Orin Development Platforms. For custom boards all the Tegra MACs can support this profile.
Available in all Standard (non-Safety), Safety and Safety overlay platform configurations.
IEEE 802.1AS Command
// #Server Mode
sudo ./ptp4l -f ./gPTP.cfg -p /dev/ptp<X> -i <iface> -m -l7
// #client Mode
sudo ./ptp4l -f ./gPTP_slave.cfg -p /dev/ptp<X> -i <iface> -m -l7
// where:// <iface> : Interface name i.e eqos_0, mgbe0_0, mgbe1_0 on which PTP is supposed to be started. It could be a VLAN interface above the primary interface.// /dev/ptp<X> - PTP dev node associated with the interface. Use "ethtool -T" command to identify the hardware clock instance i.e <X>
PTP Bridging in Orin
Orin SOC has 5 Ethernet MAC controllers embedded in it. Out of which only one can act as PTP secondary interface to synchronize the Tegra with external GM. There could be use-cases where the time info coming from external GM needs to be forwarded to the devices connected to other mac controllers. This requires a PTP time aware bridge like implementation in Tegra. Starting 6.0.2 a new feature is included in lower layer to sync multiple MAC PHCs from an external GM. As of now, support is there for only 2 MACs in a given configuration.
Primary (source) and secondary (sink) MAC selection is configurable through device
tree. Check the device tree binding doc in
Documentation/devicetree/bindings/platform/tegra/tegra-nvethernet.txt
.
PTP-TSC Sync
Orin SOC provides a hardware assisted mechanism to align/sync the TSC (clock/counter) with one of the Tegra SOC Ethernet MAC on second boundary using the PPS signal from the MAC. This feature is useful in synchronizing camera fsync signals (used for camera frame capture/timestamping) with PTP time in order to reduce the timestamp jitter between sensors timestamped with PTP domain. This feature is also useful for co-relation of TSC and PTP time-domain timestamps (needed for sensor fusion application) as it ensures a fixed offset (no run-time drift) between PTP and TSC counters over the time. The MAC selection for TSC reference is based on the PTP topology of the platform. It must be always the MAC acting as PTP client for External GTM directly or through switch.
PTP time source MAC selection is configurable through NvTime2 modules configuration section.
NvPPS
- Current synchronized PTP time from PHC
- Event co-related PTP and TSC time domain timestamps
This module is enabled by default in the DRIVE OS kernel.
Operating Mode
NvPPS module has two operating modes.
- GPIO/PPS mode : The NvPPS driver takes external 1PPS signal as input from devices like GPS etc.. on Tegra GPIO pin as an event and reads the timestamps from relevant time domains for correlation.
- Timer mode: In this mode event for co-relation is based on periodic SW timer scheduled inside NvPPS module.
Timer mode is useful when there is no external device like GPS present for 1 PPS signal generation in system design or if their is no provision in platform (e.g P3663) to receive PPS signal through Tegra GPIO.
Userspace exposed interfaces
The module exposes a dev node named as "/dev/nvpps0". The dev node supports following IOCTL calls:
SN | IOCTL | Description |
---|---|---|
1 | NVPPS_GETTIMESTAMP | Get current timestamps from kernel and PTP time from primary PHC interface |
2 | NVPPS_GETEVENT | Get correlated timestamps of different time-domains (TSC, PTP etc.) at the last event. |
3 | NVPPS_GETVERSION | Get NvPPS driver and API versions. |
4 | NVPPS_GETPARAMS |
Get the current NVPPS parameters. Like Operating mode(in GPIO or Timer mode) and TSC timestamp mode(in Nanosec or Counter mode). For the mode values to be used, please refer ioctl header file mentioned below. |
5 | NVPPS_SETPARAMS |
Set the NvPPS parameters, described in the NVPPS_GETPARAMS section. This IOCTL can be used to update NvPPS parameters in runtime. Call this IOCTL with this command. Update configuration (operating mode and TSC timestamp mode) are required to set the parameters. The parameter settings in NvPPS module are common to all client applications. |
The data structures required for supporting the IOCTLs are defined in
<top>/drive-linux/kernel/source/oss_src/nvidia-oot/include/uapi/linux/nvpps_ioctl.h
.
Kernel space exposed interface
In addition to User space interfaces, NvPPS module exports a kernel API for other
kernel modules to get the current synchronized PTP time in kernel. Refer to
<top>/drive-linux/kernel/source/oss_src/nvidia-oot/include/linux/nvpps.h
.
/*
* Get PTP time
* Clients may call this API whenever PTP time is needed.
* If PTP time source is not registered, returns -EINVAL
*
* This API is available irrespective of nvpps dt availablity
* When nvpps dt node is not present, interface name will
* default to "eth0".
*/
int nvpps_get_ptp_ts(void *ts)
NvPPS module configuration
Following static configuration is possible through NvPPS Device tree node. Refer to
device tree binding doc
<top>/drive-linux/kernel/source/oss_src/nvidia-oot/Documentation/devicetree/bindings/nvpps/nvpps.txt
.
- Primary PTP interface (prop_name: "interface" ) - The MAC interface which connects to external GM.
- Secondary PTP interface (prop_name: "sec_interface" ) - The MAC which synchronizes with primary PTP MAC interface using PTP bridging.
-
1PPS input pin (prop_name: "gpios" ) - Specifies GPIO pin detail on which 1PPS signal is available. Please refer platform specific NvPPS DT node more info.
- PTP_TSC sync disable (prop name: "ptp_tsc_sync_dis") - Define this dt property to disable TSC syncing with PTP
- PTP_TSC sync K_INT value (prop name: "ptp_tsc_k_int") - The property is used to define the K_INT value, which is used when calculating the delta value to apply, when using fast convergence algorithm. Minimum val: 0x0, Max val: 0xff, and default val: 0x70.
- PTP_TSC sync LOCK_THRESHOLD value (prop name: "ptp_tsc_lock_threshold") - The property is used to define the LOCK_THRESHOLD value, The PTP_TSC lock is deemed lost when the when the absolute diff value exceeds this threshold value. The reset value 0x1F correspond to 1us. Min: 0x1F(1us), max:0xFFFF(approx 2.1ms), Default: 0x26c(20us). eg: if 50us needs to be programmed, then 0x1F * 0x32(50) = 0x60E