In this chapter, common configuration and maintenance tasks are described.
Initial Device Configuration
Starting from the Dunfell release of Linux Yocto, SECO Northern Europe devices no longer support a dynamic change of device configuration (e.g. display or touch settings) via xml file with the xconfig script. Initial device configurations need to be made before OS installation and will be attached permanently to that installation. Further changes down the line require a new installation of the OS.
This has the benefit of a simplified device boot, as well as an accelerated boot speed. While later configuration changes might be more complicated, with the nature of embedded systems, changes are not very common and an improved boot process would be better for the system overall.
The process of booting into the Flash-N-Go System is described in the chapter [Deploying the Linux system to the target]. Within Flash-N-Go System, the xconfig script can be called to modify the device configuration.
More detail about Flash-N-Go infrastructure can be found here.
SECO Northern Europe system configuration
As with xconfig, sconfig also no longer support dynamic changes of configuration in the target OS. A new OS installation is required for the new setting to take effect.
Some parts of the system configuration are stored in an xml file stored on one of the boot partitions of the eMMC. This information is shared between the backup OS Flash-N-Go System and the main OS, but also persistent between normal OS installations.
The shared information is stored in an xml file called config.xml, found in /etc/shared. For this purpose, there is a link to the script at /usr/sbin/sconfig which can be called without the absolute path:
root@santaro:~# sconfig dhcp true ip 192.168.1.1 mask 255.255.255.0 gateway 192.168.1.100 mac 0x00:0x07:0x8E:0x35:0xA4:0x8A name GFMM03515530 serial 03515530
Call without parameter to show the list of current configurations on the system. Call with -h to show additional help.
If the script is called with a setting as parameter, the setting is read from the XML configuration and displayed on the console.
root@santaro:~# sconfig gateway 192.168.1.1
If additionally a value is appended, this value is updated to the according setting in the XML configuration.
root@santaro:~# sconfig gateway 192.168.1.10 root@santaro:~# sconfig gateway 192.168.1.10
The ’name’ set with sconfig is also used as hostname for the device. It defaults to GFMM<serial number>.
Network configuration
The Network Manager service is responsible for initializing all network interfaces at system startup and when an ethernet cable or a WLAN stick is plugged in.
The Network Manager stores its config files in the /etc/NetworkManager directory. Normally there is no need to change those files directly as there are some tools available to configure the network.
More information about Network Manager can be found here.
WLAN
While SANTOKA has a built-in WLAN module, all other SECO Northern Europe products support WLAN using WLAN USB dongles. A list of supported devices can be found in the BSP release notes. WLAN can be used as client or provide an own network as Access Point.
Network management is done through nmcli, which is a command-line client for the Network Manager and reporting network status. A detail explanation of nmcli usage can be found here and here.
Configure as WLAN client
Configure as WLAN Access Point
It is possible to configure the device to act as WLAN Access Point though this feature is not supported by all WLAN modules and WLAN drivers.
Compliance to Regulatory Domain
The WLAN modules perform wireless communication that is subject to different local regulations, depending on where the module is used. For example, in the USA the FCC does not allow communication to be performed on channels 12, 13, and 14, whereas in Japan communication is allowed on all channels 1 to 14.
CRDA Regulatory Domain Setting
Most of our systems allow the configuration of the regulatory domain via the standard CRDA support of the Linux kernel.
These settings use a general strategy of regdomain compliance:
The system uses a default "world" regdomain.
The wifi adapter can define its own regdomain. (E.g., the PCEAN2i Module is configured to US.)
A user can set a regdomain.
In any case only the common subset of the three possible settings is enabled, so the permissions can usually
only shrink to be more compliant.
The world regdomain is a bit special. It receives configurations on channels that are not allowed everywhere in the world, which are enabled only if a router announces its network on such a channel.
Run an application at startup
The init system changed from System V to systemd. This means that all scripts in /etc/init.d are gone and replaced by systemd units. systemd uses so-called unit-files to configure services to start and stop. The tool systemctl is the main userspace tool to control these if needed.
Web Browser
We provide the qt-kiosk-browser in the default image. It is intended to be used for HTML-based applications starting automatically during system boot, which won’t display the regular browser GUI, i.e. URL-bar, navigation buttons, etc.
The tool is based on the QtWebEngine which uses the same backend as chromium.
Check the official documentation of qt-kiosk-browser for further reference.
Features:
The provided browser is a reduced single-page or ’kiosk’ mode browser. All pages are opened in Fullscreen mode and there are no UI elements available, neither navigation bar, context menu or status bar.
Closing these views is due to the web page’s implementation, as well as implementing forward- and backward functionality if needed.
Downloads and pdf views are currently not supported.
There is an onscreen keyboard available, that comes up when a text input is selected.
Configuration
The qt-kiosk-browser loads the qt-kiosk-browser git page by default. Customer can change the default URL by configuring the required URL in the qt-kiosk-browser by entering the following commands (replace <Your URL> with required URL):
Run the application at startup
The Yocto OS images provided by Seco starts a Qt-based demo application automatically after system boot. To enable Auto Start of the qt-kiosk-browser instead, execute the following commands on the console of the device.
By default a demo will be launched at startup:
To disable the demo from startup
systemctl disable guf-show-demo
Create the service file for qt-kiosk-browser and add code in the file
cat > /lib/systemd/system/qt-kiosk-browser.service [Unit] Description=qt-kiosk-browser After=weston@root.service Requires=weston@root.service Conflicts=getty@tty1.service [Service] Type=simple Environment=XDG_RUNTIME_DIR=/var/run/user/0 Environment=QT_QPA_FONTDIR=/usr/share/fonts/truetype Environment=QT_QPA_PLATFORM=wayland ExecStart=qt-kiosk-browser /etc/qt-kiosk-browser.conf --no-sandbox TimeoutSec=60 Restart=on-failure StandardOutput=syslog StandardError=syslog SyslogIdentifier=qt-kiosk-browser [Install] WantedBy=multi-user.target
Enable the qt-kiosk-browser service and reboot the device
systemctl enable qt-kiosk-browser reboot
The browser will load automatically after reboot.
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.
The hardware watchdog device on SECO Northern Europe devices is 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 crashes 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.
Further documentation and additional configuration can be found here and here.
Power down mode
The system can enter a power down mode to reduce power consumption when the system is not in use. In this mode all PLLs are disabled, CPU voltages are lowered and several hardware components are powered down. The overall power consumption should be less than 500 mW in this mode but actually depends on the device and its hardware assembly option.
The average time it takes to enter power down mode has been measured at 364+-5ms (last byte on UART RX until voltage drop on VDDSOC).
There are different possibilities to make the system wake up from the power down mode. Wakeup sources have to be configured before entering power down mode, otherwise the system cannot be woken up.
Reboot, Halt and Poweroff
As you probably have noticed already, none of our SECO Northern Europe devices are equipped with any kind of power button. This means, they will start booting and running an OS as soon as an external power-supply is connected and turned-on and the only way to turn the device off is to disconnect the external power-supply.
The devices are not designed to be turned-off under software-control.
The common Unix/Linux utilities to shutdown the system behave accordingly:
reboot: will stop all login-services, stop all running applications, flush all caches, unmount all filesystems and safely reboot the system.
halt: will stop all login-services, stop all running applications, flush all caches, unmount all filesystems and just "halt" the system, so that a user may safely disconnect the power-supply without risking any data-loss.
poweroff: according to Unix/Linux conventions for systems that cannot turn-off themselves, will do just the same as halt.
This means, as per Linux/Unix convention for systems that can’t turn-off themselves, none of these commands will turn-off device power; not even the display power. The halt and poweroff commands will only ensure that the system is put in a state, where no user-processes are running anymore and all data has been written back to storage media.
Kernel command line
The kernel command line can be used to change some kernel features.
Be careful changing the command line, as it can easily break the booting process of your device. If booting fails after those changes, you will need to boot into Flash-N-Go System and correct the settings. In this case, please refer to the Flash-N-Go infrastructure manual.
Disabling boot logo
By default SECO Northern Europe devices come with the SECO logo as the boot logo at startup. If this is not desired by the customer, the logo can be disabled by adding the parameter “logo.nologo” to the Kernel command line as described above.
Changing time and date
By default the system time is automatically synced from an NTP Server and user should not need to do any change. However, it is possible to set a custom time for the system using the command timedatectl.
Integrating customized driver (module loading)
SECO Northern Europe devices can automatically load customized drivers (module) on boot with the help of systemd. The systemd-modules-load.service is responsible for external module loading on system startup. Users can customize this service to integrate their own driver to the system.