CM-iTC: Linux: Mint

Overview

• The Linux distribution on CM-iTC is Linux Mint 13 LTS with full-featured MATE desktop environment.
• All the necessary drivers and tools are already installed.
• Networking, sound, video acceleration, 2D and 3D graphics, watchdog, CAN bus and other features all work out of the box.

Graphic support

• Intel Processor E6xx Series using the SGX535 graphic module from PowerVR.
• Graphic drivers are Intel® Embedded Media and Graphics Drivers.
• Intel® Embedded Graphics Drivers specifically target the needs of embedded platform developers. For more info please review the Users Guide.

The EMGD drivers in their current state are not included in any major Linux distribution yet. There are still a few technical and compatibility issues to be fixed. Known issues are listed below.

• Required xserver-xorg downgrade to 1.9 version

Hardware-accelerated flashplayer

• Hardware-accelerated flashplayer is included in EMGD 1.16
• To test it, open any HD video on youtube and it plays well.

MPlayer

The E6xx graphic module provides support for the hardware decoding of the most popular video formats. MPlayer-VAAPI is a branch of well-known MPlayer media player, it uses hardware decoding capabilities and supports the following codecs:

• MPEG-2
• MPEG-4 ASP (DivX)
• H.263 (MPEG-4 short-video header variant)
• MPEG-4 AVC (H.264)
• Windows Media Video 9 (WMV3)
• Windows Media Video 9 Advanced (VC-1 Advanced profile)

Non-accelerated decoding is currently not supported with the vaapi renderer.

• You can run it from command line only!

$ mplayer /home/username/Videos/h264_1080p_hp_4.1_40mbps_birds.mkv

• mplayer-vaapi source code is available in gitorious page, compiled .deb files at mplayer-vaapi ppa

Audio

There are two audio codecs available, one on the CM-iTC module and another on the SB-iTC baseboard. The CM-iTC audio codec is always available.

If the E9 jumper is in "HDA-BASE" state - both codecs are visible to the system. Current Linux drivers allow only one of the two codecs to be active at any given time. The probe_mask option in /etc/modprobe.d/alsa-base.conf file specifies which codec is active.

• To use the CM-iTC audio codec, add the following line to /etc/modprobe.d/alsa-base.conf:

options snd-hda-intel probe_mask=1

• In this case, the out line is CORE-LINE-OUT (P31) and the in line is CORE-LINE-IN (P29)
• To use the SB-iTC sound codec:

options snd-hda-intel probe_mask=2

• In this case, the out lines are BASE-HOUT-A (P23) and BASE-HOUT-B (P22) and the in line is LINE-IN-C (P21)

CAN Bus

The CM-iTC provides a CAN interface for use in commercial systems. The CAN controller performs communication in accordance with the BOSCH CAN Protocol Version 2.0B Active1 (standard format and extended format). The bit rate can be programmed to a maximum of 1Mbit/s.

The pch_can kernel module is responsible for CAN Bus functionality. Userspace utils for CAN Bus are named can-utils and can be downloaded from can-utils project.

We present example of basic communication between two SB-iTC boards sharing the same CAN_H and CAN_L lines.

Ensure CAN_VCC, P50-29 is connected to +5V, for example P50-27, and CAN_GND P50-35 is conected to GND, for example P50-37

# Run initial steps on both boards
$ sudo ip link set can0 type can bitrate 500000
$ sudo ifconfig can0 up

# See link configuration and status and RX/TX statistics on both boards
$ ip -d -s link show can0

# On one board run candump to view all messages on the bus
$ candump -L can0,0:0,#FFFFFFFF

# Send message from another board. 
$ cansend can0 123#12345678

# As result it will be dumped on the first board
$ candump -L can0,0:0,#FFFFFFFF
(1167617833.473521) can0 123#12345678

# See link configuration and status and RX/TX statistics again
$ ip -d -s link show can0

GPIO’s

GPIO on SB-iTC consists of 12 general-purpose I/Os from Topcliff packet hub and 6 from the Tunnel Creek processor. All the I/Os have interrupt functions and can support asynchronous interrupts.

The sch_gpio kernel module is responsible for Tunnel Creek GPIOs and the pch_gpio for Topcliff GPIOs. The kernel modules suppose the following pin naming convention:

GPIO’s pin naming convention on SB-iTC

GPIO name	HW source	Name on SB-iTC board	Pin on SB-iTC board	Notes
GPIO1	Tunnel Creek	GPIO1	P50-4
GPIO4	Tunnel Creek	GPIO4	P50-10	shared with LED, WD
GPIO7	Tunnel Creek	GPIO_SUS2	P1-48	shared with LVDS_BCTL
GPIO8	Tunnel Creek	GPIO_SUS3	P1-47	shared with LVDS_DDC_CLK
GPIO9	Tunnel Creek	GPIO_SUS4	P1-49	shared with LVDS_DDC_DAT
GPIO12	Tunnel Creek	GPIO_SUS7	P50-1
GPIO244	Topcliff	SB_GPIO0	P50-5
GPIO245	Topcliff	SB_GPIO1	P50-13
GPIO246	Topcliff	SB_GPIO2	P50-15
GPIO247	Topcliff	SB_GPIO3	P50-6
GPIO248	Topcliff	SB_GPIO4	P50-18
GPIO249	Topcliff	SB_GPIO5	P50-7
GPIO250	Topcliff	SB_GPIO6	P50-9
GPIO251	Topcliff	SB_GPIO7	P50-20
GPIO252	Topcliff	SB_GPIO8	P50-11
GPIO253	Topcliff	SB_GPIO9	P50-14
GPIO254	Topcliff	SB_GPIO10	P50-16
GPIO255	Topcliff	SB_GPIO11	P50-38

The GPIO sysfs interface allows users to manipulate any GPIO from userspace (also known as programmable flags). Since it uses gpiolib, all GPIO's on the system may be utilized dynamically.

Userspace utilizes a sysfs control interface to dynamically request and release individual GPIO's. Once a GPIO has been requested, writing to the newly created path allows you to control the direction and the data, while reading from it returns the GPIO data (which usually corresponds to a 0 or 1 representing the signal level).

A basic example of GPIO usage (under root):

$ modprobe sch_gpio
$ echo 4 > /sys/class/gpio/export
$ echo out > /sys/class/gpio/gpio4/direction
$ echo 1 > /sys/class/gpio/gpio4/value
## at this point the CM-iTC ON LED should be in off-state.
$ echo 0 > /sys/class/gpio/gpio4/value
## at this point the CM-iTC ON LED should be in on-state again.
$ echo 4 > /sys/class/gpio/unexport

The GPIO framework and GPIO sysfs interface are both documented in Linux Kernel Documentation :: GPIO

UART

Corresponding device nodes are: /dev/ttyPCH[0-3].

Supports full UART and 2-wire UART:

• UART0 : full UART
• UART1-3 : 2-wire UART

Full-duplex buffering. Full status reporting. Reduces interrupts to CPU by implementing 256-bytes(UART0) or 64-bytes(UART1-3) transmit and receive FIFOs. Independent control of the following: transmission interrupt, reception interrupt, line status interrupt, and FIFOs.

Programmable serial interface:

• 5-, 6-, 7-, or 8-bit character
• Generation and verification of odd parity, even parity, or no parity
• 1, 1.5, and 2 stop bits

Programmable baud rate generator:

• UART0 : from 300 bps to 4Mbps
• UART1-3 : from 300 bps to 1Mbps

Watchdog

The Intel® AtomTM E6xx processor supports a user configurable watchdog. Watchdog timer provides a resolution that ranges from 1 sec to 10 min.

Once the watchdog is enabled the system restarts once the timeout period elapses, so in order to prevent it the user needs to either feed the watchdog or to disable it. By default the timeout value is 60 sec and the watchdog deamon feeds the watchdog every 10 sec. You can overwrite the default settings in /etc/watchdog.conf and /etc/default/watchdog

Watchdog is already installed and configured on the Linux image provide by CompuLab. You can simulate kernel panic (as super user)

$ echo c > /proc/sysrq-trigger

As a result, the watchdog is not fed and the system will reboot after 60 sec

See also

• Getting started with Linux on CM-iTC
• Linux Kernel for CM-iTC