Re: [Linuxptp-users] DSA bridge PTP issues

[Riccardo L. <la...@le...>]

Il 28/03/23 12:14, Vladimir Oltean ha scritto:
> On Tue, Mar 28, 2023 at 11:29:02AM +0200, Riccardo Laiolo wrote:
>> Hi there,
>> I'm working on a custom NXP iMX8 SoM connected to a Marvell MV88E6390 switch on port0 (eth0 as management port).
>> Five switch ports are exposed to the outside and bridged together in a dsa device (br0 soft bridge).
>> I'm running iMX linux-5.15.71 from NXP downstream repository.
>>
>> I need my device to be a ptp device (master or slave depending on the specific application).
>>
>> Since I can ping other PCs on the network I think Marvell DSA drivers are working, but ptp is not working.
>>
>> I found and backported this patch (https://github.com/torvalds/linux/commit/9627c981ac82209c66c1b6c0e15c6cceb8656f01)
>> into my codebase, but when I launch ptp4l it's not working properly. Launching ptp4l on eth0 it says eth0 is
>> rejecting HWTSTAMP filtering configuration. Launching ptp4l on an outside facing port (lan1:5), instead, using IPv4
>> or IPv6 transport, it's like my SoM can't talk to other ptp devices: if my SoM is a ptp master i see announce, sync,
>> and follow-up messages get sent, and I see dly_req from other slaves coming back, but there are no dly_resp at all.
>> When my som is slave there are no packets from it. It's like all ptp related packets get ignored.
>>
>> Is it possible to run ptp on eth0 (or on br0)? I want to syncronize devices on all the front facing ports.
>>
>> I've attached `ip a` output, `ethtool -T eth0` output, and `ethtool -T lan1` output.
> "ethtool -T lan1" reports that the switch ports only support L2 PTP, so
> no IPv4 and no IPv6.

Thanks for your reply,
why are you saying there's no IP support? I thought ethtool was saying there is both L2 and L4 filtering capabilities.
>Hardware Receive Filter Modes:
>	none
>	ptpv2-l4-event
>	ptpv2-l4-sync
>	ptpv2-l4-delay-req
>	ptpv2-l2-event
>	ptpv2-l2-sync
>	ptpv2-l2-delay-req
>	ptpv2-event
>	ptpv2-sync
>	ptpv2-delay-req

>
> PTP hardware timestamping on eth0 (the DSA master) is rejected if the
> switch supports hardware timestamping too, because the kernel does not
> support reporting more than 1 TX timestamp per packet (or rather, it
> does report multiple timestamps, but it doesn't tell user space where
> they came from). Since a choice needs to be made even with the
> limitations in place, that current choice is to only allow PTP hardware
> timestamping on the DSA switch ports, if those support this operation,
> or on the DSA master if the switch doesn't support hardware timestamping.

Ok, that seems reasonable. Thanks for the insight.

> PTP hardware timestamping does not work on a bridge interface, for the
> same basic reason that a bridge forwards packets to potentially multiple
> ports, and it is not immediately clear, when an application sees a
> timestamp coming from a bridge interface, which bridge port took that
> timestamp (they may have different PHCs).
>
> This only leaves you a single option:
>
> ptp4l -i lan1 -i lan2 -i lan3 [ ... ] -2 -P -m --tx_timestamp_timeout 40

Finally, I tried to launch ptp4l on my board as master (on all of the front-facing port)
with -2 and it's working as expected, since all the (slave-only) devices are synchronising to it.

On the other hand if I configure my board as a slave-only device (-s flag) it's not working.
I've attached two logs, in the first one i launched ptp4l with -i on all ports,
but it's noisy and unreadable!
Anyway, the master was on port3 and on port5 was a second slave.
In the second one i passed -i lan3 (the port connected directly to the ptp master device)

Thanks for the help,
RL

-- 
Riccardo Laiolo
Leaff Engineering - Digital Solutions & Algorithms