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.
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
/sys/devices/soc0/soc.1/2000000.aips-bus/snvs.14/20cc034.snvs-rtc-lp/power/wakeup
/sys/devices/soc0/soc.1/2000000.aips-bus/20c9000.usbphy/power/wakeup
/sys/devices/soc0/soc.1/2000000.aips-bus/2000000.spba-bus/2020000.serial/tty/ttymxc0/power/wakeup
/sys/devices/soc0/soc.1/2000000.aips-bus/20ca000.usbphy/power/wakeup
/sys/devices/soc0/soc.1/2000000.aips-bus/2090000.can/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184000.usb/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184000.usb/ci_hdrc.0/usb1/1-1/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184000.usb/ci_hdrc.0/usb1/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184000.usb/ci_hdrc.0/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184200.usb/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.1/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/2184200.usb/ci_hdrc.1/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/21e8000.serial/tty/ttymxc1/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/21f4000.serial/tty/ttymxc4/power/wakeup
/sys/devices/soc0/soc.1/2100000.aips-bus/21f0000.serial/tty/ttymxc3/power/wakeup
Example:
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
29264
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
396000
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.
Debug
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.
RS232
Some hardware also feature one or more RS232 interfaces.
Please note, that there might be no handshake lines available on the RS232 connector.
RS485
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.
USB
USB-Host
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.
USB-OTG
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
100MBit-Ethernet
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.
1GBit-Ethernet
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 can0
listed 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).
WiFi
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).
network={
ssid="SSID"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
psk="mywifikey"
}
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:
hostapd.conf
interface=uap0
ssid=kontron-demo
hw_mode=g
channel=6
auth_algs=1
wmm_enabled=0
dnsmasq.conf
# DHCP-Server active for WiFi
interface=uap0
# DHCP-Server not active for Ethernet
no-dhcp-interface=eth0
# IPv4 range and lease time
dhcp-range=192.168.2.2,192.168.2.254,24h
# DNS
dhcp-option=option:dns-server,192.168.2.1
listen-address=127.0.0.1
listen-address=192.168.2.1
interfaces
auto lo
iface lo inet loopback
# Wired interfaces
auto eth0
iface eth0 inet static
address 192.168.1.11
netmask 255.255.255.0
# Wireless interfaces
auto mlan0
iface mlan0 inet static
address 192.168.3.1
netmask 255.255.255.0
up iw dev mlan0 interface add uap0 type __ap
up ifconfig uap0 192.168.2.1
auto uap0
iface uap0 inet static
address 192.168.2.1
netmask 255.255.255.0
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.
Storage
NAND-Flash
The NAND-Flash-Chip usually contains the root-filesystem including devicetrees and kernel image.
NOR-Flash
The NOR-Flash-Chip usually contains the U-Boot bootloader and the U-Boot environment.
SD-Card
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.
eMMC
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.
GPIOs
The GPIOs are usually already exported to the Linux system on booting. The configuration as input or output or both takes place in the devicetree.
To read an input you can do:
cat /sys/class/gpio/<gpio-label>/value
To set an output you can do:
echo 1 > /sys/class/gpio/<gpio-label>/value
RTC
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
Audio
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
PWM-Beeper
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>)
To control the volume of the beeper you can set a volume level between 0 (mute) and MAX in /sys/class/input/inputX/volume
, while MAX is the maximum volume level reported in /sys/class/input/inputX/max_volume_level
.
The volume levels can be customized in the devicetree.