| ========================= |
| NXP SJA1105 switch driver |
| ========================= |
| |
| Overview |
| ======== |
| |
| The NXP SJA1105 is a family of 10 SPI-managed automotive switches: |
| |
| - SJA1105E: First generation, no TTEthernet |
| - SJA1105T: First generation, TTEthernet |
| - SJA1105P: Second generation, no TTEthernet, no SGMII |
| - SJA1105Q: Second generation, TTEthernet, no SGMII |
| - SJA1105R: Second generation, no TTEthernet, SGMII |
| - SJA1105S: Second generation, TTEthernet, SGMII |
| - SJA1110A: Third generation, TTEthernet, SGMII, integrated 100base-T1 and |
| 100base-TX PHYs |
| - SJA1110B: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX |
| - SJA1110C: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX |
| - SJA1110D: Third generation, TTEthernet, SGMII, 100base-T1 |
| |
| Being automotive parts, their configuration interface is geared towards |
| set-and-forget use, with minimal dynamic interaction at runtime. They |
| require a static configuration to be composed by software and packed |
| with CRC and table headers, and sent over SPI. |
| |
| The static configuration is composed of several configuration tables. Each |
| table takes a number of entries. Some configuration tables can be (partially) |
| reconfigured at runtime, some not. Some tables are mandatory, some not: |
| |
| ============================= ================== ============================= |
| Table Mandatory Reconfigurable |
| ============================= ================== ============================= |
| Schedule no no |
| Schedule entry points if Scheduling no |
| VL Lookup no no |
| VL Policing if VL Lookup no |
| VL Forwarding if VL Lookup no |
| L2 Lookup no no |
| L2 Policing yes no |
| VLAN Lookup yes yes |
| L2 Forwarding yes partially (fully on P/Q/R/S) |
| MAC Config yes partially (fully on P/Q/R/S) |
| Schedule Params if Scheduling no |
| Schedule Entry Points Params if Scheduling no |
| VL Forwarding Params if VL Forwarding no |
| L2 Lookup Params no partially (fully on P/Q/R/S) |
| L2 Forwarding Params yes no |
| Clock Sync Params no no |
| AVB Params no no |
| General Params yes partially |
| Retagging no yes |
| xMII Params yes no |
| SGMII no yes |
| ============================= ================== ============================= |
| |
| |
| Also the configuration is write-only (software cannot read it back from the |
| switch except for very few exceptions). |
| |
| The driver creates a static configuration at probe time, and keeps it at |
| all times in memory, as a shadow for the hardware state. When required to |
| change a hardware setting, the static configuration is also updated. |
| If that changed setting can be transmitted to the switch through the dynamic |
| reconfiguration interface, it is; otherwise the switch is reset and |
| reprogrammed with the updated static configuration. |
| |
| Switching features |
| ================== |
| |
| The driver supports the configuration of L2 forwarding rules in hardware for |
| port bridging. The forwarding, broadcast and flooding domain between ports can |
| be restricted through two methods: either at the L2 forwarding level (isolate |
| one bridge's ports from another's) or at the VLAN port membership level |
| (isolate ports within the same bridge). The final forwarding decision taken by |
| the hardware is a logical AND of these two sets of rules. |
| |
| The hardware tags all traffic internally with a port-based VLAN (pvid), or it |
| decodes the VLAN information from the 802.1Q tag. Advanced VLAN classification |
| is not possible. Once attributed a VLAN tag, frames are checked against the |
| port's membership rules and dropped at ingress if they don't match any VLAN. |
| This behavior is available when switch ports are enslaved to a bridge with |
| ``vlan_filtering 1``. |
| |
| Normally the hardware is not configurable with respect to VLAN awareness, but |
| by changing what TPID the switch searches 802.1Q tags for, the semantics of a |
| bridge with ``vlan_filtering 0`` can be kept (accept all traffic, tagged or |
| untagged), and therefore this mode is also supported. |
| |
| Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but |
| all bridges should have the same level of VLAN awareness (either both have |
| ``vlan_filtering`` 0, or both 1). |
| |
| Topology and loop detection through STP is supported. |
| |
| Offloads |
| ======== |
| |
| Time-aware scheduling |
| --------------------- |
| |
| The switch supports a variation of the enhancements for scheduled traffic |
| specified in IEEE 802.1Q-2018 (formerly 802.1Qbv). This means it can be used to |
| ensure deterministic latency for priority traffic that is sent in-band with its |
| gate-open event in the network schedule. |
| |
| This capability can be managed through the tc-taprio offload ('flags 2'). The |
| difference compared to the software implementation of taprio is that the latter |
| would only be able to shape traffic originated from the CPU, but not |
| autonomously forwarded flows. |
| |
| The device has 8 traffic classes, and maps incoming frames to one of them based |
| on the VLAN PCP bits (if no VLAN is present, the port-based default is used). |
| As described in the previous sections, depending on the value of |
| ``vlan_filtering``, the EtherType recognized by the switch as being VLAN can |
| either be the typical 0x8100 or a custom value used internally by the driver |
| for tagging. Therefore, the switch ignores the VLAN PCP if used in standalone |
| or bridge mode with ``vlan_filtering=0``, as it will not recognize the 0x8100 |
| EtherType. In these modes, injecting into a particular TX queue can only be |
| done by the DSA net devices, which populate the PCP field of the tagging header |
| on egress. Using ``vlan_filtering=1``, the behavior is the other way around: |
| offloaded flows can be steered to TX queues based on the VLAN PCP, but the DSA |
| net devices are no longer able to do that. To inject frames into a hardware TX |
| queue with VLAN awareness active, it is necessary to create a VLAN |
| sub-interface on the DSA master port, and send normal (0x8100) VLAN-tagged |
| towards the switch, with the VLAN PCP bits set appropriately. |
| |
| Management traffic (having DMAC 01-80-C2-xx-xx-xx or 01-19-1B-xx-xx-xx) is the |
| notable exception: the switch always treats it with a fixed priority and |
| disregards any VLAN PCP bits even if present. The traffic class for management |
| traffic has a value of 7 (highest priority) at the moment, which is not |
| configurable in the driver. |
| |
| Below is an example of configuring a 500 us cyclic schedule on egress port |
| ``swp5``. The traffic class gate for management traffic (7) is open for 100 us, |
| and the gates for all other traffic classes are open for 400 us:: |
| |
| #!/bin/bash |
| |
| set -e -u -o pipefail |
| |
| NSEC_PER_SEC="1000000000" |
| |
| gatemask() { |
| local tc_list="$1" |
| local mask=0 |
| |
| for tc in ${tc_list}; do |
| mask=$((${mask} | (1 << ${tc}))) |
| done |
| |
| printf "%02x" ${mask} |
| } |
| |
| if ! systemctl is-active --quiet ptp4l; then |
| echo "Please start the ptp4l service" |
| exit |
| fi |
| |
| now=$(phc_ctl /dev/ptp1 get | gawk '/clock time is/ { print $5; }') |
| # Phase-align the base time to the start of the next second. |
| sec=$(echo "${now}" | gawk -F. '{ print $1; }') |
| base_time="$(((${sec} + 1) * ${NSEC_PER_SEC}))" |
| |
| tc qdisc add dev swp5 parent root handle 100 taprio \ |
| num_tc 8 \ |
| map 0 1 2 3 5 6 7 \ |
| queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ |
| base-time ${base_time} \ |
| sched-entry S $(gatemask 7) 100000 \ |
| sched-entry S $(gatemask "0 1 2 3 4 5 6") 400000 \ |
| flags 2 |
| |
| It is possible to apply the tc-taprio offload on multiple egress ports. There |
| are hardware restrictions related to the fact that no gate event may trigger |
| simultaneously on two ports. The driver checks the consistency of the schedules |
| against this restriction and errors out when appropriate. Schedule analysis is |
| needed to avoid this, which is outside the scope of the document. |
| |
| Routing actions (redirect, trap, drop) |
| -------------------------------------- |
| |
| The switch is able to offload flow-based redirection of packets to a set of |
| destination ports specified by the user. Internally, this is implemented by |
| making use of Virtual Links, a TTEthernet concept. |
| |
| The driver supports 2 types of keys for Virtual Links: |
| |
| - VLAN-aware virtual links: these match on destination MAC address, VLAN ID and |
| VLAN PCP. |
| - VLAN-unaware virtual links: these match on destination MAC address only. |
| |
| The VLAN awareness state of the bridge (vlan_filtering) cannot be changed while |
| there are virtual link rules installed. |
| |
| Composing multiple actions inside the same rule is supported. When only routing |
| actions are requested, the driver creates a "non-critical" virtual link. When |
| the action list also contains tc-gate (more details below), the virtual link |
| becomes "time-critical" (draws frame buffers from a reserved memory partition, |
| etc). |
| |
| The 3 routing actions that are supported are "trap", "drop" and "redirect". |
| |
| Example 1: send frames received on swp2 with a DA of 42:be:24:9b:76:20 to the |
| CPU and to swp3. This type of key (DA only) when the port's VLAN awareness |
| state is off:: |
| |
| tc qdisc add dev swp2 clsact |
| tc filter add dev swp2 ingress flower skip_sw dst_mac 42:be:24:9b:76:20 \ |
| action mirred egress redirect dev swp3 \ |
| action trap |
| |
| Example 2: drop frames received on swp2 with a DA of 42:be:24:9b:76:20, a VID |
| of 100 and a PCP of 0:: |
| |
| tc filter add dev swp2 ingress protocol 802.1Q flower skip_sw \ |
| dst_mac 42:be:24:9b:76:20 vlan_id 100 vlan_prio 0 action drop |
| |
| Time-based ingress policing |
| --------------------------- |
| |
| The TTEthernet hardware abilities of the switch can be constrained to act |
| similarly to the Per-Stream Filtering and Policing (PSFP) clause specified in |
| IEEE 802.1Q-2018 (formerly 802.1Qci). This means it can be used to perform |
| tight timing-based admission control for up to 1024 flows (identified by a |
| tuple composed of destination MAC address, VLAN ID and VLAN PCP). Packets which |
| are received outside their expected reception window are dropped. |
| |
| This capability can be managed through the offload of the tc-gate action. As |
| routing actions are intrinsic to virtual links in TTEthernet (which performs |
| explicit routing of time-critical traffic and does not leave that in the hands |
| of the FDB, flooding etc), the tc-gate action may never appear alone when |
| asking sja1105 to offload it. One (or more) redirect or trap actions must also |
| follow along. |
| |
| Example: create a tc-taprio schedule that is phase-aligned with a tc-gate |
| schedule (the clocks must be synchronized by a 1588 application stack, which is |
| outside the scope of this document). No packet delivered by the sender will be |
| dropped. Note that the reception window is larger than the transmission window |
| (and much more so, in this example) to compensate for the packet propagation |
| delay of the link (which can be determined by the 1588 application stack). |
| |
| Receiver (sja1105):: |
| |
| tc qdisc add dev swp2 clsact |
| now=$(phc_ctl /dev/ptp1 get | awk '/clock time is/ {print $5}') && \ |
| sec=$(echo $now | awk -F. '{print $1}') && \ |
| base_time="$(((sec + 2) * 1000000000))" && \ |
| echo "base time ${base_time}" |
| tc filter add dev swp2 ingress flower skip_sw \ |
| dst_mac 42:be:24:9b:76:20 \ |
| action gate base-time ${base_time} \ |
| sched-entry OPEN 60000 -1 -1 \ |
| sched-entry CLOSE 40000 -1 -1 \ |
| action trap |
| |
| Sender:: |
| |
| now=$(phc_ctl /dev/ptp0 get | awk '/clock time is/ {print $5}') && \ |
| sec=$(echo $now | awk -F. '{print $1}') && \ |
| base_time="$(((sec + 2) * 1000000000))" && \ |
| echo "base time ${base_time}" |
| tc qdisc add dev eno0 parent root taprio \ |
| num_tc 8 \ |
| map 0 1 2 3 4 5 6 7 \ |
| queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \ |
| base-time ${base_time} \ |
| sched-entry S 01 50000 \ |
| sched-entry S 00 50000 \ |
| flags 2 |
| |
| The engine used to schedule the ingress gate operations is the same that the |
| one used for the tc-taprio offload. Therefore, the restrictions regarding the |
| fact that no two gate actions (either tc-gate or tc-taprio gates) may fire at |
| the same time (during the same 200 ns slot) still apply. |
| |
| To come in handy, it is possible to share time-triggered virtual links across |
| more than 1 ingress port, via flow blocks. In this case, the restriction of |
| firing at the same time does not apply because there is a single schedule in |
| the system, that of the shared virtual link:: |
| |
| tc qdisc add dev swp2 ingress_block 1 clsact |
| tc qdisc add dev swp3 ingress_block 1 clsact |
| tc filter add block 1 flower skip_sw dst_mac 42:be:24:9b:76:20 \ |
| action gate index 2 \ |
| base-time 0 \ |
| sched-entry OPEN 50000000 -1 -1 \ |
| sched-entry CLOSE 50000000 -1 -1 \ |
| action trap |
| |
| Hardware statistics for each flow are also available ("pkts" counts the number |
| of dropped frames, which is a sum of frames dropped due to timing violations, |
| lack of destination ports and MTU enforcement checks). Byte-level counters are |
| not available. |
| |
| Device Tree bindings and board design |
| ===================================== |
| |
| This section references ``Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml`` |
| and aims to showcase some potential switch caveats. |
| |
| RMII PHY role and out-of-band signaling |
| --------------------------------------- |
| |
| In the RMII spec, the 50 MHz clock signals are either driven by the MAC or by |
| an external oscillator (but not by the PHY). |
| But the spec is rather loose and devices go outside it in several ways. |
| Some PHYs go against the spec and may provide an output pin where they source |
| the 50 MHz clock themselves, in an attempt to be helpful. |
| On the other hand, the SJA1105 is only binary configurable - when in the RMII |
| MAC role it will also attempt to drive the clock signal. To prevent this from |
| happening it must be put in RMII PHY role. |
| But doing so has some unintended consequences. |
| In the RMII spec, the PHY can transmit extra out-of-band signals via RXD[1:0]. |
| These are practically some extra code words (/J/ and /K/) sent prior to the |
| preamble of each frame. The MAC does not have this out-of-band signaling |
| mechanism defined by the RMII spec. |
| So when the SJA1105 port is put in PHY role to avoid having 2 drivers on the |
| clock signal, inevitably an RMII PHY-to-PHY connection is created. The SJA1105 |
| emulates a PHY interface fully and generates the /J/ and /K/ symbols prior to |
| frame preambles, which the real PHY is not expected to understand. So the PHY |
| simply encodes the extra symbols received from the SJA1105-as-PHY onto the |
| 100Base-Tx wire. |
| On the other side of the wire, some link partners might discard these extra |
| symbols, while others might choke on them and discard the entire Ethernet |
| frames that follow along. This looks like packet loss with some link partners |
| but not with others. |
| The take-away is that in RMII mode, the SJA1105 must be let to drive the |
| reference clock if connected to a PHY. |
| |
| RGMII fixed-link and internal delays |
| ------------------------------------ |
| |
| As mentioned in the bindings document, the second generation of devices has |
| tunable delay lines as part of the MAC, which can be used to establish the |
| correct RGMII timing budget. |
| When powered up, these can shift the Rx and Tx clocks with a phase difference |
| between 73.8 and 101.7 degrees. |
| The catch is that the delay lines need to lock onto a clock signal with a |
| stable frequency. This means that there must be at least 2 microseconds of |
| silence between the clock at the old vs at the new frequency. Otherwise the |
| lock is lost and the delay lines must be reset (powered down and back up). |
| In RGMII the clock frequency changes with link speed (125 MHz at 1000 Mbps, 25 |
| MHz at 100 Mbps and 2.5 MHz at 10 Mbps), and link speed might change during the |
| AN process. |
| In the situation where the switch port is connected through an RGMII fixed-link |
| to a link partner whose link state life cycle is outside the control of Linux |
| (such as a different SoC), then the delay lines would remain unlocked (and |
| inactive) until there is manual intervention (ifdown/ifup on the switch port). |
| The take-away is that in RGMII mode, the switch's internal delays are only |
| reliable if the link partner never changes link speeds, or if it does, it does |
| so in a way that is coordinated with the switch port (practically, both ends of |
| the fixed-link are under control of the same Linux system). |
| As to why would a fixed-link interface ever change link speeds: there are |
| Ethernet controllers out there which come out of reset in 100 Mbps mode, and |
| their driver inevitably needs to change the speed and clock frequency if it's |
| required to work at gigabit. |
| |
| MDIO bus and PHY management |
| --------------------------- |
| |
| The SJA1105 does not have an MDIO bus and does not perform in-band AN either. |
| Therefore there is no link state notification coming from the switch device. |
| A board would need to hook up the PHYs connected to the switch to any other |
| MDIO bus available to Linux within the system (e.g. to the DSA master's MDIO |
| bus). Link state management then works by the driver manually keeping in sync |
| (over SPI commands) the MAC link speed with the settings negotiated by the PHY. |
| |
| By comparison, the SJA1110 supports an MDIO slave access point over which its |
| internal 100base-T1 PHYs can be accessed from the host. This is, however, not |
| used by the driver, instead the internal 100base-T1 and 100base-TX PHYs are |
| accessed through SPI commands, modeled in Linux as virtual MDIO buses. |
| |
| The microcontroller attached to the SJA1110 port 0 also has an MDIO controller |
| operating in master mode, however the driver does not support this either, |
| since the microcontroller gets disabled when the Linux driver operates. |
| Discrete PHYs connected to the switch ports should have their MDIO interface |
| attached to an MDIO controller from the host system and not to the switch, |
| similar to SJA1105. |
| |
| Port compatibility matrix |
| ------------------------- |
| |
| The SJA1105 port compatibility matrix is: |
| |
| ===== ============== ============== ============== |
| Port SJA1105E/T SJA1105P/Q SJA1105R/S |
| ===== ============== ============== ============== |
| 0 xMII xMII xMII |
| 1 xMII xMII xMII |
| 2 xMII xMII xMII |
| 3 xMII xMII xMII |
| 4 xMII xMII SGMII |
| ===== ============== ============== ============== |
| |
| |
| The SJA1110 port compatibility matrix is: |
| |
| ===== ============== ============== ============== ============== |
| Port SJA1110A SJA1110B SJA1110C SJA1110D |
| ===== ============== ============== ============== ============== |
| 0 RevMII (uC) RevMII (uC) RevMII (uC) RevMII (uC) |
| 1 100base-TX 100base-TX 100base-TX |
| or SGMII SGMII |
| 2 xMII xMII xMII xMII |
| or SGMII or SGMII |
| 3 xMII xMII xMII |
| or SGMII or SGMII SGMII |
| or 2500base-X or 2500base-X or 2500base-X |
| 4 SGMII SGMII SGMII SGMII |
| or 2500base-X or 2500base-X or 2500base-X or 2500base-X |
| 5 100base-T1 100base-T1 100base-T1 100base-T1 |
| 6 100base-T1 100base-T1 100base-T1 100base-T1 |
| 7 100base-T1 100base-T1 100base-T1 100base-T1 |
| 8 100base-T1 100base-T1 n/a n/a |
| 9 100base-T1 100base-T1 n/a n/a |
| 10 100base-T1 n/a n/a n/a |
| ===== ============== ============== ============== ============== |
