Difference between revisions of "CM-iTC: Linux: Mint"

From Compulab Mediawiki
Jump to: navigation, search
(→‎Watchdog)
Line 5: Line 5:
 
In the provided ready-to-run image {{filename|syslinux}} bootloader is installed instead of commonly used {{filename|grub}}. At the current state neither legacy {{filename|grub}} nor {{filename|grub2}} can boot Linux from SD Card on the CM-iTC.
 
In the provided ready-to-run image {{filename|syslinux}} bootloader is installed instead of commonly used {{filename|grub}}. At the current state neither legacy {{filename|grub}} nor {{filename|grub2}} can boot Linux from SD Card on the CM-iTC.
  
−
Take this in account if you are planning to install another Linux distribution to an SD card. By default, most Linux distributions use grub and you will need to replace it with
+
Take this in account if you are planning to install another Linux distribution to an SD card. By default, most Linux distributions use {{filename|grub}} and you will need to replace it with {{filename|syslinux}}.
  
 
== Authorization info ==
 
== Authorization info ==
Line 55: Line 55:
 
</pre>
 
</pre>
 
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)
 
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 {{filename|pch_can}} kernel module is responsible for CAN Bus functionality. Userspace utils for CAN Bus are named {{filename|can-utils}} and can be downloaded
 +
from [http://developer.berlios.de/projects/socketcan Socket-CAN] project.
 +
 +
We present example of basic communication between two SB-iTC boards sharing the same CAN_H and CAN_L lines:
 +
<pre>
 +
# Run initial steps on both boards
 +
itc@cm-iTC ~ $ sudo modprobe can-raw
 +
itc@cm-iTC ~ $ sudo modprobe can-bcm
 +
itc@cm-iTC ~ $ sudo ip link set can0 type can bitrate 500000
 +
itc@cm-iTC ~ $ sudo ifconfig can0 up
 +
itc@cm-iTC ~ $ cd /var/opt/socketcan/can-utils
 +
 +
# See link configuration and status and RX/TX statistics on both boards
 +
itc@cm-iTC ~ $ ip -d -s link show can0
 +
 +
# On one board run candump to view all messages on the bus
 +
itc@cm-iTC ~ $ ./candump -L can0,0:0,#FFFFFFFF
 +
 +
# Send message from another board.
 +
itc@cm-iTC ~ $ ./cansend can0 123#12345678
 +
 +
# As result it will be dumped on the first board
 +
itc@cm-iTC ~ $ ./candump -L can0,0:0,#FFFFFFFF
 +
(1167617833.473521) can0 123#12345678
 +
 +
# See link configuration and status and RX/TX statistics again
 +
itc@cm-iTC ~ $ ip -d -s link show can0
 +
</pre>
 +
 +
== GPIO’s ==
 +
GPIO on SB-iTC consists of 12 general-purpose I/Os from Topcliff packet hub and 6 from Tunnel Creek processor. All the I/Os have interrupt functions and can support asynchronous interrupts.
 +
 +
The {{filename|sch_gpio}} kernel module is responsible for Tunnel Creek GPIOs and the {{filename|pch_gpio}} for Topcliff GPIOs. The kernel modules suppose the following pin naming convention:
 +
 +
{| cellpadding="3" border="1" style="border: 1px solid rgb(85, 85, 85); border-collapse: collapse;"
 +
|+ 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):
 +
<pre>
 +
cm-iTC itc # modprobe sch_gpio
 +
cm-iTC itc # echo 4 > /sys/class/gpio/export
 +
cm-iTC itc # echo out > /sys/class/gpio/gpio4/direction
 +
cm-iTC itc # echo 1 > /sys/class/gpio/gpio4/value
 +
## at this point the CM-iTC ON LED should be in off-state.
 +
cm-iTC itc # echo 0 > /sys/class/gpio/gpio4/value
 +
## at this point the CM-iTC ON LED should be in on-state again.
 +
cm-iTC itc # echo 4 > /sys/class/gpio/unexport
 +
</pre>
 +
 +
The GPIO framework and GPIO sysfs interface are both documented in [http://www.kernel.org/doc/Documentation/gpio.txt 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
 +
Equipped with DMA interface.
 +
 +
== Watchdog ==
 +
The Intel® AtomTM Processor E6xx Series supports a user configurable watchdog timer.
 +
It contains selectable prescaler approximately 1 sec to 10 min.
 +
 +
Once watchdog was enabled the system will be restarted every "timeout" period,
 +
so to prevent it user can restart or disable the watchdog. Default "timeout"
 +
value is 60 sec.
 +
 +
To use it install watchdog utility and edit ''/etc/default/watchdog''.
 +
<pre>
 +
itc@cm-iTC ~ $ sudo apt-get install watchdog
 +
itc@cm-iTC ~ $ sudo nano /etc/default/watchdog
 +
# Start watchdog at boot time? 0 or 1
 +
run_watchdog=1
 +
# Load module before starting watchdog
 +
watchdog_module="itc_wdt"
 +
# Specify additional watchdog options here (see manpage).
 +
</pre>
 +
 +
By default watchdog deamon will "feed" the watchdog every 10 sec.
  
 
== See also ==
 
== See also ==

Revision as of 16:55, 22 March 2011

Overview

Linux Mint for the CM-iTC is based on standard Linux Mint 10 "Julia". The Linux package for CM-iTC contains run-time image with a full-featured desktop filesystem. Network, sound and graphics should work out of the box.

Bootloader

In the provided ready-to-run image syslinux bootloader is installed instead of commonly used grub. At the current state neither legacy grub nor grub2 can boot Linux from SD Card on the CM-iTC.

Take this in account if you are planning to install another Linux distribution to an SD card. By default, most Linux distributions use grub and you will need to replace it with syslinux.

Authorization info

  • username: itc
  • password: 111111

Customized kernel

  • Based on the 2.6.38 mainline kernel with patches from Ubuntu and Compulab.
  • Available in packages repository
  • Supports most features present on the SB-iTC development board and CM-iTC module.
  • Described in more detail on the Linux kernel for CM-iTC page.

Package management

  • In order to be consistent with Ubuntu/Debian packaging standards, all custom packages provided by CompuLab reside in the repository.
  • This repository contains binaries and sources for the kernel, graphic drivers, libraries, etc. You will receive all required updates automatically.
  • Please refer to Debian Repository HOWTO for information about working with a Ubuntu/Debian repositories.

Graphic support

Admolition note.png The current state of the EMGD drivers may be called alpha version. They are not included in any official Linux distribution yet. There are still a few technical issues to be fixed. Known issues are listed below.
  • Known issues
    • Display artefacts when visual effects are enabled. Work-around: Set Preferences->Appearance->Visual Effects to "None"

MPlayer

The E6xx graphic module provides support for the hardware decoding of the most popular video formats. The well-known MPlayer media player is patched for this purpose 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.

Please refer to official mplayer-vaapi page for more information.

Sound

There are two sound cards available in the evaluation kit, one on the CM-iTC core module and another on the SB-iTC baseboard. Current Linux drivers allow only one of the two cards to be active at any given time. The /etc/modprobe.d/alsa-base.conf file specifies which card will be active.

  • To use the CM-iTC sound card, add this line to /etc/modprobe.d/alsa-base.conf:
options snd-hda-intel probe_mask=0x1

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 card, add this line to /etc/modprobe.d/alsa-base.conf:
options snd-hda-intel probe_mask=0x2

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 Socket-CAN project.

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

# Run initial steps on both boards
itc@cm-iTC ~ $ sudo modprobe can-raw
itc@cm-iTC ~ $ sudo modprobe can-bcm
itc@cm-iTC ~ $ sudo ip link set can0 type can bitrate 500000
itc@cm-iTC ~ $ sudo ifconfig can0 up
itc@cm-iTC ~ $ cd /var/opt/socketcan/can-utils

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

# On one board run candump to view all messages on the bus
itc@cm-iTC ~ $ ./candump -L can0,0:0,#FFFFFFFF

# Send message from another board. 
itc@cm-iTC ~ $ ./cansend can0 123#12345678

# As result it will be dumped on the first board
itc@cm-iTC ~ $ ./candump -L can0,0:0,#FFFFFFFF
(1167617833.473521) can0 123#12345678

# See link configuration and status and RX/TX statistics again
itc@cm-iTC ~ $ 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 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): 

cm-iTC itc # modprobe sch_gpio
cm-iTC itc # echo 4 > /sys/class/gpio/export
cm-iTC itc # echo out > /sys/class/gpio/gpio4/direction
cm-iTC itc # echo 1 > /sys/class/gpio/gpio4/value
## at this point the CM-iTC ON LED should be in off-state.
cm-iTC itc # echo 0 > /sys/class/gpio/gpio4/value
## at this point the CM-iTC ON LED should be in on-state again.
cm-iTC itc # 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

Equipped with DMA interface.

Watchdog

The Intel® AtomTM Processor E6xx Series supports a user configurable watchdog timer. It contains selectable prescaler approximately 1 sec to 10 min.

Once watchdog was enabled the system will be restarted every "timeout" period, so to prevent it user can restart or disable the watchdog. Default "timeout" value is 60 sec.

To use it install watchdog utility and edit /etc/default/watchdog. 

itc@cm-iTC ~ $ sudo apt-get install watchdog
itc@cm-iTC ~ $ sudo nano /etc/default/watchdog 
# Start watchdog at boot time? 0 or 1
run_watchdog=1
# Load module before starting watchdog
watchdog_module="itc_wdt"
# Specify additional watchdog options here (see manpage).

By default watchdog deamon will "feed" the watchdog every 10 sec.

See also

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