[PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 4775 bytes --]

Dear Community,

As of [1] KSZ drivers support HW timestamping HWTSTAMP_TX_ONESTEP_P2P.
When used with ptp4l (config [2]) I'm able to see that two boards with
KSZ9477 can communicate and one of them is a grandmaster device.

This is OK (/dev/ptp0 is created and works properly).

From what I have understood - the device which supports p2p1step also
supports "older" approaches, so communication with other HW shall be
possible.

Hence the questions:

1. Would it be possible to communicate with beaglebone black (BBB)
connected to the same network?

root@BeagleBone:~# ethtool -T eth0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        ptpv2-event

My board:
# ethtool -T lan3
Hardware Transmit Timestamp Modes:
        off
        onestep-p2p
Hardware Receive Filter Modes:
        none
        ptpv2-l4-event
        ptpv2-l2-event
        ptpv2-event

(other fields are the same)

As I've stated above - onestep-p2p shall also support the "on" mode
from BBB.

The documentation of KSZ9477 states that:
- IEEE 1588v2 PTP and Clock Synchronization
- Transparent Clock (TC) with auto correction update
- Master and slave Ordinary Clock (OC) support
- End-to-end (E2E) or peer-to-peer (P2P)
- PTP multicast and unicast message support
- PTP message transport over IPv4/v6 and IEEE 802.3
- IEEE 1588v2 PTP packet filtering
- Synchronous Ethernet support via recovered clock

which looks like all PTP use cases (and other boards) for HW shall be
supported.

Is this a matter of not (yet) available in-driver support or do I need
to configure linuxptp in different way to have such support?



2. The master clock synchronization and calibration

On one board (grandmaster) (connected to lan3):
[1943.558]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
[1951.091]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
[1951.091]: selected local clock 824f12.fffe.110022 as best master
[1951.091]: port 1: assuming the grand master role

The other board:
[890.003]: port 1 (lan3): new foreign master 824f12.fffe.110022-1
[894.003]: selected best master clock 824f12.fffe.110022
[894.005]: port 1 (lan3): LISTENING to UNCALIBRATED on RS_SLAVE

The phc2sys -m -s lan3 shows some calibration...

CLOCK_REALTIME phc offset        65 s2 freq  -45509 delay 351557
CLOCK_REALTIME phc offset       591 s2 freq  -44964 delay 350475
CLOCK_REALTIME phc offset      -892 s2 freq  -46270 delay 350516
CLOCK_REALTIME phc offset    137456 s2 freq  +91811 delay 733784
CLOCK_REALTIME phc offset   -136987 s2 freq -141395 delay 350676
CLOCK_REALTIME phc offset    -41327 s2 freq  -86831 delay 350216
CLOCK_REALTIME phc offset        66 s2 freq  -57837 delay 350489
CLOCK_REALTIME phc offset     12037 s2 freq  -45846 delay 351854
CLOCK_REALTIME phc offset     12213 s2 freq  -42059 delay 350474
CLOCK_REALTIME phc offset      8984 s2 freq  -41624 delay 349682


but the "fluctuation" is too large to regard it as a "stable" and
precise source.

And probably hence it is "UNCALIBRATED" master clock.

Even more strange - the tshark -i lan3 -Y "ptp" -V

.... 1011 = messageId: Announce Message (0xb)
correction: 0.000000 nanoseconds                     
    correction: Ns: 0 nanoseconds                   
    correctionSubNs: 0 nanoseconds             

.... 0010 = messageId: Peer_Delay_Req Message (0x2)
    correction: 0.000000 nanoseconds
    correction: Ns: 0 nanoseconds
    correctionSubNs: 0 nanoseconds

shows always the correction value of 0 ns.
I do guess that it shall have some (different) values.

Any hints on fixing this problem?


3. Just to mention - I've found rather old conversation regarding PTP
support [3] on KSZ devices (but for KSZ9563)

And it looks like it has already been adopted to minline Linux. 
Am I correct? Or is anything still missing (and hence I do see the two
described above issues)?

Thanks in advance for your help :-)

Links:

[1] -
https://elixir.bootlin.com/linux/v6.16-rc1/source/drivers/net/dsa/microchip/ksz_ptp.c#L293

[2] - config for PTP (/etc/ptp4l.conf):

cat /etc/ptp4l.conf     
[global]

#twoStepFlag 0   ->  set automatically in ptp4l
time_stamping p2p1step
slaveOnly 0/1
delay_mechanism P2P
delay_filter_length 100
tx_timestamp_timeout 100
network_transport L2

[3] -
https://patchwork.ozlabs.org/project/netdev/patch/20201019172435.4416-8-ceggers@arri.de/#2570624

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Oleksij Rempel]

On Mon, Jun 16, 2025 at 05:25:01PM +0200, Lukasz Majewski wrote:
> Dear Community,
> 
> As of [1] KSZ drivers support HW timestamping HWTSTAMP_TX_ONESTEP_P2P.
> When used with ptp4l (config [2]) I'm able to see that two boards with
> KSZ9477 can communicate and one of them is a grandmaster device.
> 
> This is OK (/dev/ptp0 is created and works properly).
> 
> From what I have understood - the device which supports p2p1step also
> supports "older" approaches, so communication with other HW shall be
> possible.

This is not fully correct. "One step" and "two step" need different things from
hardware and driver.

In "one step" mode, the switch modifies the PTP frame directly and inserts the
timestamp during sending (start of frame). This works without host help.

But for "two step" mode, the hardware only timestamps after the frame is sent.
The host must then read this timestamp. For that, the switch must trigger an
interrupt to the host. This requires:
- board to wire the IRQ line from switch to host,
- and driver to handle that interrupt and read the timestamp (like in
ksz_ptp_msg_thread_fn()).

So it's not only about switch HW. It also depends on board design and driver
support.

> Hence the questions:
> 
> 1. Would it be possible to communicate with beaglebone black (BBB)
> connected to the same network?

No, this will not work correctly. Both sides must use the same timestamping
mode: either both "one step" or both "two step".
 
> root@BeagleBone:~# ethtool -T eth0
> Hardware Transmit Timestamp Modes:
>         off
>         on
> Hardware Receive Filter Modes:
>         none
>         ptpv2-event

BBB supports only "two step" (mode "on").
 
> My board:
> # ethtool -T lan3
> Hardware Transmit Timestamp Modes:
>         off
>         onestep-p2p
> Hardware Receive Filter Modes:
>         none
>         ptpv2-l4-event
>         ptpv2-l2-event
>         ptpv2-event

Your board supports only "one step". So they cannot sync correctly.

> (other fields are the same)
> 
> As I've stated above - onestep-p2p shall also support the "on" mode
> from BBB.

No, onestep-p2p cannot talk to "on" mode. They use different timestamping
logic. ptp4l cannot mix one-step and two-step.

> The documentation of KSZ9477 states that:
> - IEEE 1588v2 PTP and Clock Synchronization
> - Transparent Clock (TC) with auto correction update
> - Master and slave Ordinary Clock (OC) support
> - End-to-end (E2E) or peer-to-peer (P2P)
> - PTP multicast and unicast message support
> - PTP message transport over IPv4/v6 and IEEE 802.3
> - IEEE 1588v2 PTP packet filtering
> - Synchronous Ethernet support via recovered clock
> 
> which looks like all PTP use cases (and other boards) for HW shall be
> supported.
> 
> Is this a matter of not (yet) available in-driver support or do I need
> to configure linuxptp in different way to have such support?

Be careful - this list shows what the hardware could support, but not what
actually works in all setups. Many features need specific driver or board
support.

For example, KSZ9477 has an erratum for 2-step mode:
When 2-step is enabled, some PTP messages (like Sync, Follow-up, Announce) can
get dropped if normal traffic is present. This makes 2-step mode unreliable.

End-user impact: Protocols like gPTP or AVB, which require 2-step mode, will
not work correctly. The device cannot keep time sync in 2-step mode with other
devices.
 
> 2. The master clock synchronization and calibration
> 
> On one board (grandmaster) (connected to lan3):
> [1943.558]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
> [1951.091]: port 1: LISTENING to MASTER on
> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> [1951.091]: selected local clock 824f12.fffe.110022 as best master
> [1951.091]: port 1: assuming the grand master role
> 
> The other board:
> [890.003]: port 1 (lan3): new foreign master 824f12.fffe.110022-1
> [894.003]: selected best master clock 824f12.fffe.110022
> [894.005]: port 1 (lan3): LISTENING to UNCALIBRATED on RS_SLAVE

At this point, I would expect to see output like:

master offset ... path delay ...
port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED

If these are missing, sync is not working. In this case, the likely reason is
that the two devices use different timestamping modes — one-step vs two-step —
which are not compatible. Because of that, delay and offset cannot be
calculated, and the state stays UNCALIBRATED.
 
> The phc2sys -m -s lan3 shows some calibration...
> 
> CLOCK_REALTIME phc offset        65 s2 freq  -45509 delay 351557
> CLOCK_REALTIME phc offset       591 s2 freq  -44964 delay 350475
> CLOCK_REALTIME phc offset      -892 s2 freq  -46270 delay 350516
> CLOCK_REALTIME phc offset    137456 s2 freq  +91811 delay 733784
> CLOCK_REALTIME phc offset   -136987 s2 freq -141395 delay 350676
> CLOCK_REALTIME phc offset    -41327 s2 freq  -86831 delay 350216
> CLOCK_REALTIME phc offset        66 s2 freq  -57837 delay 350489
> CLOCK_REALTIME phc offset     12037 s2 freq  -45846 delay 351854
> CLOCK_REALTIME phc offset     12213 s2 freq  -42059 delay 350474
> CLOCK_REALTIME phc offset      8984 s2 freq  -41624 delay 349682
> 
> 
> but the "fluctuation" is too large to regard it as a "stable" and
> precise source.

This is not the right tool to check the current sync problem. The timestamp
readings on KSZ are done over several SPI transactions, which adds jitter and
delay.

For better accuracy, the driver should support gettimex64(), but this is not
implemented in the KSZ driver. So the phc2sys output is not reliable here.

> And probably hence it is "UNCALIBRATED" master clock.
> 
> Even more strange - the tshark -i lan3 -Y "ptp" -V
> 
> .... 1011 = messageId: Announce Message (0xb)
> correction: 0.000000 nanoseconds                     
>     correction: Ns: 0 nanoseconds                   
>     correctionSubNs: 0 nanoseconds             
> 
> .... 0010 = messageId: Peer_Delay_Req Message (0x2)
>     correction: 0.000000 nanoseconds
>     correction: Ns: 0 nanoseconds
>     correctionSubNs: 0 nanoseconds
> 
> shows always the correction value of 0 ns.
> I do guess that it shall have some (different) values.
> 
> Any hints on fixing this problem?

The correctionField is only set when Transparent Clock (TC) is active. But with
KSZ switches, TC is disabled as soon as any port uses DSA CPU tagging.

So in your setup, TC is not active — that’s why correctionField stays 0. This
is expected behavior with current driver and DSA integration
 
> 3. Just to mention - I've found rather old conversation regarding PTP
> support [3] on KSZ devices (but for KSZ9563)
> 
> And it looks like it has already been adopted to minline Linux. 
> Am I correct? Or is anything still missing (and hence I do see the two
> described above issues)?

Some support is in mainline, but what works depends on several things:

- the exact KSZ switch variant (some have quirks, e.g. broken 2-step mode),
- the required feature (OC, TC, 1-step or 2-step),
- the board implementation (e.g. IRQ lines connected or not),
- and driver support (e.g. timestamp reading, gettimex64).

For example:
- If your KSZ chip has broken 2-step mode (known issue), you can only use
  1-step.
- If the switch is used with DSA and CPU tagging is enabled, Transparent
Clock cannot work.

So yes, it’s upstream - but real support depends on your exact use case.

Best Regards,
Oleksij Rempel
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 10059 bytes --]

Hi Oleksij,

Big thanks for sharing your experience with KSZ9477 and PTP - now many
things got clear.

> On Mon, Jun 16, 2025 at 05:25:01PM +0200, Lukasz Majewski wrote:
> > Dear Community,
> > 
> > As of [1] KSZ drivers support HW timestamping
> > HWTSTAMP_TX_ONESTEP_P2P. When used with ptp4l (config [2]) I'm able
> > to see that two boards with KSZ9477 can communicate and one of them
> > is a grandmaster device.
> > 
> > This is OK (/dev/ptp0 is created and works properly).
> > 
> > From what I have understood - the device which supports p2p1step
> > also supports "older" approaches, so communication with other HW
> > shall be possible.  
> 
> This is not fully correct. "One step" and "two step" need different
> things from hardware and driver.
> 
> In "one step" mode, the switch modifies the PTP frame directly and
> inserts the timestamp during sending (start of frame). This works
> without host help.

In principle - timestamp is inserted to KSZ TAG and then the PTP
specific frame is "modified" by KSZ9477 internal HW to accommodate it.

And the timestamp counter is accessible via SPI with KSZ9477 registers.

> 
> But for "two step" mode, the hardware only timestamps after the frame
> is sent.

Ok, so in this case the HW inserts to switch/NIC registers' the new
timestamp value when PTP frame is send. Then it needs to be read and
utilized by the driver.

> The host must then read this timestamp. For that, the switch
> must trigger an interrupt to the host. This requires:
> - board to wire the IRQ line from switch to host,
> - and driver to handle that interrupt and read the timestamp (like in
> ksz_ptp_msg_thread_fn()).
> 

Now it is clear why PTP driver for KSZ creates some interrupts, but
those don't trigger.

> So it's not only about switch HW. It also depends on board design and
> driver support.

Ok.

> 
> > Hence the questions:
> > 
> > 1. Would it be possible to communicate with beaglebone black (BBB)
> > connected to the same network?  
> 
> No, this will not work correctly. Both sides must use the same
> timestamping mode: either both "one step" or both "two step".
>  
> > root@BeagleBone:~# ethtool -T eth0
> > Hardware Transmit Timestamp Modes:
> >         off
> >         on
> > Hardware Receive Filter Modes:
> >         none
> >         ptpv2-event  
> 
> BBB supports only "two step" (mode "on").

Yes, correct. It can only properly communicate with other device (like
RPI4) supporting mode "on".

>  
> > My board:
> > # ethtool -T lan3
> > Hardware Transmit Timestamp Modes:
> >         off
> >         onestep-p2p
> > Hardware Receive Filter Modes:
> >         none
> >         ptpv2-l4-event
> >         ptpv2-l2-event
> >         ptpv2-event  
> 
> Your board supports only "one step". So they cannot sync correctly.
> 
> > (other fields are the same)
> > 
> > As I've stated above - onestep-p2p shall also support the "on" mode
> > from BBB.  
> 
> No, onestep-p2p cannot talk to "on" mode. They use different
> timestamping logic. ptp4l cannot mix one-step and two-step.

Ok. Now it is clear.

> 
> > The documentation of KSZ9477 states that:
> > - IEEE 1588v2 PTP and Clock Synchronization
> > - Transparent Clock (TC) with auto correction update
> > - Master and slave Ordinary Clock (OC) support
> > - End-to-end (E2E) or peer-to-peer (P2P)
> > - PTP multicast and unicast message support
> > - PTP message transport over IPv4/v6 and IEEE 802.3
> > - IEEE 1588v2 PTP packet filtering
> > - Synchronous Ethernet support via recovered clock
> > 
> > which looks like all PTP use cases (and other boards) for HW shall
> > be supported.
> > 
> > Is this a matter of not (yet) available in-driver support or do I
> > need to configure linuxptp in different way to have such support?  
> 
> Be careful - this list shows what the hardware could support, but not
> what actually works in all setups. Many features need specific driver
> or board support.
> 
> For example, KSZ9477 has an erratum for 2-step mode:
> When 2-step is enabled, some PTP messages (like Sync, Follow-up,
> Announce) can get dropped if normal traffic is present. This makes
> 2-step mode unreliable.
> 
> End-user impact: Protocols like gPTP or AVB, which require 2-step
> mode, will not work correctly. The device cannot keep time sync in
> 2-step mode with other devices.

And this information is crucial for me - i.e. the KSZ9477 has HW
limitation, which only allows it to be used with "onestep" PTP
synchronization scheme.

>  
> > 2. The master clock synchronization and calibration
> > 
> > On one board (grandmaster) (connected to lan3):
> > [1943.558]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
> > [1951.091]: port 1: LISTENING to MASTER on
> > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> > [1951.091]: selected local clock 824f12.fffe.110022 as best master
> > [1951.091]: port 1: assuming the grand master role
> > 
> > The other board:
> > [890.003]: port 1 (lan3): new foreign master 824f12.fffe.110022-1
> > [894.003]: selected best master clock 824f12.fffe.110022
> > [894.005]: port 1 (lan3): LISTENING to UNCALIBRATED on RS_SLAVE  
> 
> At this point, I would expect to see output like:
> 
> master offset ... path delay ...
> port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
> 
> If these are missing, sync is not working. In this case, the likely
> reason is that the two devices use different timestamping modes —
> one-step vs two-step — which are not compatible. Because of that,
> delay and offset cannot be calculated, and the state stays
> UNCALIBRATED. 

This is not exactly the case - i.e. I'm using two boards with KSZ9477
ICs connected together (no bridging is used).

Both are the same HW, with the same Linux on each.

> > The phc2sys -m -s lan3 shows some calibration...
> > 
> > CLOCK_REALTIME phc offset        65 s2 freq  -45509 delay 351557
> > CLOCK_REALTIME phc offset       591 s2 freq  -44964 delay 350475
> > CLOCK_REALTIME phc offset      -892 s2 freq  -46270 delay 350516
> > CLOCK_REALTIME phc offset    137456 s2 freq  +91811 delay 733784
> > CLOCK_REALTIME phc offset   -136987 s2 freq -141395 delay 350676
> > CLOCK_REALTIME phc offset    -41327 s2 freq  -86831 delay 350216
> > CLOCK_REALTIME phc offset        66 s2 freq  -57837 delay 350489
> > CLOCK_REALTIME phc offset     12037 s2 freq  -45846 delay 351854
> > CLOCK_REALTIME phc offset     12213 s2 freq  -42059 delay 350474
> > CLOCK_REALTIME phc offset      8984 s2 freq  -41624 delay 349682
> > 
> > 
> > but the "fluctuation" is too large to regard it as a "stable" and
> > precise source.  
> 
> This is not the right tool to check the current sync problem. The
> timestamp readings on KSZ are done over several SPI transactions,
> which adds jitter and delay.

Ok.

> 
> For better accuracy, the driver should support gettimex64(), but this
> is not implemented in the KSZ driver. So the phc2sys output is not
> reliable here.

Ok. Thanks for the clarification.

> 
> > And probably hence it is "UNCALIBRATED" master clock.
> > 
> > Even more strange - the tshark -i lan3 -Y "ptp" -V
> > 
> > .... 1011 = messageId: Announce Message (0xb)
> > correction: 0.000000 nanoseconds                     
> >     correction: Ns: 0 nanoseconds                   
> >     correctionSubNs: 0 nanoseconds             
> > 
> > .... 0010 = messageId: Peer_Delay_Req Message (0x2)
> >     correction: 0.000000 nanoseconds
> >     correction: Ns: 0 nanoseconds
> >     correctionSubNs: 0 nanoseconds
> > 
> > shows always the correction value of 0 ns.
> > I do guess that it shall have some (different) values.
> > 
> > Any hints on fixing this problem?  
> 
> The correctionField is only set when Transparent Clock (TC) is
> active. But with KSZ switches, TC is disabled as soon as any port
> uses DSA CPU tagging.

Ok.

> 
> So in your setup, TC is not active — that’s why correctionField stays
> 0. This is expected behavior with current driver and DSA integration

Ok. Thanks for the clarification.

>  
> > 3. Just to mention - I've found rather old conversation regarding
> > PTP support [3] on KSZ devices (but for KSZ9563)
> > 
> > And it looks like it has already been adopted to minline Linux. 
> > Am I correct? Or is anything still missing (and hence I do see the
> > two described above issues)?  
> 
> Some support is in mainline, but what works depends on several things:
> 
> - the exact KSZ switch variant (some have quirks, e.g. broken 2-step
> mode),
> - the required feature (OC, TC, 1-step or 2-step),
> - the board implementation (e.g. IRQ lines connected or not),
> - and driver support (e.g. timestamp reading, gettimex64).
> 
> For example:
> - If your KSZ chip has broken 2-step mode (known issue), you can only
> use 1-step.
> - If the switch is used with DSA and CPU tagging is enabled,
> Transparent Clock cannot work.
> 

Now it is clear.

So the TC can be only used when no 'master' port is connected (i.e. the
switch is working as a "standalone", non-CPU mode)?

> So yes, it’s upstream - but real support depends on your exact use
> case.

Ok.

I've looked into the tshark output and it looks like only:

Announce Message (0xb) 80:1f:12:3e:0a:22 -> 01:1b:19:00:00:00
Sync Message (0x0)     80:1f:12:3e:0a:22 -> 01:1b:19:00:00:00
Peer_Delay_Req Message (0x2)
	80:1f:12:3e:0a:42 -> 01:80:c2:00:00:0e (LLDP Multicast)

frames are present.

The DELAY-RESPONSE from (master to slave) is not present, so the slave
cannot calculate transmission delay and synchronize.

I'm now investigating why it is not present.

> 
> Best Regards,
> Oleksij Rempel




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Vadim Fedorenko]

On 17/06/2025 06:25, Oleksij Rempel wrote:
> On Mon, Jun 16, 2025 at 05:25:01PM +0200, Lukasz Majewski wrote:
>> Dear Community,
>>
>> As of [1] KSZ drivers support HW timestamping HWTSTAMP_TX_ONESTEP_P2P.
>> When used with ptp4l (config [2]) I'm able to see that two boards with
>> KSZ9477 can communicate and one of them is a grandmaster device.
>>
>> This is OK (/dev/ptp0 is created and works properly).
>>
>>  From what I have understood - the device which supports p2p1step also
>> supports "older" approaches, so communication with other HW shall be
>> possible.
> 
> This is not fully correct. "One step" and "two step" need different things from
> hardware and driver.
> 
> In "one step" mode, the switch modifies the PTP frame directly and inserts the
> timestamp during sending (start of frame). This works without host help.
> 
> But for "two step" mode, the hardware only timestamps after the frame is sent.
> The host must then read this timestamp. For that, the switch must trigger an
> interrupt to the host. This requires:
> - board to wire the IRQ line from switch to host,
> - and driver to handle that interrupt and read the timestamp (like in
> ksz_ptp_msg_thread_fn()).
> 
> So it's not only about switch HW. It also depends on board design and driver
> support.
> 
>> Hence the questions:
>>
>> 1. Would it be possible to communicate with beaglebone black (BBB)
>> connected to the same network?
> 
> No, this will not work correctly. Both sides must use the same timestamping
> mode: either both "one step" or both "two step".
>   

I'm not quite sure this statement is fully correct. I don't have a
hardware on hands to make this setup, but reading through the code in
linuxptp - the two-step fsm kicks off based on the message type bit. In 
case when linuxptp receives 1-step sync, it does all the calculations.
For delay response packets on GM side it doesn't matter as GM doesn't do
any calculations. I don't see any requirements here from the perspective
of protocol itself.

But again, I don't have HW to make a proof.

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Richard Cochran]

On Tue, Jun 17, 2025 at 05:10:11PM +0100, Vadim Fedorenko wrote:
> On 17/06/2025 06:25, Oleksij Rempel wrote:
> > No, this will not work correctly. Both sides must use the same timestamping
> > mode: either both "one step" or both "two step".
> 
> I'm not quite sure this statement is fully correct. I don't have a
> hardware on hands to make this setup, but reading through the code in
> linuxptp - the two-step fsm kicks off based on the message type bit. In case
> when linuxptp receives 1-step sync, it does all the calculations.

Correct.

> For delay response packets on GM side it doesn't matter as GM doesn't do
> any calculations. I don't see any requirements here from the perspective
> of protocol itself.

Running on a PTP client, ptp4l will happily use either one or two step
Sync messages from the server.

Thanks,
Richard

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Oleksij Rempel]

On Tue, Jun 17, 2025 at 10:07:32PM -0700, Richard Cochran wrote:
> On Tue, Jun 17, 2025 at 05:10:11PM +0100, Vadim Fedorenko wrote:
> > On 17/06/2025 06:25, Oleksij Rempel wrote:
> > > No, this will not work correctly. Both sides must use the same timestamping
> > > mode: either both "one step" or both "two step".
> > 
> > I'm not quite sure this statement is fully correct. I don't have a
> > hardware on hands to make this setup, but reading through the code in
> > linuxptp - the two-step fsm kicks off based on the message type bit. In case
> > when linuxptp receives 1-step sync, it does all the calculations.
> 
> Correct.
> 
> > For delay response packets on GM side it doesn't matter as GM doesn't do
> > any calculations. I don't see any requirements here from the perspective
> > of protocol itself.
> 
> Running on a PTP client, ptp4l will happily use either one or two step
> Sync messages from the server.

Thank you for clarification! In this case, something else was wrong, and
I made a wrong assumption. I had a non-working configuration, so I made
the assumption without verifying the code.

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

Hi Oleksij,

> On Tue, Jun 17, 2025 at 10:07:32PM -0700, Richard Cochran wrote:
> > On Tue, Jun 17, 2025 at 05:10:11PM +0100, Vadim Fedorenko wrote:  
> > > On 17/06/2025 06:25, Oleksij Rempel wrote:  
> > > > No, this will not work correctly. Both sides must use the same
> > > > timestamping mode: either both "one step" or both "two step".  
> > > 
> > > I'm not quite sure this statement is fully correct. I don't have a
> > > hardware on hands to make this setup, but reading through the
> > > code in linuxptp - the two-step fsm kicks off based on the
> > > message type bit. In case when linuxptp receives 1-step sync, it
> > > does all the calculations.  
> > 
> > Correct.
> >   
> > > For delay response packets on GM side it doesn't matter as GM
> > > doesn't do any calculations. I don't see any requirements here
> > > from the perspective of protocol itself.  
> > 
> > Running on a PTP client, ptp4l will happily use either one or two
> > step Sync messages from the server.  
> 
> Thank you for clarification! In this case, something else was wrong,
> and I made a wrong assumption. I had a non-working configuration, so
> I made the assumption without verifying the code.
> 

Ok, I do have one issue to fix - the BBB with "two step" timestamping
mode (with recent ptp4l) shall communicate with the KSZ9477 based PTP
setup, which uses the "one step" timestamping.

The second problem which I've found after some debugging:
- One device is selected as grandmaster clock. Another one tries to
  synchronize (for the simpler setup I've used two the same boards with
  identical kernel and KSZ9477 setup).

- tshark from host on which we do have grandmaster running:
  IEEEI&MS_00:00:00 PTPv2 58 Sync Message
  LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
  IEEEI&MS_00:00:00 PTPv2 58 Sync Message
  LLDP_Multicast PTPv2 68 Peer_Delay_Req Message

So the SYNC is send, then the "slave" responds correctly with
Peer_Delay_Req_Message.

But then the "grandmaster" is NOT replying with PER_DELAY_RESPONSE.

After some digging into the code it turned out that
dsa_skb_defer_rx_timestamp() (from net/dsa/tag.c) calls
ptp_classify_raw(skb), which is a bpf program.

Instead of returning 0x42 I do receive "PTP_CLASS_NONE" and the frame is
dropped.

That is why grandmaster cannot send reply and finish the PTP clock
adjustment process.

The CONFIG_NET_PTP_CLASSIFY=y.

Any hints on how to proceed? If this would help - I'm using linux
kernel with PREEMPT_RT applied to it.

> Best Regards,
> Oleksij


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Vladimir Oltean]

On Thu, Jun 26, 2025 at 11:33:25PM +0200, Lukasz Majewski wrote:
> The second problem which I've found after some debugging:
> - One device is selected as grandmaster clock. Another one tries to
>   synchronize (for the simpler setup I've used two the same boards with
>   identical kernel and KSZ9477 setup).
> 
> - tshark from host on which we do have grandmaster running:
>   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
>   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
>   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
>   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
> 
> So the SYNC is send, then the "slave" responds correctly with
> Peer_Delay_Req_Message.

Peer delay measurement is an independent process, not a response to Sync
messages.

> But then the "grandmaster" is NOT replying with PER_DELAY_RESPONSE.
> 
> After some digging into the code it turned out that
> dsa_skb_defer_rx_timestamp() (from net/dsa/tag.c) calls
> ptp_classify_raw(skb), which is a bpf program.
> 
> Instead of returning 0x42 I do receive "PTP_CLASS_NONE" and the frame is
> dropped.
> 
> That is why grandmaster cannot send reply and finish the PTP clock
> adjustment process.
> 
> The CONFIG_NET_PTP_CLASSIFY=y.
> 
> Any hints on how to proceed? If this would help - I'm using linux
> kernel with PREEMPT_RT applied to it.

Which frame is classified as PTP_CLASS_NONE? The peer delay request?
That doesn't sound convincing, can you place a call to skb_dump() and
show the contents of the PTP packets that don't pass this BPF filter?
Notably, the filter matches for event messages and doesn't match for
general messages, maybe that confused your debugging process in some way.

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]

Hi Vladimir,

> On Thu, Jun 26, 2025 at 11:33:25PM +0200, Lukasz Majewski wrote:
> > The second problem which I've found after some debugging:
> > - One device is selected as grandmaster clock. Another one tries to
> >   synchronize (for the simpler setup I've used two the same boards
> > with identical kernel and KSZ9477 setup).
> > 
> > - tshark from host on which we do have grandmaster running:
> >   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
> >   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
> >   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
> >   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
> > 
> > So the SYNC is send, then the "slave" responds correctly with
> > Peer_Delay_Req_Message.  
> 
> Peer delay measurement is an independent process, not a response to
> Sync messages.
> 
> > But then the "grandmaster" is NOT replying with PER_DELAY_RESPONSE.
> > 
> > After some digging into the code it turned out that
> > dsa_skb_defer_rx_timestamp() (from net/dsa/tag.c) calls
> > ptp_classify_raw(skb), which is a bpf program.
> > 
> > Instead of returning 0x42 I do receive "PTP_CLASS_NONE" and the
> > frame is dropped.
> > 
> > That is why grandmaster cannot send reply and finish the PTP clock
> > adjustment process.
> > 
> > The CONFIG_NET_PTP_CLASSIFY=y.
> > 
> > Any hints on how to proceed? If this would help - I'm using linux
> > kernel with PREEMPT_RT applied to it.  
> 
> Which frame is classified as PTP_CLASS_NONE? The peer delay request?
> That doesn't sound convincing, can you place a call to skb_dump() and
> show the contents of the PTP packets that don't pass this BPF filter?
> Notably, the filter matches for event messages and doesn't match for
> general messages, maybe that confused your debugging process in some
> way.

It looks like PER_DELAY_REQ goes from one KSZ9477 device (with DA:
01:80:C2:00:00:0E) and then it is not visible (i.e. is dropped) in the
tshark output on the other KSZ9477 device.

From what I've read on the Internet - those multicast frames are
dropped by default by switches, but I'm using KSZ9477 ports in
stand alone mode - i.e. bridge is not created).

On the other hand - the frames with DA: 01:16:19:00:00:00 (other
multicast "set" of address) are delivered correctly (so the grandmaster
clock is elected).

This is under further investigation.
(setting KSZ9477 lan3s as promisc doesn't help).


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Oleksij Rempel]

On Sun, Jun 29, 2025 at 11:28:30AM +0200, Lukasz Majewski wrote:
> Hi Vladimir,
> 
> > On Thu, Jun 26, 2025 at 11:33:25PM +0200, Lukasz Majewski wrote:
> > > The second problem which I've found after some debugging:
> > > - One device is selected as grandmaster clock. Another one tries to
> > >   synchronize (for the simpler setup I've used two the same boards
> > > with identical kernel and KSZ9477 setup).
> > > 
> > > - tshark from host on which we do have grandmaster running:
> > >   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
> > >   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
> > >   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
> > >   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
> > > 
> > > So the SYNC is send, then the "slave" responds correctly with
> > > Peer_Delay_Req_Message.  
> > 
> > Peer delay measurement is an independent process, not a response to
> > Sync messages.
> > 
> > > But then the "grandmaster" is NOT replying with PER_DELAY_RESPONSE.
> > > 
> > > After some digging into the code it turned out that
> > > dsa_skb_defer_rx_timestamp() (from net/dsa/tag.c) calls
> > > ptp_classify_raw(skb), which is a bpf program.
> > > 
> > > Instead of returning 0x42 I do receive "PTP_CLASS_NONE" and the
> > > frame is dropped.
> > > 
> > > That is why grandmaster cannot send reply and finish the PTP clock
> > > adjustment process.
> > > 
> > > The CONFIG_NET_PTP_CLASSIFY=y.
> > > 
> > > Any hints on how to proceed? If this would help - I'm using linux
> > > kernel with PREEMPT_RT applied to it.  
> > 
> > Which frame is classified as PTP_CLASS_NONE? The peer delay request?
> > That doesn't sound convincing, can you place a call to skb_dump() and
> > show the contents of the PTP packets that don't pass this BPF filter?
> > Notably, the filter matches for event messages and doesn't match for
> > general messages, maybe that confused your debugging process in some
> > way.
> 
> It looks like PER_DELAY_REQ goes from one KSZ9477 device (with DA:
> 01:80:C2:00:00:0E) and then it is not visible (i.e. is dropped) in the
> tshark output on the other KSZ9477 device.
> 
> From what I've read on the Internet - those multicast frames are
> dropped by default by switches, but I'm using KSZ9477 ports in
> stand alone mode - i.e. bridge is not created).
> 
> On the other hand - the frames with DA: 01:16:19:00:00:00 (other
> multicast "set" of address) are delivered correctly (so the grandmaster
> clock is elected).
> 
> This is under further investigation.
> (setting KSZ9477 lan3s as promisc doesn't help).

Hm, if I remember it correctly, there was some HW filters:
https://patchwork.ozlabs.org/project/devicetree-bindings/cover/20201118203013.5077-1-ceggers@arri.de/#2589089
"
When master mode is on Delay_Resp will not be forwarded to the host
port.
When master mode is off Delay_Req will not be forwarded to the host
port.
"

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |