From the DRIVE OS time synchronization documentation, I understand that the onboard Marvell switches have their own internal MCU/firmware for PTP/AVNU CDS 1.6 and that the switch ports use static PTP roles.
What we would like to achieve is to use an external GM connected via EQOS and distribute this time to the LiDARs connected through the onboard switches:
According to the static PTP role table described in NVIDIA DRIVE OS Linux SDK Developer Guide Time Synchronization , I am not fully sure whether this should work. The documentation shows both switch-ports (mgbe-3 and mgbe-2) only as client ports and the corresponding ports inside the switches as unchangeable server ports.
The linked forum topic makes it look as if a similar MGBE-to-switch setup should be possible in principle, although there were issues. So do I understand the documentation wrong and should an EQOS-connected external GM feeding time toward Switch-2 / MGBE3-connected LiDARs work?
I am also unsure whether, in the default state, the PHCs of EQOS, MGBE2, and MGBE3 are expected to become synchronized (that’s also how I understand the linked documentation). This is not necessery for our goal - just for better understanding.
Any clarification on the intended default behavior and the recommended setup would be very helpful.
The main reason for this setup is that we want to synchronize all sensors in the system, even though they are connected through different Ethernet ports and onboard switches.
In our current setup, the external grandmaster provides the vehicle-wide reference time. The external GM provides a generic IEEE 802.1AS time source, while the LiDARs require one of the automotive 802.1AS variants, such as AVNU / Automotive or AUTOSAR.
Therefore, directly connecting the external GM to Switch 1 would probably not work, because the switch is probably not able to synchronize to this GM if the profiles do not match (that’s what NVIDIAs doc says). Our idea was to use the Orin as an intermediate system: receive the external GM time on EQOS, synchronize the Orin / PHC to it, and then provide a compatible automotive gPTP profile (AVNU) towards the switch-connected sensors. That’s why we didn’t connect the GM to Matenet J11 port 4 - just because of the non-compatible gPTP-Profile.
The main question is whether DRIVE OS supports such a use case, where time received on EQOS is distributed further to sensors connected through the onboard switches, possibly with the Orin acting as a kind of gPTP gateway / profile translator.
As a separate question, we were also wondering whether it is possible to use the switch-internal time as the common time source for the switch-connected sensors, without using an external GM at all. However, for our main setup we would prefer to synchronize everything to the external GM time, because this is the common vehicle reference time.
