introduction
CongatecThe X86 system on module (SOM) includes a board controller component that is connected to the processor via an ESPI bus, and the provision of various functions such as I²C buses, GPIOS, a watchdog timer and various sensors for monitoring tension, fan speed and much more.
For your X86 system-on-module (SOMS), Congatec offers a Yocto-Meta layer: Meta-Congatec-X86. This meta layer includes a driver, a library and tools for networking with the board controller.
The primary problem with the driver provided is its deviation from Standard Linux -APIS. It contains a custom drawing device and is based on custom ioctl() For communication with the user space. This non-standard approach leads to compatibility and portability problems. For example, an application that the Standard Linux -GPio -API with Standard -Linux -API used would have to be adapted to access the GPIOs of Congatec’s Board Controller. Similarly, software, which was specially developed for the GPIOs of the Board Controller, would have to require changes to work with GPIOs on other platforms.
Since the driver is outside the customs, he also raises concerns about long -term support and maintenance. Questions arise, of course – will the driver be updated regularly in order to remain compatible with future Linux kernel versions in view of the instability of internal APIs? Are errors and security gaps addressed in good time?
One of our customers plans to use Conga-Sa7 Board in a commercial product recognized these challenges at an early stage. As a result, you have asked us to integrate support for the Congatec board controller directly into the Mainline -Line Linux core. The course of the driver in the kernel would guarantee these problems with better portability, long -term maintenance and support of the community.
First support
The project scope initially concentrated on the fulfillment of certain customer requirements, which was limited to a subgroup of the features of the Board Controller: Watchdog, I2C and GPIOS.
As already mentioned, the board controller is connected to the processor via an ESPI bus. Thanks to the source code for the user -defined driver and the available library, it was trivial to determine the protocol that was used to communicate with the board controller and implemented a clean, standard linux kernel driver.
Since the Board Controller offers several functions, we used the use Multifunctional device Subsystem: If you are not familiar with MFD, we recommend looking at this Consequences of Bootlin Engineer Alexandre Belloni on this topic.
Our MFD driver is in Driver/mfd/cgbc-core.c and is essentially responsible for:
- Binding against the board controller when it is recognized. Since the Board Controller is not defined in the ACPI tables, which are provided by the Congatec SOC firmware/BIOS, we use The DMI table This will recognize the card that we are on a hardware platform that contains this special board controller
- Provision of supply functions that make it possible to communicate with the board controller. These user functions are used by the Undermaker to actually do their work.
- Instantiating The sub -carers: First a watchdog, a GPIO controller and two I2C controllers
The MFD driver itself delivers a few sysfs Entries that enable, for example, to call up the Board Controller version:
# cat /sys/devices/platform/cgbc/cgbc_version CGBCP032
In addition, 3 specific drivers were implemented for each of the 3 functions for support:
Thanks to these drivers, the different functions are now exposed via the Standard Linux APIs. For example for Watchdog:
# wd_identify CGBC Watchdog
For GPIO:
# gpiodetect | grep cgbc gpiochip5 (cgbc-gpio) (14 lines) # gpioinfo 5 gpiochip5 - 14 lines: line 0: unnamed unused output active-high line 1: unnamed unused output active-high line 2: unnamed unused output active-high line 3: unnamed unused output active-high line 4: unnamed unused output active-high line 5: unnamed unused output active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high
And for I2C:
# i2cdetect -l | grep Congatec i2c-11 i2c Congatec General Purpose I2C adapter I2C adapter i2c-13 i2c Congatec Power Management I2C adapter I2C adapter
This first set of drivers went through 3 iterations on the public Linux Kernel mailing lists and was then merged as part of the Linux 6.13 version. See also the individual:
In addition to I2C, Watchdog and GPIO, the Board Controller has many sensors (tension, electricity, fan), and we also wanted to support them. For this purpose we have an additional HWMON driver able Driver/hwmon/cgbc-hwmon.cAnd added an additional subtif that describes these sensors in the MFD driver. With this new driver, the sensors are now available via SYSFS that is the standard -API for HWMON and can be read with sensors Command line tool:
$ sensors cgbc_hwmon-isa-0000 Adapter: ISA adapter DC Runtime Voltage: 4.93 V Chipset Temperature: +48.0 C Board Temperature: +44.0 C
This additional driver was merged as Linux 6.15. See also the individual:
Add Conga-Sa8 support
How our customer rates Conga-Sa8We also added the upstream support. Since both the Conga-Sa7 and the Conga-Sa8 boards issue the same board controller, the only change that is necessary to support the new board was to add a new DMI entry to the MFD driver:
static const struct dmi_system_id cgbc_dmi_table() __initconst = (...) .ident = "SA8", .matches = DMI_MATCH(DMI_BOARD_VENDOR, "congatec"), DMI_MATCH(DMI_BOARD_NAME, "conga-SA8"), , , ;
This change also went into the upstream Linux 6.15 version, see commit:
Go on
Some characteristics of the board controller do not remain supported, e.g. We have made some attempts to implement a Backlight driver without success. There are also many Congatec boards to support (with more or less effort). So you are welcome to test and contribute!