PTP over SJA1110

[Ankur_pixl]

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.

[PavelL]

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

[Ankur_pixl]

Hello,

The destination MAC is 01:1B:19:00:00:00. We're using the switch with the Linux DSA bridge and have no control or configuration access over the Cortex-M7 core.

How do we allow this traffic through in the L2 configuration? We used bridge mdb, but it doesn't work; the entries install and even show as offloaded, yet the frames still aren't forwarded between the ports. Does this need to be set explicitly on the Cortex-M7 core?

Additional context on our setup:

Our MAC/port configuration is as follows:

bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent
bridge mdb add dev br-EPS port t1-6        grp 01:1b:19:00:00:00 permanent

These show as offloaded in bridge -d mdb show, but L2 PTP frames arriving on one port are not forwarded out the other.

Importantly, one of the switch ports does not have a working CPU port; it operates purely as a route between two ports (port-to-port forwarding), with no host/CPU port in that path. Since the reserved multicast 01:1b:19:00:00:00 appears to be trapped to the management/CPU route by default, and that route is not available here, we suspect the frames are being dropped rather than forwarded.

Could you advise how to configure the switch to forward this reserved PTP multicast MAC in hardware between the two user ports, without relying on a CPU/management port?

-- Ankur

[PavelL]

Hello @Ankur_pixl ,

The destination MAC address 01:1B:19:00:00:00 is an IEEE 1588 Layer 2 PTP multicast address. This is different from the 802.1AS / Automotive Profile gPTP destination MAC address 01:80:C2:00:00:0E, which is typically used in the SJA1110 gPTP Automotive Profile configuration.

Based on your description, this does not look like a standard Linux bridge MDB issue. The MDB entries may be correctly installed and even reported as offloaded, but the frame may still not reach the normal multicast forwarding path.

A likely explanation is that the SJA1110 hardware or the SJA1110 DSA driver classifies this destination MAC as a PTP/control frame before the normal L2 multicast forwarding decision is applied. In that case, the frame may be redirected to the CPU/management path instead of being forwarded directly between the two user ports.

This would explain the observed behavior:

- the ingress counter increases, so the frame is received by the switch,

- the MDB entries are installed and shown as offloaded,

- but the egress counter does not increase, because the frame is likely trapped to the CPU/management route before normal port-to-port forwarding is applied.

If the CPU/management route is not available in your port-to-port forwarding path, the trapped frame may effectively be dropped.

Regarding the Cortex-M7: if you are using the switch through the Linux DSA bridge and you do not run or control a gPTP stack on the internal Cortex-M7, then this should not normally be something configured from the Cortex-M7 application. In this use case, the relevant configuration is owned by the Linux DSA driver and by the switch hardware configuration programmed by that driver.

However, "bridge mdb" may not be sufficient if a dedicated PTP/control-frame trap rule is active for 01:1B:19:00:00:00. To forward this traffic directly in hardware between two user ports, the switch configuration would need to ensure that:

1. the PTP/control-frame trap for 01:1B:19:00:00:00 is disabled or bypassed for this traffic, and

2. a valid L2 multicast forwarding entry exists for 01:1B:19:00:00:00 towards the required user ports.

At this point, I would not expect the standard `bridge mdb` command alone to override a lower-level PTP/control-frame trap rule if such a rule is active in the SJA1110 DSA configuration.

As the next step, please check whether your SJA1110 DSA driver or BSP enables PTP hardware timestamping or installs any MAC filter / PTP trap rule for 01:1B:19:00:00:00. If such a rule is present, the solution will likely require a driver-level change or a switch static configuration change, rather than only a runtime Linux bridge MDB command.

Could you please share the following information?

- Linux BSP/kernel version,

- SJA1110 DSA driver source baseline,

- full output of "bridge -d mdb show",

- the involved DSA port names and physical switch port numbers,

- whether PTP hardware timestamping is enabled in the SJA1110 DSA driver,

- and, if possible, a packet capture on the DSA master/CPU interface to confirm whether the Layer 2 PTP frames are being trapped to the CPU path.

With this information we can further check whether the frames are being consumed by the PTP/control trap path, or whether there is another L2 multicast forwarding limitation.

Best regards,

Pavel