| Table of Contents | ||||
|---|---|---|---|---|
|
...
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.
...
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.
| Expand | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Calling xconfig to show available option:
List the installed configuration of the device:
Delete the existing display config:
Import an xml configuration file, in this example a display config located in /mnt/mstick1/:
|
...
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:
...
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.
...
| Code Block |
|---|
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.
...
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
Scan for nearby networks:
Note the name of networks listed under the column SSID, to connect a desired network:
Once successfully connected, test the connection with ping:
Network Manager will save the connection and auto-connect on reboot, so you don't have to worry about issuing the command every time the device is booted. |
...
| Expand | ||||
|---|---|---|---|---|
| ||||
To setup a WLAN Access point with own sub network including a DHCP service using the Network Manager use following commands:
This creates a “test” network with the password “secret_passphrase”. The connection to identify this setup in the Network Manager is called Hotspot. This kind of WLAN access point assigns each client an own IP Address in its own sub net, starting with 10.42.0.1 by default. Accesses to the internet over an ethernet connection are using NAT (network address translation). This way the clients are not visible from the ethernet. To remove this connection use:
|
...
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.
| Expand | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
View list of installed services
Disable/enable a service from automatic startup
Check the status of a service
Example: disable the demo from startup
|
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.
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.
Links that are supposed to open tabs, like ’Link’, either in foreground or background, are creating a new Fullscreen view, hiding the root page. Not that this should not be used too extensive, due to the additional demand on system memory. 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. This is intended for first demonstration purposes only, of course, and may be changed to a different URL of your choice with the following command (replace <Your URL> with required URL):
| Code Block |
|---|
sed -i 's,http://github.com/OSSystems/qt-kiosk-browser,<Your URL>,g' /etc/qt-kiosk-browser.conf |
Start the qt-kiosk-browser by entering the following command
| Code Block |
|---|
qt-kiosk-browser /etc/qt-kiosk-browser.conf --no-sandbox |
Automatic start on system boot
The prebuilt Dunfell OS images provided by Garz & Fricke usually starts a small 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.
Disable demo from startup
| Code Block |
|---|
systemctl disable guf-show-demo |
Create the service file for qt-kiosk-browser and add code in the file
| Code Block |
|---|
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
| Code Block |
|---|
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.
...
| Expand | ||||
|---|---|---|---|---|
| ||||
The file /etc/systemd/system.conf contains option to configure the watchdog logic.
Default value of 0 means watchdog is disabled, set to a value (e.g. 20s) to reboot the system after there is no keep-alive ping during the given interval.
Further configuration to watchdog timing at reboot, shutdown, and by kexec, respectively. |
...
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.
...
| Note |
|---|
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. |
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
To change the kernel command line, the boot partition needs to be mounted:
Open the boot configurator file to edit:
The boot configuration normally looks similar to this:
The last line is the kernel command line. Options can be added to the end. |
...
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.
| Expand | ||
|---|---|---|
| ||
Edit the boot.cfg file as shown (adding logo.nologo to the last line):
|
...
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.
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
First check if systemd-modules-load.service is activated:
Create the config file in /etc/modules-load.d/:
Edit the file to only contain the module name:
Next time the system reboots, the module will be automatically loaded. |