Using the Hardware

This page shows you how to access different peripherals and features of the hardware in general. To find out details about the board configuration and peripherals on a specific board, navigate to the hardware description page of that board.

SOC/Board Features

Sleep Modes

The system can be suspended to one of two sleep modes.
Please note that the actual state of the board and the devices in sleep mode depends on the hardware and software configuration and especially on the availability of a power management controller (PMIC).

1. Standby

> echo standby > /sys/power/state

In this state the CPU will be halted and if possible peripheral devices will be put in low-power mode.

2. Suspend to RAM

> echo mem > /sys/power/state

In this state the CPU and if possible any peripheral devices and buses will be halted. Only the RAM remains powered to keep the state of the system for wakeup.

To wake up from standby, multiple wakeup sources can be defined. By default only the built in RTC of the i.MX6 is enabled as wakeup source.
To list all drivers that expose a wakeup property in sysfs, you can run:

> find /sys -name wakeup

To wake up the system after 20 seconds using the internal RTC:

> echo +20 > /sys/class/rtc/rtc1/wakealarm

Other wakeup sources (such as GPIOs) can be added via devicetree or by using drivers that implement wakeup functionality.

Thermal Management

The i.MX6 contains a temperature sensor to measure the CPU temperature. The driver offers to set two "trip points". If the temperature is rising above trip point 0 (default 85°C), the CPU frequency is lowered by the DVFS driver (digital voltage and frequency scaling, this driver is registered as "cooling device" in the thermal driver).
If the temperature rises above trip point 1 (default 100°C), the system is shut down and can only be restarted if it has cooled down.

Measure the CPU temperature in millis of °C:

> cat /sys/class/thermal/thermal_zone0/temp

Set trip point 0 to 80°C:

> echo 80000 > /sys/class/thermal/thermal_zone0/trip_point_0_temp

CPU-Frequency Scaling

In the devicetree there is a set of operating points, that define voltage and frequency values for the CPU core. The cpufreq driver is able to switch between these operating points depending on the load or temperature.
To define the behaviour of the switching, a "governor" is specified in the driver.

To read the current CPU frequency in kHz:

> cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

To save power and always set the CPU to a low frequency, set the powersave governor:

> echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

To gain best performance and always set the CPU to a high frequency, set the performance governor:

> echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

To scale the frequency depending on the load, set the interactive governor (default):

> echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

For further information also see: cpufreq user-guide

Serial Interfaces

The following section provides general information on the serial interfaces found on Kontron hardware. For specific information on a certain board, please see the according hardware description.


There's usually one UART, that is used as a debug and control interface to connect with terminal application on a PC via a Micro-USB header
Depending on the hardware, the board contains an FTDI-USB-Chip or requires an external USB-Adapter to translate the UART-Signals to USB.
To connect with the debug-interface you can use terminal applications like TeraTerm (Windows), GtkTerm (Linux with GUI), screen (Linux shell) or the like. Set your terminal to 115200 baud 8N1.


Some hardware also feature one or more RS232 interfaces.
Please note, that there might be no handshake lines available on the RS232 connector.


If your hardware features a RS485 port, it is usually initialized by the driver and can be used in your application right away, just the same as you would use any other serial interface. The DE-Signal for the RS485-Transceiver is handled by the driver.



The USB-Host-Ports can be used to attach common USB-devices like thumbdrives, keyboards, etc. Please note, that some device drivers might need to be enabled in the kernel config first, before those devices work correctly. Using USB storage devices is also possible in the bootloader.


A USB-OTG port can be used as an additional host interface, or as USB device. If the hardware supports it, it can be switched to OTG mode to provide host or device functionality depending on the connected device.
The mode for the OTG port is defined in the devicetree.

Network Interfaces


The i.MX6DL/D/Q has an internal Ethernet-Controller (FEC), that is connected to an external PHY on the Kontron demoboard. This interface is available on eth0 by default and it can also be used in the bootloader (e.g. for network booting).
The i.MX6UL has two internal Ethernet-Controllers, whereas only one PHY is found on the Kontron SoM module. To use the second ethernet, a second PHY on the baseboard is needed.


Some boards have an additional Gigabit-Ethernet-Controller connected via USB.

FlexCan (SocketCan)

If your hardware features a CAN port and it is correctly setup in the devicetree, you can use it in Linux by installing the packages libsocketcan and canutils.
If the Packages are installed you can set up the interface by using the command:

ifconfig can0 up

Afterwars you'll see the interface can0listed when calling ifconfig without parameter.
Configuration of the Interface is possible with the command canconfig can0 from the package canutils and permanently in the file /etc/network/interfaces.

Sending and receiving from the interface can be done with the commands cansend and candump (also from package canutils).


If your hardware has an onboard WiFi module you can usually enabled it by issuing ifconfig mlan0 up.
The used modules on recent Kontron hardware are from the LILY and ELLA series from u-blox.

WiFi as client

To setup the WiFi to connect to an AP, you usually have to install and setup wpa-supplicant. Here's an example /etc/wpa_supplicant/wpa_supplicant.conf for a WPA2 network (your AP might need different settings).


By calling 'wpa_supplicant -B -i mlan0 -c /PATH/TO.CONF -D wext' you can connect to the wireless network. With the command 'udhcpc -i mlan0' you will get an IP.

WiFi as Access Point (AP)

To setup the WiFi for use as an AP you usually have to install the packages hostapd and dnsmasq.
Here is a configuration example for a simple unencrypted AP:

# DHCP-Server active for WiFi

# DHCP-Server not active for Ethernet

# IPv4 range and lease time

auto lo
iface lo inet loopback

# Wired interfaces
auto eth0
iface eth0 inet static

# Wireless interfaces
auto mlan0
iface mlan0 inet static
    up iw dev mlan0 interface add uap0 type __ap
    up ifconfig uap0

auto uap0
iface uap0 inet static
    up /etc/init.d/hostapd restart

Display Interfaces

In general there are three possible interfaces to connect a display to a Kontron demoboard: RGB, LVDS and HDMI. It is also possible to use two displays at the same time if certain conditions are met.

Depending on the kernel and bootloader settings, the display interfaces are mapped to framebuffer devices (/dev/fbX), whereas fb0 is the primary display and fb2 the secondary display. fb1 and fb3 are used for overlays on the primary and secondary displays and are generally not used.

To test the display without running an application you can first enable it:

> echo 0 > /sys/class/graphics/fb0/blank

and then write some random data to the display to get colored pixels:

> dd if=/dev/urandom of=/dev/fb0

The display interfaces are configured in the devicetree and in the bootloader environment variables.

Backlight brightness

To change the screen backlight the file /sys/class/backlight.19/brightness has to be modified. Values from zero (maximal brightness) to seven (dark) are valid.
In the following example the backlight will be first set to dark and afterwards changed to maximal brightness.

> echo 7 > /sys/class/backlight/backlight.19/brightness
# dark
> echo 0 > /sys/class/backlight/backlight.19/brightness
# maximal brightness

It should be mentioned, that the settings need to be saved as ASCII string into the file. If the file will not be closed after writing the values, the separate strings of the set brightness have to end with a newline (\n).

Touch Devices

Kontron offers different display solutions with different touch panels. Depending on the setup, there's usually a touch controller connected to the i.MX6 via I²C or USB.



The NAND-Flash-Chip usually contains the root-filesystem including devicetrees and kernel image.


The NOR-Flash-Chip usually contains the U-Boot bootloader and the U-Boot environment.


Most Kontron boards feature an onboard micro-SD card slot. The SD-card can be used as boot device, or as general file storage.
Please note, that depending on what card you use, there are limitations on the write cycles and general durability of the card. For a longer lifespan, especially in applications with heavy SD-card usage, we recommend to not use commercial grade, but industrial grade cards.


Some Kontron boards have an onboard eMMC chip instead of a NAND flash. eMMC can be used the same way as a normal SD-card.


Controlled by sysfs (since Kernel 4.8 deprecated)

export gpio

echo <gpio_number> > /sys/class/gpio/export

set direction (input/output):

echo input > /sys/class/gpio/gpio<gpio-number>/direction

echo output > /sys/class/gpio/gpio<gpio-number>/direction

set gpio (output):

echo 1 > /sys/class/gpio/gpio<gpio-number>/value

read gpio (input):

cat > /sys/class/gpio/gpio<gpio-number>/value

Controlled by libgpiod tools (need Kernel v4.7 or higher)

libgpiod provides a cleaner interface to gpios. For example you can print the available gpios on the system.


gpiochip4 [20ac000.gpio] (32 lines)
gpiochip3 [20a8000.gpio] (32 lines)
gpiochip2 [20a4000.gpio] (32 lines)
gpiochip1 [20a0000.gpio] (32 lines)
gpiochip0 [209c000.gpio] (32 lines)

That means you have 5 groups witch each of 32 gpios

read the value of a single gpio line:

gpioget gpiochip1 23

set the value of a single gpio line:

gpioset gpiochip1 23=1

It is also possible to wait for events on gpio-lines. For further reading please have a look at:


Internal RTC

The i.MX6 has an internal RTC for timekeeping, but on most Kontron boards there is an additional external RTC with higher accuracy and therefore the internal RTC is not used.

External RTC

The external RTC is bufferd by a battery to keep the time when the device is not powered. The RTC can be accessed via the hwclock command (see Linux documentation for further information).
The accuracy of the external clock is about 1 minute per month.

The default BSP setting is to perform a sync RTC to system time on booting and a sync system time to RTC on shutdown. This guarantees, that changes to the systemtime are kept while the device is powered down.

To perform synchronisations manually, you can use hwclock:

RTC to system time:

> hwclock --hctosys

system time to RTC:

> hwclock --systohc


To list all soundcards you can use the following command:

cat /proc/asound/cards

To test your soundcard you can use the command speaker-test:

speaker-test -t sine -f 1000


Some of the custom Kontron boards (not the demoboard) feature a PWM-controlled beeper. It is registered in evdev and can be controlled via the userspace tool beep, by sending a BEL character to the console (echo -e "\a" > /dev/tty0), or by using ioctl("/dev/input/eventX",KIOCSOUND,<tone>)