Automotive In-Vehicle Networking Software

Last modified by Christian Herber on 2019/05/02 08:24

Automotive In-Vehicle Networking Software

Automotive in–vehicle networks connect Electronic Control Units (ECUs) within a vehicle. Different networking technologies are used including Ethernet, FlexRay, CAN, and LIN. This project contains software supporting the use of products for in–vehicle networking use cases. Mainly, this covers device drivers for transceiver and switch products.

Frequently Asked Questions (FAQ)


1. What Linux kernel versions are the drivers compatible with?

A: In general, the drivers are typically tested on one or few kernel versions which are used in NXP's automotive products. However, they should be compatible with a range of kernel versions. In some versions, the relevant APIs may change so that drivers can become incompatible. In this case porting the driver is often trivial. Details on which kernel versions are supported should be inferred from the respective readme files within.

2. Can I use the driver for free?

A: The drivers are provided under open source license and thus usable free of charge.

3. What do I need to consider if I want to use both the phy and the switch driver?

A: Since the SJA1105PQRS driver depends on the phy driver (e.g. TJA110x driver), it is important to load the phy driver first.


1. How do I configure the switch?

 A: The initial switch configuration is done by loading a static configuration stream into the switch via SPI. Such a configuration can be generated using the python tools included in this package. For more detailed description of the configuration tables and use cases, please refer to the User Manual and Application Hints on

The tools are also available under platform_independent/cfg. The python script '' is an example configuration for the SJA1105Q application board and can serve as a starting point for own boards.  The script '' will invoke the generation of the configuration as Intel HEX file, convert to binary using and copy into /lib/firmware.

2. Where do I put the static configuration binary?

A: The configuration binary is expected in /lib/firmware/. The naming scheme is as follows: sja1105p_k-n_cfg.bin, where k is the index of the switch to be configured and n is the total number of connected switches. Custom firmware names can be configured in the device tree.

3. Which Information needs to be present in the device tree?

A: The driver expects several per-port properties:

  • Port Configuration (whether it is a host port or not, whether it has a phy connected to it or not)
  • Reference (phandle) to the attached ethernet phy, if any
  • Logical port number of the port
  • (optional) RX-/TX-Clock delay in case the port uses RGMII and requires some delay

For details and examples refer to included documentation in doc/device_tree/ 

4. I loaded the driver but I cannot communicate. How can I debug this?

 A: If the configuration was loaded successfully, the following steps should be taken:

  • Read out the High level errors using the debug FS, located at /sys/kernel/debug/sja1105p-<Switch No.>. If the frames were dropped due to configuration, the reason is indicated and can be fixed by adjusting configuration or test frames. If all counters are 0, no frame reached the switch core
  • Read out the MAC level errors using the debug FS. If these error counters are non-zero, there is typically a problem in interface configuration. Please check speed setting, PHY configuration, and delay configuration in case of RGMII.
  • If both error counter categories or 0, no frame arrived at the switch. Check that your PHYs have active links and scope the enable signals on xMII interfaces if needed.

5. The driver loaded successfully, how can I access link information from userspace?

A: For each logical switch port, the driver creates a network interface that can be accessed by standard Linux networking tools. The link status and link statistics like sent and received bytes and error counters can be accessed for example by ‘ifconfig’.



1. I loaded the driver but I cannot ping/do not have a link/… what to do?

A: A phy driver is directly involved in the Ethernet data path. NXP's PHYs can operate autonomously without a phy driver. If the same problem exists without a driver, the problem is not in the driver. Please check the pin-strapping options on the PHY and the interface configuration on the MAC side.

2. I loaded the PHY driver but it was not detected.

A: To detect the PHY, a correct PHY address must be configured in the device tree. Refer to the included README for more information. The PHY address is determined at power-on by pin-strapping. If only one PHY is connected to the MDIO/MDC of the corresponding MAC, address 0 (broadcast) can be used for ease of bring-up. Please refer to the documentation for more details.

3. What is the “managed mode” of the NXP PHY?

A: NXP PHYs can be operated in autonomous and managed mode, for detailed information refer to the Data sheet/Application Hint of the respective device. The mode of operation can be chosen by using the kernel module parameter "managedMode" when loading the driver module. By default, the phy driver assumes autonomous mode. If you plan on using some of the advanced features of the NXP PHY you should chose the managed mode. 

4. Should I use polling or interrupts?

A: Polling is easier to start with, while interrupt based operation can reduce the overhead inflicted upon the system by the driver. So the recommendation is to start by using polling and transition to interrupts at a later point. Of course, this requires that the interrupt signal is properly connected to the processor. More information on how to setup interrupts can be found in the included README.

5. What features are supported?

A: The driver supports the typical features as given by the Linux PHY framework. In addition, sysFS nodes are available for using advanced features like test modes, loopback, cable test, master/slave selection, and TC-10 wakeup configuration. These configuration files are located at /sys/bus/mdio_bus/devices/<PHY>/configuration/. For a full list, please refer to the README file of the specific driver release.



Open source licenses contained in the project:

The source code available for download from Code Aurora may be covered by one or more different licenses. The files in Code Aurora may contain changes and additions on top of the code from the original source. These changes and additions are covered under the same license as the original source. In many cases, the license is explicitly listed at the beginning of the file. A list of licenses is included for reference purposes only.

Created by Gregory Stinocher on 2017/11/13 19:53
This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 7.4.3 - Documentation