NXP SJA1110 Ethernet Switch Driver Development

The SJA1110 is a family of four pin- and software-compatible automotive Ethernet switch SoCs. Driver work on this family is not ordinary network driver work: switch behaviour is defined by a static configuration table that is uploaded to the device at init, and the driver layer has to match that table exactly. In practice most failures on this family come from that mismatch, not from the Ethernet stack itself.

Scope

  • Static configuration — ports, VLANs and frame-forwarding rules, kept consistent between the configuration tool and the driver code
  • PHY connectivity — RGMII and SGMII, including clock source and skew behaviour that only becomes visible under load
  • OS integration — FreeRTOS, Zephyr or bare-metal, on the NXP RTD SDK or a custom HAL layer
  • Register-level debugging — MDIO/MDC access when the abstraction layer hides the actual failure
  • Real-time packet path — interrupt-driven processing with defined latency behaviour
  • Time synchronisation — hardware timestamping for PTP / IEEE 1588 and 802.1AS

Where the problems actually show up

These are the failure modes that recur on this family, and they are the reason register-level access matters more than the API:

  • Configuration and driver drift. The static configuration is generated once and uploaded at init. If the driver assumes a different port map, VLAN setup or forwarding rule set, the switch works — just not the way anyone expects, and only under specific traffic.
  • Clock and skew on SGMII. The reference clock source decides whether the link negotiates at all. Problems that look like a PHY fault are usually a clock or skew budget issue.
  • MDIO contention. More than one master touching the switch management interface produces intermittent failures that disappear under a debugger.
  • Interrupt behaviour under burst traffic. Average latency is not the requirement; worst-case latency is. Priority inversion in the packet path is the usual cause when a real-time guarantee breaks.
  • Timestamping without the timestamping unit. Hardware timestamping only holds if the switch timestamping path and the 802.1AS setup are actually enabled and the PHY delay is accounted for. Software timestamps are not a substitute.
  • Security features as a driver-only problem. MACsec-capable PHYs such as TJA1121 need key management, not just a working driver.

Toolchain

NXP RTD SDK (Real-time Drivers) for the SJA1110 family, the static configuration tool that generates the uploadable table, and a device-tree or HAL layer where the integration runs on Linux rather than an RTOS. Where the SDK does not cover a case, the driver is written against the register set directly.

What you get

Tested, documented drivers — not a code drop. Configuration files, the assumptions the driver makes, and the test conditions are part of the delivery, because the mismatch between configuration and driver is exactly what breaks later.

FAQ

Is the SJA1110 supported by the standard Linux DSA driver?

The archived NXP Linux driver exists, but it targets a specific device and configuration. For production use the static configuration and the driver have to be generated and validated together, which is where most of the work is.

Can the driver be ported between FreeRTOS, Zephyr and bare-metal?

The hardware access layer can, the OS abstraction cannot. The port, VLAN and forwarding logic is OS-independent; the interrupt and buffer handling is not. That separation is what makes a port feasible.

Why does the switch work in the lab and fail in the vehicle?

Because the lab traffic is not the real traffic. Frame size distribution, burst behaviour and the timestamping path are the variables that change between a bench test and a running system.

Related