CM-iTC: Linux: Mint

From Compulab Mediawiki
Revision as of 15:20, 19 March 2013 by Grinberg (talk | contribs) (→‎Hardware-accelerated flashplayer)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.
Admolition note.png 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)
Admolition note.png 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

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.

Admolition note.png 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

Retrieved from "https://mediawiki.compulab.com/w/index.php?title=CM-iTC:_Linux:_Mint&oldid=1484"