CM-iTC: Linux: Mint
- 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.
- 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 is included in EMGD 1.16
- To test it, open any HD video on youtube and it plays well.
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-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
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)
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 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 name||HW source||Name on SB-iTC board||Pin on SB-iTC board||Notes|
|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|
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
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
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