2401785_en-US

[#1]

PTP over SJA1110

Hi,

We are debugging PTP on a PolarFire SoC GEM connected through an SJA1110 switch.

We observe that:

• PTP over Layer 2 (ptp4l -2) is received by the switch (ingress counters increase), but it is not forwarded (egress counters do not increase).
• PTP over UDP (ptp4l ) is forwarded correctly through the same bridge path.
• Normal Ethernet traffic (ICMP/ARP) also forwards correctly.

Is there any special handling or additional configuration required on the SJA1110 to forward Layer 2 PTP frames (destination MAC 01:1B:19:00:00:00) across bridged ports? Are there any known restrictions on forwarding Layer 2 PTP?

Also, is PTP over UDP (ptp4l) fully supported and recommended with the PolarFire SoC GEM, or is Layer 2 the only supported/recommended transport?

Any guidance would be appreciated.

Re: PTP over SJA1110

Hello @Ankur_pixl ,

In a typical gPTP / time-aware bridge use case, the switch is not expected to forward all gPTP frames transparently as ordinary multicast traffic. The usual flow is that the switch receives the gPTP frames from the Grandmaster, processes them through the gPTP stack running on the internal Cortex-M7 and then generates its own gPTP frames with the appropriate timestamps towards the connected downstream devices.

SJA1110 is typically configured for the Layer 2 Automotive Profile, where the PTP destination MAC address is 01:80:C2:00:00:0E. This address is used for 802.1AS/gPTP style Layer 2 transport and such frames are normally handled by the switch PTP/gPTP function rather than simply bridged as regular multicast traffic.

Your observation that the ingress counters increase, while the egress counters do not increase, suggests that the Layer 2 PTP frames are received by the switch but are not forwarded through the normal bridge path. One likely explanation is that the used PTP multicast MAC address is matched by the SJA1110 configuration, for example in the General Parameters table, DPI configuration, L2 Lookup Table or another PTP/trap-related configuration item, and the frames are therefore trapped to the host port, most likely to the internal Cortex-M7 host, instead of being forwarded to the expected external egress port.

This would also explain why PTP over UDP and normal Ethernet traffic such as ICMP/ARP are forwarded correctly. These frames do not match the same Layer 2 PTP/gPTP classification rule and are therefore handled as normal bridge traffic.

Please check the following points in your SJA1110 configuration:

1. Which PTP destination MAC address is configured in the switch, especially in the General Parameters table.

2. Whether PTP/gPTP frames are configured to be trapped to the host port.

3. Whether the internal Cortex-M7 host is running a gPTP stack or receiving the trapped PTP frames.

4. Whether the used destination MAC address is 01:1B:19:00:00:00 or 01:80:C2:00:00:0E.

5. Whether the L2 Lookup Table or multicast forwarding configuration contains an entry that forwards this destination MAC to the required external ports.

6. Whether the ingress and egress ports are in the same VLAN and forwarding domain for this traffic.

If your intention is to use SJA1110 as a gPTP/time-aware bridge, then the expected configuration is usually not simple transparent forwarding of the original gPTP frames. The switch should participate in the gPTP timing domain and generate the corresponding gPTP messages towards the connected devices.

If your intention is instead to use SJA1110 only as a plain Ethernet bridge for raw Layer 2 PTP frames, then the PTP trapping/special handling must be disabled or avoided for this traffic, and the corresponding multicast destination MAC address must be explicitly allowed in the L2 forwarding configuration.

Regarding the PolarFire SoC GEM, I cannot make a definitive statement about the recommended or fully supported PTP transport mode for that device. From the SJA1110 point of view, PTP over UDP may be forwarded as ordinary IP/UDP traffic if the bridge path allows it. However, this does not necessarily mean that UDP transport is supported or recommended by the PolarFire GEM driver for hardware timestamping. Please confirm the supported PTP transport and timestamping modes with the PolarFire SoC GEM documentation or with Microchip support.

Best regards,

Pavel