Hello Markus,
On Wed, Nov 08, 2023 at 04:58:54PM +0000, Osterried Markus (ETAS-DAP/XPC-Fe3)
via Linuxptp-users wrote:
> Hi,
>
> I am using a custom board with NXP LS1027A SoC which has an integrated
> ethernet controller (which provides one front facing port, eno0) and
> an integrated ethernet switch (which provides four front facing ports,
> swp0-swp3).
>
> I want to implement an IEEE1588 boundary clock supporting all five
> ports. The ethernet controller has attached a different PHC as the
> ports of the switch has, /dev/ptp0 resp. /dev/ptp1.
>
> Nevertheless, with hardware trigger signal, I can ensure that both
> clocks start at the same time and runs with same frequency, so they
> will always have the same value (within granularity of about 5 ns) -
> as long as they are free running, because frequency adjustments and
> time jumps can not be done atomically for both clocks.
>
> The idea was to create a virtual PHC (vclock, /dev/ptp2), based on
> either one of the two physical PHCs.
>
> But while ptp4l prints this info
> port 1 (eno0): /dev/ptp2 is virtual clock
> port 2 (swp0): taking /dev/ptp2 from the command line, not the attached ptp1
>
> it seems that swp0 still uses the PHC /dev/ptp1 and frames send on
> this port contains timestamps derived from /dev/ptp1, while eno0 uses
> /dev/ptp2, so timestamps on both ports are quite different.
>
> I do not really understand what ptp4l is doing when p->phc_index and
> p->phc_from_cmdline is set - but it seems it is not as I have
> expected.
>
> But I have also recognized that setsockopt(fd, SOL_SOCKET,
> SO_TIMESTAMPING, ...) fails when used with SOF_TIMESTAMPING_BIND_PHC
> when vclock is not derived from natively attached PHC.
>
> What would be the best solution to use a common (v)clock for all the
> interfaces?
> I want to avoid to synchronize the physical PHCs with phc2sys, because
> that would be less accurate then using hardware trigger signal which
> keeps (free running) PHCs on the same value.
Virtual clocks (which btw can have a single parent, not two as you seem
to expect) don't work that way. The physical MACs always take timestamps
in their physical PHC's time domain, and depending on which socket
should receive the timestamped packets, the physical timestamps are
translated to the time base of the vclock associated with that socket.
You cannot make the switch port MACs take timestamps that are translated
into a time domain associated with a vclock of the ENETC. They don't
seem to help you here. They are used if you want multiple ptp4l instances,
associated with multiple domains, on top of the same Ethernet port.
If I understand your use case correctly, you are looking for ways to
keep the /dev/ptp0 clock (shared by eno0, eno1, eno2, eno3) in sync with
the /dev/ptp1 clock (shared by swp0, swp1, swp2, swp3, swp4, swp5), so
that you can run ptp4l with the boundary_clock_jbod option between all
front-facing Ethernet ports.
There are 2 ways in which you can do that.
First, here's a diagram of the Ethernet system on the LS1028A family,
for the viewers not familiar with it:
+-------------------------+------------------------------------------------+
| +--------+ | LS1028A
|
| | eno3 |--|-----------------------------+
|
| +--------+ | internal port (1G) |
|
| | |
|
| +--------+ | internal port (2.5G) |
|
| | eno2 |--|-----------------+ |
|
| +--------+ | | |
|
|
+------------------------------------------------+
| ENETC | | |
|
| | Felix +--------+ +--------+ /dev/ptp1
|
| /dev/ptp0 | switch | swp4 | | swp5 |
|
| | +--------+ +--------+
|
| |
|
| +--------+ +--------+ | +--------+ +--------+ +--------+ +--------+
|
| | eno0 | | eno1 | | | swp0 | | swp1 | | swp2 | | swp3 |
|
+-------------------------+------------------------------------------------+
| | | | | |
SerDes RGMII SerDes SerDes SerDes SerDes
The first option is to run a pair of ptp4l instances on a pair of
Ethernet ports internal to the SoC: one on eno2 and another on swp4.
These internal Ethernet ports are capable of hardware timestamping,
so the PHC of eno2 (aka /dev/ptp0) will be kept in sync within very
low tolerances to the PHC of swp3 (aka /dev/ptp1).
The second option needs collaboration from your board. If you set the
RCW field EC1_SAI4_5_PMUX to the value of 0b101, you make the pinmuxing
of the SoC disable the eno1 RGMII port, and you make those pins available
for the auxiliary PTP pins of /dev/ptp0 and /dev/ptp1.
The idea here is to connect (externally to the SoC) the EC1_1588_PULSE_OUT1
pin of /dev/ptp0 to the SWITCH_1588_DAT[0] pin of /dev/ptp1. Then you
use the ts2phc program to keep in sync the 2 hardware clocks. This is
way more precise than phc2sys and comparable to the ptp4l option, because
the PPS signal is timestamped in hardware using the extts functionality
of the Felix PHC. One small note is that I never had access to a board
with the PPS layout I'm proposing, but based on what I know, it should
work.
There is no option to connect a PPS signal from one PHC to the other
internally to the SoC, unfortunately.
By the way, can you tell more about that hardware trigger signal? I am
familiar with the LS1028A family but I don't know what you are talking
about.
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
