GARZ&FRICKE Yocto User manual
Yocto
User Manual
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
Built on 18.08.2017
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
Important hints
Thank you very much for purchasing a Garz & Fricke product. Our products are dedicated to professional use
and therefore we suppose extended technical knowledge and practice in working with such products.
The information in this manual is subject to technical changes, particularly as a result of continuous
product upgrades. Thus this manual only reflects the technical status of the products at the time
of printing. Before design-in the device into your or your customer’s product, please verify that this
document and the therein described specification is the latest revision and matches to the PCB
version. We highly recommend contacting our technical sales team priorto any activity of that kind. A
good way getting the latest information is to check the release notes of each product and/or service.
Please refer to the chapter [
I
12 Related documents and online support].
The attached documentation does not entail any guarantee on the part of Garz & Fricke GmbH with
respect to technical processes described in the manual or any product characteristics set out in the
manual. We do not accept any liability for any printing errors or other inaccuracies in the manual
unless it can be proven that we are aware of such errors or inaccuracies or that we are unaware
of these as a result of gross negligence and Garz & Fricke has failed to eliminate these errors or
inaccuracies for this reason. Garz & Fricke GmbH expressly informs that this manual only contains
a general description of technical processes and instructions which may not be applicable in every
individual case. In cases of doubt, please contact our technical sales team.
In no event, Garz & Fricke is liable for any direct, indirect, special, incidental or consequential damages
arising out of use or resulting from non-compliancy of therein conditions and precautions, even if
advised of the possibility of such damages.
Before using a device covered by this document, please carefully read the related hardware manual
and the quick guide, which contain important instructions and hints for connectors and setup.
Embedded systems are complex and sensitive electronic products. Please act carefully and ensure
that only qualified personnel will handle and use the device at the stage of development. In the event
of damage to the device caused by failure to observe the hints in this manual and on the device
(especially the safety instructions), Garz & Fricke shall not be required to honour the warranty even
during the warranty period and shall be exempted from the statutory accident liability obligation.
Attempting to repair or modify the product also voids all warranty claims.
Before contacting the Garz & Fricke support team, please try to help yourself by the means of this
manual or any other documentation provided by Garz & Fricke or the related websites. If this does not
help at all, please feel free to contact us or our partners as listed below. Our technicians and engineers
will be glad to support you. Please note that beyond the support hours included in the Starter Kit,
various support packages are available. To keep the pure product cost at a reasonable level, we have
to charge support and consulting services per effort.
Shipping address:
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Germany
Support contact:
Phone +49 (0) 40 / 791 899 - 30
Fax +49 (0) 40 / 791 899 - 39
Email
I
suppor[email protected]
URL
I
www.garz-fricke.com
© Copyright 2016 by Garz & Fricke GmbH. All rights are reserved.
Copies of all or part of this manual or translations into a different language may only be made
with the prior written approval.
2
Contents
Important hints 2
1 Introduction 4
2 Overview 5
2.1 The bootloader 5
2.2 The Linux kernel 5
2.3 The root file system 5
2.4 The partition layout 6
2.5 Further information 6
3 Accessing the target system 8
3.1 Serial console 8
3.2 SSH console 9
3.3 Telnet console 10
3.4 Uploading files with TFTP 10
3.5 Uploading files with SFTP 11
4 Services and utilities 12
4.1 Services 12
4.1.1 Udev 13
4.1.2 D-Bus 14
4.1.3 SSH service 14
4.1.4 Telnet service 15
4.1.5 Module loading 16
4.1.6 Network initialization 16
4.1.7 Watchdog 16
4.1.8 Garz & Fricke shared configuration 18
4.1.9 Autocopy 18
4.1.10 Autostart 20
4.1.11 Cron 21
4.2 Utilities 22
4.2.1 Garz & Fricke system configuration 22
4.2.2 Power down mode 24
4.2.3 Reboot, Halt and Poweroff 24
4.2.4 Kernel command line 25
4.2.5 Bootlogo 25
4.2.6 Web Browser 27
4.2.7 Boot progress animation 28
4.2.8 Sendmail 29
5 Add-On Packages 30
5.0.9 Using the ’add-ons’ script 30
5.0.10 Direct installation 30
5.0.11 Manual installation 30
5.1 CUPS 31
5.1.1 Installation 31
5.1.2 Configuration 31
5.2 Debug 31
5.2.1 Installation 32
5.2.2 User Applications 32
5.2.3 Kernel Tracing 32
5.2.4 Network Monitoring 33
5.2.5 System Tests 33
6 Accessing the hardware 34
6.1 Digital I/O 34
6.2 Serial interfaces (RS-232 / RS-485 / MDB) 35
6.3 Ethernet 35
6.4 Real Time Clock (RTC) 35
3
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
6.5 Keypad connector 36
6.6 SPI 37
6.7 I2C 37
6.8 CAN 38
6.9 USB 39
6.9.1 USB Host 39
6.9.2 USB Device 39
6.9.3 USB OTG ID pin emulation 40
6.10 Display power 40
6.11 Display backlight 40
6.12 SD cards and USB mass storage 41
6.13 Temperature Sensor 41
6.14 Touchscreen 42
6.15 Audio 42
6.16 SRAM 42
6.17 HDMI 43
6.17.1 HDMI as primary display 43
6.17.2 HDMI as secondary display 43
6.17.3 HDMI as mirror of the internal display 43
6.17.4 HDMI XML configuration 43
6.18 WLAN 45
7 Building and running a user application 46
7.1 SDK installation 46
7.2 Simple command-line application 46
7.3 Qt-based GUI user application 47
7.4 Using the Qt Creator IDE 48
7.4.1 Configuring Qt Creator 48
7.4.2 Developing with Qt Creator 51
7.5 Autostart mechanism for user applications 52
8 Building a Garz & Fricke Yocto Linux system from source 55
8.1 General information about Garz & Fricke Yocto Linux systems 55
8.2 Build requirements 55
8.3 Download and installation of the Garz & Fricke Yocto BSP 55
8.4 Building the BSP for the target platform 56
9 Deploying the Linux system to the target 57
9.1 Booting Flash-N-Go System 57
9.2 Installing a Yocto image on the device 57
9.2.1 Over the network via TFTP 58
9.2.2 From a local folder using an external storage device 58
9.2.3 Control the installation process using parameters 58
10 Securing the device 60
10.1 Services 60
10.2 User permissions concept 60
10.2.1 Root password 60
10.2.2 Non root user 61
10.2.3 super user privileges for non root user 61
10.3 autostart 62
10.4 Flash-N-Go System 62
10.5 Networking 62
10.5.1 Firewall - netfilter/iptables 62
10.5.2 Using secure network protocols 63
10.6 Restrict physical access 63
10.7 Application security 63
11 Debugging 64
11.1 Important hints 64
11.1.1 The debugger needs access to the debug symbols 64
4
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
11.1.2 The debugger needs access to the source files 64
11.1.3 Optimization compiler flags destroy high level language code stepping 64
11.1.4 The symbol files have to originate from the same compile run as their installed stripped counterparts
on the target system 64
11.1.5 Remote vs. native debugging 65
11.1.6 User space code vs. kernel code debugging 65
11.1.7 Known issues 65
11.2 Simple command line application debugging 66
11.2.1 KDbg as simple GUI debug frontend 68
11.3 Qt application debugging 72
12 Related documents and online support 78
A GNU General Public License v2 79
A.1 Preamble 79
A.2 TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 79
A.3 END OF TERMS AND CONDITIONS 82
A.3.1 How to Apply These Terms to Your New Programs 82
B Standard Device Configuration 84
B.1 Operating System 84
B.2 Bootloader 84
B.3 Boot Logo 84
B.4 Serial diagnostic port 84
B.5 IPv4 Settings 84
B.6 Services 85
B.7 Display 85
5
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
1 Introduction
Garz & Fricke systems based on Freescale i.MX6 can be used with an adapted version of Linux, a royalty-
free open-source operating system. The Linux kernel as provided by Garz & Fricke is based on extensions by
Freescale that currently have not been contributed back into the mainline kernel. Furthermore, Garz & Fricke has
made several modifications and extensions to the kernel which are currently not contributed back to the mainline
kernel as well. Nevertheless, the full source code is available as a board support package (BSP) from Garz &
Fricke.
A Garz & Fricke device normally comes with a pre-installed Garz & Fricke Linux operating system. However, since
Linux is an open source system, the user is able to build the complete BSP from source, modify it according to
his needs and replace the pre-installed Linux system with a custom one.
This manual contains information about the usage of the Garz & Fricke Linux operating system for i.MX6, as well
as the build process of the Garz & Fricke Linux BSP and the integration of custom software components. The
BSP can be downloaded from the Garz & Fricke support server:
I
http://support.garz-fricke.com/projects/Santaro/Linux-Yocto/Releases/
It does not include the complete source code to all packages. Instead, several external packages are downloaded
from third party online sources and from the Garz & Fricke packages mirror during the build process: If third party
souces are not available anymore at the former location there should be a backup available at:
I
http://support.garz-fricke.com/mirror
Modifications to these packages are provided as source code patches, which are part of the BSP.
Please note that Linux development at Garz & Fricke is always in progress. Thus, there are new releases of the
BSP at irregular intervals. Due to differences between the various Linux BSP platforms and versions, a separate
manual is available for every platform/version. To avoid confusion, the version number of the manual exactly
matches the BSP version number.
In addition to this manual, please also refer to the dedicated hardware manuals which can be found on the Garz
& Fricke website as well.
6
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
2 Overview
A Garz & Fricke Linux System generally consists of four basic components:
the bootloader
the Linux kernel
the root file system
the device configuration
These software components are usually installed on separate partitions on the backing storage of the embedded
system.
Newer Garz & Fricke devices are shipped with a separate small ramdisk-based Linux system called Flash-N-Go
System which is installed in parallel to the main operating system. The purpose of Flash-N-Go is to provide the
user a comfortable and secure update mechanism for the main operating system components.
2.1 The bootloader
There are several bootloaders available for the various Linux platforms in the big Linux world. For desktop PC
Linux systems, GRUB or LILO are commonly used. Those bootloaders are started by hardwired PC-BIOS.
Embedded Systems do not have a PC-like BIOS. In most cases they are started from raw flash memory or an
eMMC device. For this purpose, there are certain open source boot loaders available, like RedBoot, U-Boot or
Barebox. Furthermore, Garz & Fricke provides its own bootloader called Flash-N-Go Boot for its newer platforms
(e.g. SANTARO).
i.MX6 uses the bootloader Flash-N-Go Boot.
2.2 The Linux kernel
The Linux OS kernel includes the micro kernel specific parts of the Linux OS and several internal device and
subsystem drivers.
2.3 The root file system
The root file system is simply a file system. It contains the Linux file system hierarchy folders and files. Depending
on the system configuration, the root file system may contain:
system configuration files
shared runtime libraries
dynamic device and subsystem drivers - so called loadable kernel modules - in contrast to kernel-included
device and subsystem drivers
executable programs for system handling
fonts
etc.
Usually, a certain standard set of runtime libraries can be found in almost every Linux system, including standard
C/C++ runtime libraries, math support libraries, threading support libraries, etc.
Embedded Linux systems principally differ in dealing with the graphical user interface (GUI). The following list
gives some examples for GUI systems that are commonly used in embedded Linux systems:
no GUI framework
Qt Embedded on top of a Linux frame buffer device
Qt Embedded on top of DirectFB graphics acceleration library
Qt Embedded on top of an X-Server
GTK+ on top of DirectFB graphics acceleration library
GTK+ on top of a X-Server
Nano-X / Microwindows on top of a Linux frame buffer device
Some system may additionally be equipped with a window manager of small footprint or a desktop system like
KDE ore GNOME. However, in practice most embedded Linux Systems are running only one GUI application and
a desktop system generates useless overhead.
i.MX6 is equipped with Qt5 on top of a X-Server.
7
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
2.4 The partition layout
As already stated in chapter [
I
2 Overview], the different components of the embedded Linux system are stored in
different partitons of the backing-storage. The backing-storage type of i.MX6 is eMMC. In addition to the partitions
for the basic Linux components there may be some more partitions depending on the system configuration.
The partition layout for the i.MX6 platform is:
Partition File System Contents
mmcblk0boot0 none bootloader image
mmcblk0boot1 FAT32 XML configuration parametes (config.xml) and touchscreen configuration
(ts.conf)
mmcblk0p1 FAT32 Linux kernel image file (linuximage), bootloader command file
(boot-alt.cfg) and Flash-N-Go ramdisk file (root.cpio.gz)
mmcblk0p2 FAT32 Linux kernel image file (linuximage), the devicetree file (*.dtb) and the
bootloader command file (boot.cfg) for the Garz & Fricke Linux system
mmcblk0p3 ext3 root file system
Flash-N-Go Boot can start the following Linux kernel image types:
zImage compressed image
uImage compressed image with u-boot header
Image uncompressed image
2.5 Further information
For readers who are not familar with Linux in general, the following link may be helpful:
I
http://tldp.org/LDP/intro-linux/html
Information regarding embedded Linux systems can be found in the following book:
"Building Embedded Linux systems 2nd Edition", Karim Yaghmour, John Masters, Gilad Ben-Yossef, Philippe
Gerum, O’Reilly, 2008, ISBN: 978-0-596-52968-0
Information regarding Linux infrastructure issues in general can be found at:
I
http://tldp.org/LDP/Pocket-Linux-Guide/html
I
http://www.linuxfromscratch.org
Information about Qt/Embedded can be found at:
I
http://directfb.org
Information about the X window system can be found at:
I
http://www.freedesktop.org
Information about Qt/Embedded can be found at:
I
http://qt-project.org
Information about Nano-X / Microwindows can be found at:
I
http://www.microwindows.org
Information about GTK+ can be found at:
I
http://www.gtk.org
Information about U-Boot can be found at:
I
http://www.denx.de/wiki/U-Boot
Information about the RedBoot can be found at:
8
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
3 Accessing the target system
A Garz & Fricke hardware platform can be accessed from a host system using the following technologies:
Serial console console access over RS-232
Telnet console access over Ethernet
SSH encrypted console access and file transfer over Ethernet
TFTP file downoad over Ethernet
SFTP file upload and download over Ethernet
Each of the following chapters describes one of these possibilities and, where applicable, gives a short example
of how to use it. For all examples, the Garz & Fricke target system is assumed to have the IP address 192.168.1.1.
3.1 Serial console
The easiest way to access the target is via the serial console. There are two way to connect the serial console:
RS232 on Molex Micro-Fit connector
Virtual console over USB
To use the RS232 connection, connect the first RS232 port of your target system using to a COM port of your PC
or a USB-to-RS232 converter using a null modem cable.
For a working connection, the signals TXD and RXD have to be connected cross-over in the same way like a
null modem cable does. The location of the RS232 connector and the necessary pins can be found in [
I
Figure
1],[
I
Figure 2] below. If you received your system as part of a starter kit, this kit should also contain a cable to
be used for this connection.
Figure 1: Location of the RS232 connector on a 7" device (upper) and on a 5" device (lower)
Pin Name Description
1 GND Ground
2 RS232_TXD1 Port#1: Transmit data (Output)
3 RS232_RXD1 Port#1: Receive data (Input)
4 RS232_RTS1 Port#1: Request-to-send (Output)
5 RS232_CTS1 Port#1: Clear-to-send (Input)
10
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
Figure 2: Pinning of the RS232 connector on a 7" device (left) and on a 5" device (right)
To use the serial console provided over USB, connect a Micro-USB cable to the USB-OTG connector of the
target. When this USB cable is connected to a Windows PC, a driver is installed and a new COM port is created.
Its name can be seen in the device manager.
Note: Although the serial connection over USB is easy to setup, there are some disadvantages over the RS232
connection: The output of the bootloader and the boot messages are not shown. The first thing you see is the
login shell. This way it is not ideal for system updates.
With the serial connection set up start your favourite terminal program (e.g. minicom) with the following settings:
115200 baud
8 data bits
no parity
1 stop bit
no hardware flow control
no software flow control
If you are using the RS232 connection, you should see debug messages in the terminal from the very first moment
when the target is powered. After the boot process has finished, you will see the Linux login shell:
Garz & Fricke Yocto BSP (based on Poky) @VERSION@ santaro /dev/ttymxc0
santaro login:
You can log in as user root without any password by default.
3.2 SSH console
Using SSH, you can access the console of the device and copy files to or from the target. Please note that SSH
must be installed on the host system in order to gain access.
To login via SSH, type on the host system:
The first time you access the target system from the host system, the target is added to the list of known hosts.
You have to confirm this step in order to establish the connection.
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is e5:86:89:19:50:a5:46:52:15:35:e5:0e:d2:d1:f9:62.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
root@santaro:~#
To return to your host system’s console, type:
root@santaro:~# exit
You can use secure copy (scp) on the device or the host system to copy files from or to the device.
Example: To copy the file myapp from the host’s current working directory to the target’s /usr/bin directory, type
on the host’s console:
11
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
To copy the target’s /usr/bin/myapp file back to the host’s current working directory, type:
3.3 Telnet console
Telnet can be used to access the console. Please note that Telnet must be installed on the host system in order
to gain access.
To login via Telnet, type on the host system:
$ telnet 192.168.1.1
The login prompt appears and you can login with username and password:
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
santaro login: root
Password: [Enter password]
root@santaro:~#
3.4 Uploading files with TFTP
You can copy files from the host system to the target system using the target’s TFTP client. Please note that
a TFTP server has to be installed on the host system. Usually, a TFTP server can be installed on every Linux
distribution. To install the TFTP server under Debian based systems with apt, the following command must be
executed on the host system:
$ sudo apt-get install xinetd tftpd tftp
The TFTP server must be configured as follows in the /etc/xinetd.d/tftpd file on the host system in order to
provide the directory /srv/tftp as TFTP directory:
service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /srv/tftp
disable = no
}
The /srv/tftp directory must be created on the host system with the following commands:
$ sudo mkdir /srv/tftp
$ sudo chmod -R 777 /srv/tftp
$ sudo chown -R nobody /srv/tftp
After the above modification the xinetd must be restarted on the host system with the new TFTP service with the
following command:
$ sudo service xinetd restart
From now on, you can access files in this directory from the target.
Example: Copying the file myapp from the host system to the target’s /usr/bin directory. To achieve this, first
copy the file myapp to your TFTP directory on the host system:
12
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
$ cp ./myapp /srv/tftp/
The host system is assumed to have the ip address 192.168.1.100. On the target system, type:
root@santaro:~# tftp -g 192.168.1.100 -r myapp -l /usr/bin/myapp
3.5 Uploading files with SFTP
You can exchange files between the host system and the target system using an SFTP (Secure FTP) client on
the host system. Simply choose your favourite SFTP client (e.g. FileZilla) and connect to sftp://192.168.1.1 with
user root and no password.
13
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
4 Services and utilities
The Garz & Fricke Linux BSP includes several useful services for flexible application handling. Some of them are
just run-once services directly after the OS has been started, others are available permanently.
4.1 Services
The services on Garz & Fricke Yocto Linux systems are usually started with start scripts. This is a very common
technique on Linux systems. Yocto uses the /etc/init.d/rc script for this purpose. This script is run by the init
process after parsing the /etc/inittab file:
[...]
# The default runlevel.
id:5:initdefault:
# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS
# What to do in single-user mode.
~~:S:wait:/sbin/sulogin
# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
[...]
As the comments in the file tell, the first script to be run on boot is /etc/init.d/rcS, which executes all start scripts
in /etc/rcS.d. Afterwards, the default runlevel (5) is entered, which makes the start scripts in /etc/rc5.d being
executed.
All scripts starting with the character Sare executed with the argument start appended, while all scripts starting
with the character Kare executed with the argument stop appended. Furthermore, the naming convention states
that the S/K character is followed by a number which determines the (numeric) execution order.
The actual scripts live in the directory /etc/init.d (e.g. /etc/init.d/myapp) while the /etc/rc* folders contain links
to those scripts (e.g. /etc/rc5.d/S95myapp).
Those script having the following basic layout, though not all scripts in the image contain the header between ###
BEGIN and ### END. Further documentation for the script format can be found here:
I
https://wiki.debian.org/LSBInitScripts .
#!/bin/sh
### BEGIN INIT INFO
# Provides: myapp
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start myapp at boot time
# Description:
### END INIT INFO
14
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
. /etc/profile
case "$\$$1" in
start)
# Add here command that should execute during system startup.
;;
stop)
# Add here command that should execute during system shutdown.
;;
*)
echo "Usage: ... " >&2
exit 1
;;
esac
To create the startup links, put the above script into /etc/init.d/myapp execute:
root@gufboardll:~# update-rc.d myapp defaults 95 05
Adding system startup for /etc/init.d/myapp.
Here 95 is the startup level (late) and 05 is the stop level (early). If those numbers are omitted the level are
determined by the dependencies given in the header of the init script.
Make sure the executable bit is set with:
root@gufboardll:~# chmod +x /etc/init.d/myapp
It is also possible to create the individual links with:
root@gufboardll:~# ln -s /etc/init.d/myapp /etc/rc5.d/S95myapp
A service is disabled using:
root@gufboardll:~# update-rc.d -f myapp remove
update-rc.d: /etc/init.d/myapp exists during rc.d purge (continuing)
Removing any system startup links for myapp ...
/etc/rc0.d/K20myapp
/etc/rc1.d/K20myapp
/etc/rc2.d/S20myapp
/etc/rc3.d/S20myapp
/etc/rc4.d/S20myapp
/etc/rc5.d/S20myapp
/etc/rc6.d/K20myapp
In chapter [
I
7.5 Autostart mechanism for user applications] this mechanism will be used for automatic application
start up.
4.1.1 Udev
The udev service dynamically creates the device nodes in the /dev directory on system start up, as they are
reported by the Linux kernel.
Furthermore, udev is user-configurable to react on asynchronous events from device drivers reported by the Linux
kernel like hotplugging. The according rules are located in the root file system at /lib/udev/rules.d.
Additionally, udev is in charge of loading firware if a device driver requests it. Drivers that use the firmware
subsystem have to place their firmware in the folder /lib/firmware.
The udev service has a startup link that points to the corresponding start script:
/etc/rcS.d/S04udev -> /etc/init.d/udev
15
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
Udev can be configured in /etc/udev/udev.conf.
More information about udev can be found at:
I
https://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html
4.1.2 D-Bus
The dbus service is a message bus system, a simple way for applications to communicate with each another.
Additionally, D-Bus helps coordinating the process lifecycle: it makes it simple and reliable to code a single
instance application or daemon, and to launch applications and daemons on demand when their services are
needed.
Garz & Fricke systems are shipped with dbus bindings for glib and Qt. Therefore, the corresponding APIs can
be used for application programming. Furthermore, Garz & Fricke systems are configured to support HALD that
allows to detect hotplugging events in applications asynchronously.
The dbus service has a startup link that points to the corresponding start script:
/etc/rc5.d/S02dbus-1 -> /etc/init.d/dbus-1
More information about dbus can be found at:
I
http://www.freedesktop.org/wiki/Software/dbus
More information about the Qt dbus bindings can be found at:
I
http://qt-project.org/doc/qt-4.7/intro-to-dbus.html
More information about the glib dbus bindings can be found at:
I
http://dbus.freedesktop.org/doc/dbus-glib
4.1.3 SSH service
The ssh service allows the user to log in on the target system. Futhermore, the SFTP and SCP functionalities
are activated to allow secure file transfers. The communication is encrypted.
The ssh service has a startup link that points to the corresponding start script:
/etc/rc5.d/S09sshd -> /etc/init.d/openssh
The startup script simply starts /usr/sbin/sshd as a daemon. The sshd configuration can be found in the target’s
root file system at /etc/ssh/sshd_config.
More information about OpenSSH can be found at:
I
http://www.openssh.org
Login Garz & Fricke devices are configured to use passwords for authentication also on the ssh service. As
there is no password set for root by default, this is a widely open door for attackers. See the [
I
10 Securing the
device] chapter how to handle this issue.
SSH Keys The Garz & Fricke yocto images are containing default SSH Keys that are the same on every image.
Those keys are used to identify the device when connecting to it from a remote host, to make sure you send
your password to the correct device ( and not some Man-in-the-middle ). To make use of this feature you should
generate your own keys with:
root@gufboardll:~# rm /etc/ssh/ssh_host_*key*
root@gufboardll:~# /etc/init.d/sshd restart
generating ssh RSA key...
generating ssh ECDSA key...
generating ssh DSA key...
16
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
generating ssh ED25519 key...
Restarting OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid 1108)
root@gufboardll:~# ll /etc/ssh/*key*
-rw------- 1 root root 668 Sep 23 13:06 /etc/ssh/ssh_host_dsa_key
-rw-r--r-- 1 root root 607 Sep 23 13:06 /etc/ssh/ssh_host_dsa_key.
,
!
pub
-rw------- 1 root root 227 Sep 23 13:06 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r-- 1 root root 179 Sep 23 13:06 /etc/ssh/ssh_host_ecdsa_key.
,
!
pub
-rw------- 1 root root 411 Sep 23 13:06 /etc/ssh/
,
!
ssh_host_ed25519_key
-rw-r--r-- 1 root root 99 Sep 23 13:06 /etc/ssh/
,
!
ssh_host_ed25519_key.pub
-rw------- 1 root root 1675 Sep 23 13:06 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root 399 Sep 23 13:06 /etc/ssh/ssh_host_rsa_key.
,
!
pub
root@gufboardll:~#
For more information see the official OpenSSH documentation. The ssh keys can also be used as replacement
for the password authentication of the remote user. Please see the official documention for this feature.
SFTP only with restricted folder visibility Sometimes it is enough, when a remote user is able to download
log files or change config files in one specific folder. To reduce the security risk of a open remote service, it is
possible to restrict the ssh service access to the SFTP feature, locking the user into for example his home folder.
Folowing steps are needed for setup:
Create the user:
root@santaro:~# adduser service
Change the owner of his home directory to root (needed by sftp changeroot):
root@santaro:~# chown -R root:service /home/service
Edit the ssh config:
root@santaro:~# /etc/ssh/sshd_config
In the config file, change the sftp subsystem:
# override default of no subsystems
# Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
And append the following to the configuration:
Match User service
ChrootDirectory /home/service
ForceCommand internal-sftp
AllowTCPForwarding no
X11Forwarding no
Now it is possible to use for example filezilla to access the device with the new user and its password but the root
folder shown in filezilla is the home folder on the device.
Note: By default the user is also able to login using telnet or the serial console with access to the
complete root filesystem. If this is not desired, further configuration steps are needed.
4.1.4 Telnet service
The telnet service allows the user to log in on the target system.
17
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
Note: Due to the fact that telnet does not use encryption, it is recommended to deactivate this service
in final products in order to avoid security leaks. Disabling services is described in the chapter [
I
4.1
Services].
The telnet service has a startup link that points to the corresponding start script:
/etc/rc.d/S20telnet -> /etc/init.d/telnet
The startup script simply starts /usr/sbin/telnetd as a daemon. The usage of telnetd is shown by executing:
root@santaro:~# telnetd --help
BusyBox v1.22.1 (2015-09-17 20:08:55 CEST) multi-call binary.
Usage: telnetd [OPTIONS]
Following options are available and configured directly in the start script /etc/init.d/telnet:
Options:
-l LOGIN Exec LOGIN on connect
-f ISSUE_FILE Display ISSUE_FILE instead of /etc/issue
-K Close connection as soon as login exits
(normally wait until all programs close slave pty)
-p PORT Port to listen on
-b ADDR[:PORT] Address to bind to
-F Run in foreground
-i Inetd mode
-w SEC Inetd 'wait' mode, linger time SEC
-S Log to syslog (implied by -i or without -F and -w)
4.1.5 Module loading
The modules service is responsible for external module loading at system startup. It has a startup link that points
to the corresponding start script:
/etc/rcS.d/S05modutils.sh -> /etc/init.d/modutils.sh
The startup script simply looks which modules are listed in /etc/modules and loads them using /sbin/modprobe.
To ensure that the module loading works correctly, the module dependencies in /lib/modules/<kernel ver-
sion>/modules.dep have to be consistent.
4.1.6 Network initialization
The network initialization service is responsible for initializing all network interfaces at system startup. Garz &
Fricke systems use ifplugd to detect if an ethernet cable or an WLAN stick is plugged.
The network interfaces (including WLAN) are listed on the target system in the configuration file /etc/network/in-
terfaces. On conventional Linux systems, the user configures the network interfaces by hand using this file.
On Garz & Fricke systems, there is a service called sharedconf as described in [
I
4.1.8 Garz & Fricke shared
configuration] that generates this file automatically according to the settings in the global XML configuration.
If the user wants to change the network settings (including WLAN and its AP setup), it is recommended to use
the sconfig script as described in [
I
4.2.1 Garz & Fricke system configuration].
Note: Changes that are made to /etc/network/interfaces and /etc/wpa_supplicant.conf directly will
be overwritten by the sharedconf service on the next system startup and have no effect.
4.1.7 Watchdog
Generally a watchdog is a subsystem that monitors the system state in some way and executes a reset when a
malfunction is detected.
The watchdog service is built of a hardware watchdog device and a linux service.
18
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
The hardware watchdog device on SANTAROis capable to execute a hardware reset when not triggered in time.
The device node for the hardware watchdog is /dev/watchdog.
The watchdog service is able to monitor different system parameters, like the system load, and can take different
actions if any system parameter is out of a defined range. Those repair actions can be simple cleanup scripts or
the execution of a reboot or shutdown.
The service opens the hardware watchdog and triggers it regularly. When the service chrashes or the execution
of a repair script fails, the hardware watchdog isn’t triggered in time and a hardware reset will be executed.
The default state of the service is disabled.
The service can be started by executing:
root@santaro:~# /etc/init.d/watchdog.sh start
To start the service automatically on startup, create the startup links with:
root@santaro:~# update-rc.d watchdog.sh defaults
The watchdog service is configured using the configuration file /etc/watchdog.conf:
#ping = 172.31.14.1
#ping = 172.26.1.255
#interface = eth0
#file = /var/log/messages
#change = 1407
# Uncomment to enable test. Setting one of these values to '0' disables it.
# These values will hopefully never reboot your machine during normal use
# (if your machine is really hung, the loadavg will go much higher than 25)
#max-load-1 = 24
#max-load-5 = 18
#max-load-15 = 12
# Note that this is the number of pages!
# To get the real size, check how large the pagesize is on your machine.
#min-memory = 1
#repair-binary = /usr/sbin/repair
#repair-timeout =
#test-binary =
#test-timeout =
watchdog-device = /dev/watchdog
# Defaults compiled into the binary
#temperature-device =
#max-temperature = 120
# Defaults compiled into the binary
#admin = root
#interval = 1
#logtick = 1
#log-dir = /var/log/watchdog
# This greatly decreases the chance that watchdog won't be scheduled before
# your machine is really loaded
realtime = yes
priority = 1
# Check if rsyslogd is still running by enabling the following line
#pidfile = /var/run/rsyslogd.pid
19
GUF-Yocto-jethro-9.0-r7707-0
i.MX6
User Manual
4.1.8 Garz & Fricke shared configuration
The sharedconf service reads shared configuration settings from the XML configuration and configures the
Linux system accordingly. This includes network (as described in [
I
4.1.6 Network initialization]) and touch
configuration.
The sharedconf service has a startup link that points to the corresponding start script:
/etc/rcS.d/S24sharedconf -> /etc/init.d/sharedconf
4.1.9 Autocopy
This service is executed after the OS has booted and when a storage medium has been inserted. It is triggered
together with the the Autostart service (see chapter [
I
4.1.10 Autostart]) via UDEV. Autocopy always runs
before Autostart.
The Autocopy service provides a comfortable installation and/or update functionality as well as copy mechanism
for specific files that are not included in the OS (e.g. for runtime libraries).
Subfolders and files within a folder named autocopy on a USB stick, SD card or in the NAND flash will be copied
to the root of the device resp. its equivalent targets. Non-existing folders will be created automatically.
The autocopy mechanism includes the following components:
/etc/udev/rules.d/automount.rules: UDEV rule that triggers the mount.sh script
when a storage media is plugged/unplugged
/etc/udev/scripts/mount.sh: Script that implements the autocopy and automount
functionality.
Example: The user has created and application myapp that should be installed to /usr/bin/myapp on the target
and a library mylib.so used by this application that should be installed to /usr/lib/mylib.so. The layout of the
storage medium is shown in figure [
I
Figure 4.1.9].
Figure 3: Layout of the storage medium after preperation with the custom files
After the target device is up and the storage media is plugged, the following message on the target’s console is
shown:
mount.sh/automount Auto-mount of [/media/sda1] successful
mount.sh/automount Found an autocopy folder. Copying files...done
[
I
Figure 4] illustrates what happens in background. The files are properly transferred to the target.
20
This manual suits for next models
5
Table of contents
Other GARZ&FRICKE Desktop manuals
