Hi Vladimir,
thanks for your answer.
We do not have a connection between EC1_1588_PULSE_OUT1 and SWITCH_1588_DAT0 on
our board, so this option is not possible for us.
But we use this trigger signal, which actually is EC1_1588_TRIG_IN1 and
SWITCH_1588_DAT1. Both pins are connected together to a GPIO pin.
In ES_DEVCPU_PTP_PTP_PINS_PTP_PIN_CFG register, SWITCH_1588_DAT1 is configured
for STORE action.
Generating an edge on these trigger signals is latching a timestamp of the
ENETC (aka /dev/ptp0) and SWITCH (aka /dev/ptp1).
As the input clocks of ENETC and SWITCH is derived from the same clock source,
the PHCs always run at the same speed (with period configured in ENETC TMR_CTRL
and ES_DEVCPU_PTP_PTP_CFG_PTP_SYS_CLK_CFG).
When latching the timestamps of ENETC and SWITCH, we can calculate the offset
between them, which in turn we use to clock_adjtime(ADJ_SETOFFSET|ADJ_NANO) one
PHC to the other.
Doing this in the startup phase, we can guarantee that /dev/ptp0 and /dev/ptp1
is synchronized, but yes, PHC subsystem does not know that they are now
actually equivalent.
When later ptp4l wants to adjust the PHC according to an external PTP master,
it will do this only on one of the two PHCs, therefore they will be no longer
in sync.
To avoid this, the idea was to create a vclock /dev/ptp2 based on /dev/ptp0.
And to let /dev/ptp0 and /dev/ptp1 free running and in sync.
But because PHC subsystem does not know that /dev/ptp0 and /dev/ptp1 is
actually equivalent, it forbids to bind /dev/ptp2 to the socket of swpX.
If I understand your suggested options correctly, the ptp4l instance which
handles the external front-facing interfaces, will just adjust one physical
PHC, while the other PHC is re-adjusted by either internal ptp4l instance or
ts2phc, but of course within some latency. Is this correct?
Back to our original problem:
We want to use ptp4l between all front-facing ports, while physical PHCs of
eno0-eno3 and swp0-swp5 are already in sync - known by us, but not known by PHC
subsystem.
For this, you have mentioned boundary_clock_jbod can be used.
I do not know what boundary_clock_jbod is doing in detail and if and how this
could be used to provide a solution in this use case.
Could you please explain.
Many thanks and regards
Markus
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
