Hints
This document contains a collection of (maybe) useful hints and commands for developers to do various task inside the installed SECO North Yocto.
This is a growing document and not ment to reach any state of completeness like a manual, or similar.
-
Hints
- Audio
- Bluetooth
- CAN
- Device boot time test
- Display
- EEPROM
- Ethernet
- Firewall
- GPU
- HDMI
- Light sensor (SantVend)
- MDB (SantVend)
- Modem
- NFS
- Power management
- Power management: poweroff (SantVend)
- Python3
- Qt5
- RAM
- RS232
- RS485
- RTC
- sconfig
- SD-Card
- SFTP
- SSH
- Temperature Sensors
- Touch
- USB
- Video playback
- Watchdog
- WiFi
Audio
Play sound
aplay /usr/share/sounds/alsa/*
Play click sequence
wget -P /tmp/ http://support.garz-fricke.com/projects/TestFiles/Audio/short_click_4_times.wav
aplay /tmp/short_click_4_times.wav
Qt QML audio playback
#Preparation
systemctl stop seco-show-demo
cat > /tmp/audio-playback.qml << 'EOF'
import QtMultimedia 5.15
import QtQuick 2.15
Text {
text: "Click Me!";
font.pointSize: 24;
width: 150; height: 50;
Audio {
id: playMusic
source: "/usr/share/sounds/alsa/Front_Center.wav"
}
MouseArea {
id: playArea
anchors.fill: parent
onPressed: { playMusic.play() }
}
}
EOF
qmlscene /tmp/audio-playback.qml
HDMI sound playback test
Test
Start speaker-test for HDMI card.
speaker-test -c 2 -t wav -D sysdefault:CARD=DWHDMI
Gstreamer sound playback test
Test
Play test audio source with gst-launch for a few seconds for both sound devices.
gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink device=hw:0,0
gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink device=hw:1,0
Expected results
Sound is played through the HDMI display if device=hw:0,0 is used. Sound is played through the speaker if device=hw:1,0 is used.
Bluetooth
Bluetooth is currently only basically supported. Commands used for a basic hardware test:
Tanaro V1.1
Note: There are devices which do not have R11 populated on the BT Uart's CTS line. These do not support bluetooth.
# Connect the BT-Chip
rtk_hciattach ttymxc3 rtk_h5
hciconfig hci0 up
# Scan for other BT-devices
hcitool scan
Bluetooth audio example
BT was tested on Tanaro via Audio profile according to the following methodology:
- Add "bluealsa" package to the image.
- Bring up a BT controller:
# rtk_hciattach ttymxc3 rtk_h5
# hciconfig hci0 up
- Connect to another BT device which is capable of playing audio via BT (Tanaro is used to generate audio and ordinary Linux PC to play it).
- Execute on Tanaro:
# bluetoothctl
Agent registered
[CHG] Controller 44:01:BB:E0:80:C1 Pairable: yes
[bluetooth]# scan on
Discovery started
[CHG] Controller 44:01:BB:E0:80:C1 Discovering: yes
[NEW] Device C4:23:60:A1:23:8F fedora
[bluetooth]# pair C4:23:60:A1:23:8F
Attempting to pair with C4:23:60:A1:23:8F
[CHG] Device C4:23:60:A1:23:8F Connected: yes
Request confirmation
[agent] Confirm passkey 756821 (yes/no): yes
[CHG] Device C4:23:60:A1:23:8F UUIDs: 00001104-0000-1000-8000-00805f9b34fb
...
[CHG] Device C4:23:60:A1:23:8F ServicesResolved: yes
[CHG] Device C4:23:60:A1:23:8F Paired: yes
Pairing successful
[CHG] Device C4:23:60:A1:23:8F ServicesResolved: no
[CHG] Device C4:23:60:A1:23:8F Connected: no
[bluetooth]# trust C4:23:60:A1:23:8F
[CHG] Device C4:23:60:A1:23:8F Trusted: yes
Changing C4:23:60:A1:23:8F trust succeeded
[bluetooth]# connect C4:23:60:A1:23:8F
Attempting to connect to C4:23:60:A1:23:8F
[CHG] Device C4:23:60:A1:23:8F Connected: yes
Connection successful
[CHG] Device C4:23:60:A1:23:8F ServicesResolved: yes
- On a second terminal on Tanaro, check that there a new bluetooth audio device has appeared:
# bluealsa-aplay -L
bluealsa:SRV=org.bluealsa,DEV=C4:23:60:A1:23:8F,PROFILE=sco
fedora, trusted computer, playback
SCO (CVSD): S16_LE 1 channel 8000 Hz
bluealsa:SRV=org.bluealsa,DEV=C4:23:60:A1:23:8F,PROFILE=sco
fedora, trusted computer, capture
SCO (CVSD): S16_LE 1 channel 8000 Hz
bluealsa:SRV=org.bluealsa,DEV=C4:23:60:A1:23:8F,PROFILE=a2dp
fedora, trusted computer, playback
A2DP (SBC): S16_LE 2 channels 48000 Hz
- Play audio on Tanaro using a corresponding audio device:
# aplay -D bluealsa:SRV=org.bluealsa,DEV=C4:23:60:A1:23:8F,PROFILE=a2dp /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Bluetooth serial port example
- Bring up a BT controller on Tanaro:
# rtk_hciattach ttymxc3 rtk_h5
# hciconfig hci0 up
- Connect to another PC/board with BT device and which is capable of using rfcomm.
- Execute on Tanaro:
# bluetoothctl
Agent registered
[CHG] Controller 44:01:BB:E0:80:C1 Pairable: yes
[bluetooth]# scan on
Discovery started
[CHG] Controller 44:01:BB:E0:80:C1 Discovering: yes
[NEW] Device C4:23:60:A1:23:8F fedora
[bluetooth]# pair C4:23:60:A1:23:8F
Attempting to pair with C4:23:60:A1:23:8F
[CHG] Device C4:23:60:A1:23:8F Connected: yes
Request confirmation
[agent] Confirm passkey 756821 (yes/no): yes
[CHG] Device C4:23:60:A1:23:8F UUIDs: 00001104-0000-1000-8000-00805f9b34fb
...
[CHG] Device C4:23:60:A1:23:8F ServicesResolved: yes
[CHG] Device C4:23:60:A1:23:8F Paired: yes
Pairing successful
[CHG] Device C4:23:60:A1:23:8F ServicesResolved: no
[CHG] Device C4:23:60:A1:23:8F Connected: no
[bluetooth]# trust C4:23:60:A1:23:8F
[CHG] Device C4:23:60:A1:23:8F Trusted: yes
Changing C4:23:60:A1:23:8F trust succeeded
[bluetooth]# connect C4:23:60:A1:23:8F
Attempting to connect to C4:23:60:A1:23:8F
[CHG] Device C4:23:60:A1:23:8F Connected: yes
Connection successful
[CHG] Device C4:23:60:A1:23:8F ServicesResolved: yes
- On Tanaro, start listening on /dev/rfcomm0 port via rfcomm tool:
# rfcomm --raw listen /dev/rfcomm0 0
Waiting for connection on channel 0
- On second PC/board, connect to Tanaro via rfcomm:
$ sudo rfcomm --raw connect 0 44:01:BB:E0:80:C1
Connected /dev/rfcomm0 to 44:01:BB:E0:80:C1 on channel 1
Press CTRL-C for hangup
, where "44:01:BB:E0:80:C1" is an address of BT controller on Tanaro.
- Check on Tanaro that the second PC/board has been connected:
# rfcomm --raw listen /dev/rfcomm0 0
Waiting for connection on channel 0
Connection from C4:23:60:A1:23:8F to /dev/rfcomm0
Press CTRL-C for hangup
- Transfer some data via /dev/rtcomm0 between Tanaro and the second PC/board:
-
Transfer data from Tanaro to the PC/board:
-
Run on this PC/board:
$ cat /dev/rfcomm0
-
Run on another terminal of Tanaro:
# echo "Test from Tanaro" > /dev/rfcomm0
-
Check on the second PC/board that the message has been received:
$ cat /dev/rfcomm0 Test from Tanaro
-
-
Transfer data from the PC/board to Tanaro:
-
Run on free terminal of Tanaro:
# cat /dev/rfcomm0
-
Run on host:
$ echo "Test from host." > /dev/rfcomm0
-
Check on Tanaro that the message has been received:
# cat /dev/rfcomm0 Test from host.
-
BLE (SantVend v1.2)
Test
Read device version
/opt/ltp/testcases/bin/spi -m 0x1,0x09 -r 9 /dev/spidev2.0
/opt/ltp/testcases/bin/spi -m 0x1,0x09 -r 9 /dev/spidev2.0
Expected results
Second command return response (9 bytes): 84 09 00 41 00 02 00 ff ff
BLE (SantVend v1.3)
Test
Read the chip type and OS version
/opt/ltp/testcases/bin/spi -m 0x02,0x10,0x01,0x00,0x0F,0x01C -r 12 /dev/spidev2.0
/opt/ltp/testcases/bin/spi -m 0x02,0x10,0x01,0x00,0x0F,0x01C -r 12 /dev/spidev2.0
Expected results
Second command return response (12 bytes): 00 30 44 41 41 05 20 40 28 05 00 a9
CAN
CAN test
Test Setup
- Device connected to a SECO counter part device or a linux PC with PCan USB-Can adapter.
- Cable for Device to device connection:
- Device 1 CAN1_H to Device 1 CAN1_TERM
- Device 1 CAN1_H to Device 2 CAN1_H
- Device 2 CAN1_H to Device 2 CAN1_TERM
- Device 1 CAN1_L to Device 1 CAN1_TERM
- Device 1 CAN1_L to Device 2 CAN1_L
- Device 2 CAN1_L to Device 2 CAN1_TERM
Test
- Setup can interfaces on both boards and check interface statistics.
ifconfig can0 down
ip link set can0 up type can bitrate 1000000
ifconfig can0 up
ifconfig can0
- On the device under test start candump.
candump can0
- On the reciver device run cangen and cansend.
cangen can0 -n 10 -v
cansend can0 '5A1#11.22.33.44.55.66.77.88'
- On the device under test stop stop candump. On both boards check interface statistics.
ifconfig can0
- Repeat steps 2,3 and 4 in other direction (candump on the second board and cangen with cansend on the first board).
Expected results
Interface was successfully setup on both devices. Information received by candump on one board corresponds to the information sent by the other. TX and RX counters were increased by the amount of sent and received packets. Counters for errors, dropped, overruns, frame, carrier and collisions did not increase.
Old test commands
Requires a windows PC with the testtool and a PCAN Adapter.
# Counter part is running TestCAN_W32_2.0.2.0.exe -s -v1 -x4
/opt/ltp/testcases/bin/can
Device boot time test
Test
Shutdown device and disconnect the power supply unit.
Start grabserial
tool on host PC:
grabserial --verbose --device="/dev/ttyUSB0" --baud=115200 --time --match="Configuring DDR3 pads.*"
Power up the board.
Display
Test Setup
- A HDMI display connected to the board.
- A LVDS display connected to the board.
- Prepare script for backlight test:
cat > /tmp/backlight-test.sh << 'EOF'
#!/bin/sh
BL_PATH=/sys/class/backlight/backlight/
MAX_BRIGHTNESS=$(cat $BL_PATH/max_brightness)
ACTUAL_BRIGHTNESS=$(cat $BL_PATH/actual_brightness)
echo "max brightness value: $MAX_BRIGHTNESS"
echo "actual brightness value: $ACTUAL_BRIGHTNESS"
echo 0 > $BL_PATH/brightness
sleep 2
echo $(($MAX_BRIGHTNESS/2)) > $BL_PATH/brightness
sleep 2
echo $MAX_BRIGHTNESS > $BL_PATH/brightness
sleep 2
echo $ACTUAL_BRIGHTNESS > $BL_PATH/brightness
echo "done"
EOF
- Set output sections in /etc/xdg/weston/weston.ini as following.
[output]
name=LVDS-1
transform=normal
mode=preferred
[output]
name=HDMI-A-1
transform=normal
mode=preferred
Backlight test
Test
Run prepared backlight-test.sh.
sh /tmp/backlight-test.sh
Expected results
During the test:
- at first, LVDS display backlight will turn off;
- after 2 seconds, it will turn on with half of maximum brightness level;
- after 2 more seconds, brightness will be set to max brightness;
- after 2 more seconds, brightness level will be set to pre-test value.
FB blank
Test
Stop weston.
systemctl stop weston.socket
Check if FB blanking works.
echo 4 > /sys/class/graphics/fb0/blank
sleep 2
echo 0 > /sys/class/graphics/fb0/blank
Start weston again.
systemctl start weston
Expected results
On "echo 4" command, both displays stop showing any image (e.g. there is no signal for HDMI). On "echo 0" command, both displays turn on.
Single display LVDS test
Test
Set mode=off in /etc/xdg/weston/weston.ini for HDMI display. Set mode=preferred in /etc/xdg/weston/weston.ini for LVDS display. Restart weston and check weston-info.
systemctl restart weston
weston-info
Expected results
Image is shown only on LVDS display. Weston-info shows only one working display - LVDS.
Single display HDMI test
Test
Set mode=preferred in /etc/xdg/weston/weston.ini for HDMI display. Set mode=off in /etc/xdg/weston/weston.ini for LVDS display. Restart weston and check weston-info.
systemctl restart weston
weston-info
Expected results
Image is shown only on HDMI display. Weston-info shows only one working display - HDMI.
Dual display test
Test
Set mode=preferred in /etc/xdg/weston/weston.ini for HDMI display. Set mode=preferred in /etc/xdg/weston/weston.ini for LVDS display. Restart weston and check weston-info.
systemctl restart weston
weston-info
Expected results
Image is shown on both displays. Weston-info shows that both display are enabled.
Weston rotation
Set different output rotation values. It is assumed that only one output is present in weston.ini.
# Preperation
systemctl stop seco-show-demo
# 90 deg
sed -i 's/transform=.*$/transform=rotate-90/g' /etc/xdg/weston/weston.ini
systemctl restart weston
weston-image /usr/share/seco-show-demo/images/icon-hw-info.png
# 270 deg
sed -i 's/transform=.*$/transform=rotate-270/g' /etc/xdg/weston/weston.ini
systemctl restart weston
weston-image /usr/share/seco-show-demo/images/icon-hw-info.png
# 180 deg
sed -i 's/transform=.*$/transform=rotate-180/g' /etc/xdg/weston/weston.ini
systemctl restart weston
weston-image /usr/share/seco-show-demo/images/icon-hw-info.png
# 0 degree
sed -i 's/transform=.*$/transform=normal/g' /etc/xdg/weston/weston.ini
systemctl restart weston
weston-image /usr/share/seco-show-demo/images/icon-hw-info.png
EEPROM
EEPROM read
gfeeprom --show
EEPROM write
Before you run the write command verify the content of eeprom-orig.txt
.
# Perperation
output=$(gfeeprom --show | grep "0-0050/eeprom ->")
eval e=($(echo $output | sed -e 's/[>|()]//g' ))
echo "[BEGIN]
Controller Index = 1
Device = ${e[1]}
EEPROM Address = 0x${e[1]##*eeprom}
Major Version = ${e[12]}
Minor Version = ${e[14]}
Article Number = ${e[7]}
Serial Number = ${e[10]}
Component = ${e[4]}
Comment = ${e[16]}
Verify = 0x1
Force write = 0x1
[END]" > /tmp/eeprom-orig.txt
comment="Write test $(date)"
sed "s/Comment =.*/Comment = ${comment}/" /tmp/eeprom-orig.txt > /tmp/eeprom-test.txt
cat /tmp/eeprom-orig.txt
# Write to eeprom and read back
gfeeprom --program -sf /tmp/eeprom-test.txt
gfeeprom --show
# Restore original values
gfeeprom --program -sf /tmp/eeprom-orig.txt
Ethernet
Test Setup
- Access to the test device console/shell.
- The board connected to test network via Ethernet cable.
- A DHCP server is configured in test network.
- Run iperf3 server on auxilary host in test network.
iperf3 -s -p 5201
DNS lookup test
nslookup north.seco.com
Performance test
Connect only the interface that is to be tested to the network. Run iperf client on the board to check upload speed:
iperf3 -c <server_ip> -P4
Run iperf client on the board to check download speed:
iperf3 -c <server_ip> -P4 -R
iperf3 -c <hostname/ip of echo server machine> -p 5201
Expected results
Upload/download speed is greater that 90 Mbit/sec.
Firewall
Basic test of the iptables
functionality.
Ping and port scan
On the target, block all traffic:
iptables -A INPUT -j DROP
On the remote device:
export DEVICE=_{Test device IP address}_
ping $DEVICE -c3 -W1
for i in {1..255};
do ( (
nc -w 1 -n $DEVICE $i < /dev/null > /dev/null &&
echo -en "\r" && echo -n "Port $i: " &&
nc -v $DEVICE $i < /dev/null; echo -en "\r") & );
done
Ping should fail and no open port should be reported.
Validate http access
On the target, block all traffic but open port 80 and 53 (for dns)
iptables -F
iptables -A INPUT -j DROP
iptables -I INPUT 1 -p udp --source-port 53 -j ACCEPT
iptables -I OUTPUT 1 -o eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -I INPUT 1 -i eth0 -p tcp -m state --state ESTABLISHED -j ACCEPT
Try to download a webside from the internet:
wget www.google.de
Simple systemd service to configure iptables on startup
Write the current setup from the previous test to the config file:
iptables-save > /etc/iptables/iptables.rules
Verify the rules are applied after reboot.
GPU
GPU 3D Acceleration
Stop demo and run benchmark
systemctl stop seco-show-demo
glmark2-es2-wayland
All benchmark scenes should run smoothly.
HDMI
HDMI DRM device
Check if a HDMI DRM device was created.
ls /sys/class/drm/ | grep HDMI
HDMI modetest
Use modetest -c
and modetest -p
to find out which connector and crtc values (<connector>@<crtc>) are appropriate for your system.
systemctl stop weston
modetest -M imx-drm -s 66@47:1280x800
Weston on HDMI
Get connector name for HDMI:
root@localhost:~# ls /sys/class/drm/ | grep HDMI
card1-HDMI-A-1
Change weston.ini accordingly:
[output]
name=HDMI-A-1
...
Reboot the device.
Light sensor (SantVend)
Test Setup
- A light sensor is connected to the board.
Light sensor test
Test
Check light sensor reading with different illumination levels.
cat /sys/bus/iio/devices/iio\:device0/in_illuminance_input
Expected results
The dimmer the illumination, the lower the light sensors reading will be.
MDB (SantVend)
Test Setup
- Two SantVend boards connected via a MDB master-slave cable.
MDB test
Test
- Start slave test on SantVend board with slave part of the MDB cable:
mdbtest_slave ttymxc3
- Start master test on SantVend board with master part of the MDB cable:
mdbtest_master ttymxc2
Expected results
Communication between test application is established. There are no errors during transfer. Reply messages from slave are seen on master. Slave reported "POLL count: 1" at the end.
Modem
Test Setup
- Access to the test device console/shell.
- Li-Ion accumulator is connected to the board.
Start Quectel EC21 LTE modem
Test
Clean dmesg buffer and reset modem:
dmesg -C
MODEM_RESET=$(gpiofind modem_reset)
gpioset $MODEM_RESET=1; sleep 1; gpioset $MODEM_RESET=0
MODEM_IGN=$(gpiofind modem_ignition)
gpioset $MODEM_IGN=0; sleep 0.5; gpioset $MODEM_IGN=1; sleep 1; gpioset $MODEM_IGN=0
Check kernel messages.
dmesg
Check loaded modules.
lsmod
Expected results
USB/Network drivers successfully loaded after modem reset/ignition. There are no errors in dmesg. The following drivers are loaded as modules: "qcserial", "qmi_wwan", "cdc_wdm", "option", "usb_wwan", "usbserial".
AT commands test
Test
Run AT command to query vendor name.
echo -ne "AT+CGMI\r\n" | microcom -t 100 -s 115200 /dev/ttymxc4 | sed -n "2p"
Run AT command to query model number.
echo -ne "AT+CGMM\r\n" | microcom -t 100 -s 115200 /dev/ttymxc4 | sed -n "2p"
Retrieve info from SIM card:
echo -ne "AT+CFUN=1\r\n" | microcom -t 100 -s 115200 /dev/ttymxc4 | sed -n "2p"
echo -ne "AT+CPIN?\r\n" | microcom -t 100 -s 115200 /dev/ttymxc4 | sed -n "2p"
echo -ne "AT+CSQ\\r\n" | microcom -t 100 -s 115200 /dev/ttymxc4 | sed -n "2p"
echo -ne "AT+COPS?\r\n" | microcom -t 100 -s 115200 /dev/ttymxc4 | sed -n "2p"
echo -ne "AT+CNUM\r\n" | microcom -t 100 -s 115200 /dev/ttymxc4 | sed -n "2p"
echo -ne "AT+QECCNUM=0,1\r\n" | microcom -t 100 -s 115200 /dev/ttymxc4
Expected results
AT commands shows:
- CGMI - Quectel
- CGMM - EC21
- CFUN - OK
- CPIN - READY
- CCSQ - signal quality
- COPS - operator name
- QECCNUM - emergency numbers
NFS
NFS client
Change the variables NFSSERVER
and SERVERDIR
to match your configuration.
NFSSERVER=<hostname>
SERVERDIR=/home/
mkdir -p /tmp/mnt/nfs
mount -t nfs $NFSSERVER:$SERVERDIR /tmp/mnt/nfs
ls /tmp/mnt/nfs
umount /tmp/mnt/nfs
Power management
Test Setup
- Access to the test device console/shell.
- Plug the SD card into the SD card socket of the test device.
- Plug the USB memory stick into the USB host jack.
- Configure kernel to print all messages to console
echo 8 > /proc/sys/kernel/printk
.
Standby mode wakeup from CPU internal RTC
echo +5 > /sys/class/rtc/rtc1/wakealarm && echo standby > /sys/power/state
# The device should wake up after 5 seconds
Standby mode wakeup from from serial interface
echo enabled > /sys/class/tty/ttymxc0/power/wakeup && echo standby > /sys/power/state
# Device has to wake up after keypress on the serial console
Deep sleep mode wakeup from CPU internal RTC
echo +5 > /sys/class/rtc/rtc1/wakealarm && echo mem > /sys/power/state
# The device should wake up after 5 seconds
Deep sleep mode wakeup from from serial interface
echo enabled > /sys/class/tty/ttymxc0/power/wakeup && echo mem > /sys/power/state
# Device has to wake up after keypress on the serial console
Power management: poweroff (SantVend)
Test Setup
- Access to the test device console/shell.
- Power supply connected to the board
- Li-Ion accumulator is connected to the board.
Reset on short powerfail test (SantVend)
Test
Power up the device. Execute:
shutdown -hP 0
Disable the power supply for only ~1 second. The device will be powered by the battery for the short power-outage. Wait for the reset and the system reboot.
Expected results
The system should execute as reboot and be back online after < 1min.
PMIC Off-Mode test (SantVend)
Test
Power up the device. Disable the power supply. The device will then be powered by the battery. Execute:
shutdown -hP 0
Wait for device power-down (will be shown on the debug-console). Wait 10 seconds and re-power the power supply. Wait for power-up Execute:
reboot
Expected results
After the shutdown command the console should show:
[ xx.xxxxxx] reboot: Power down
The device should power up normally.
The reboot should work as expected.
Python3
Python3 web certificates
This test ensures that certificates are installed on the system and openssl and python have access them.
echo -e "import urllib.request\nprint(urllib.request.urlopen('https://www.google.com'))\n" | python3
# Expectet output something like <http.client.HTTPResponse object at 0xb6095e38>
pip3 functionality
This test ensures that python 2 and python 3 on the system are complete enough to allow installation of additional packages via pip.
pip3 install virtualenv
# Expected output something like: Successfully installed distlib-0.3.6 filelock-3.8.0 platformdirs-2.5.4 virtualenv-20.17.0
Qt5
OpenGl ES
# Preperation
systemctl stop seco-show-demo
qt5-opengles2-test
# When you touch the display, a rectancle should show up under the finger
Qt Kiosk Browser & Qt Virtual Keyboard
# Preperation
systemctl stop seco-show-demo
# Set a proper URL in /etc/qt-kiosk-browser.conf.
For example by manually setting a following in a file via text editor:
"URL": "https://edge.seco.com/de/"
Or by running a following command from Linux command line:
sed -i 's/"URL":.*$/"URL": "https:\/\/edge.seco.com\/de\/",/' /etc/qt-kiosk-browser.conf
# Start browser from console:
qt-kiosk-browser /etc/qt-kiosk-browser.conf --no-sandbox
# Start browser using provided service:
systemctl start qt-kiosk-browser
# You can verfiy the virtual keyboard functionality by clicking the search field and entering text
# To make qt-kiosk-browser to start automatically after boot instead of seco-show-demo, run following commands and reboot:
systemctl disable seco-show-demo
systemctl enable qt-kiosk-browser
RAM
SW3A/B regulator configuration
Boot the system. Check, which RAM voltage is reported by the bootloader in the console e.g:
DDR3 Voltage: 1350 mV
Find the SW3/DDR voltage regulators in sysfs and check the settings:
for j in $( for i in /sys/class/regulator/*; do grep -q -l -i "DDR_" $i/name && echo $i; done); do
echo $j; cat $j/name;
echo -n " Current Voltage: "; cat $j/microvolts;
echo -n " Min Voltage: "; cat $j/min_microvolts;
echo -n " Max Voltage: "; cat $j/max_microvolts;
echo -n " uEvent: "; grep OF_COMPATIBLE_0 $j/uevent;
done
We have both, systems running with 1.35V and systems running with 1.5V RAM voltage. If the bootloader detects a LOW level on BOOT_CFG4_1 (GPIO5_IO0) through a mounted pull down resistor (R590) it sets the PMIC voltage to 1.5V. Otherwise, a HIGH level through the internal default pull up is detected and the bottloader sets the voltage to 1.35V. Before introducing the 1.35V RAM voltage feature a pull down resistor (R590) was mounted. This means that old systems are always configured for 1.5V RAM voltage.
Hence, the test could have two possible results:
-
Pull down resistor R590 not mounted, 1.35V RAM voltage:
/sys/class/regulator/regulator.18 DDR_1V5a Current Voltage: 1350000 Min Voltage: 0 Max Voltage: 0 uEvent: OF_COMPATIBLE_0=regulator-fixed /sys/class/regulator/regulator.19 DDR_1V5b Current Voltage: 1350000 Min Voltage: 0 Max Voltage: 0 uEvent: OF_COMPATIBLE_0=regulator-fixed
-
Pull down resistor R590 mounted, 1.5V RAM voltage:
/sys/class/regulator/regulator.18 DDR_1V5a Current Voltage: 1500000 Min Voltage: 0 Max Voltage: 0 uEvent: OF_COMPATIBLE_0=regulator-fixed /sys/class/regulator/regulator.19 DDR_1V5b Current Voltage: 1500000 Min Voltage: 0 Max Voltage: 0 uEvent: OF_COMPATIBLE_0=regulator-fixed
Note: regulator number may be different
RS232
RS232 #2
Start a console on the second RS232 interface if present.
setsid getty -L 115200 ttymxc1 vt100
RS485
RS485 Full Duplex
Connect two SECO-NE devices using an RS485 full duplex cable.
# Start echo Server on device #1
/opt/ltp/testcases/bin/rs485echo -n -e -s 115200 -b 64
# Send messages from device #2
/opt/ltp/testcases/bin/rs485echo -n -s 115200 -b 64
RS485 Half Duplex
Connect two SECO-NE devices using an RS485 half duplex cable.
# Start echo Server on device #1
/opt/ltp/testcases/bin/rs485echo -e -s 115200 -b 64
# Send messages from device #2
/opt/ltp/testcases/bin/rs485echo -s 115200 -b 64
RTC
RTC write
Disconnect all network interfaces.
# Set date (02.01.2000) as system time and write it to RTC
date 0102000000
hwclock --systohc
# Read system time
date
# Read RTC
hwclock
# The result should look like: Sat Jan 2 00:00:00 2000 0.000000 seconds
sconfig
sconfig read
sconfig
sconfig set value
At the moment sconfig values can not be modified.
SD-Card
SD-Card read and write
Plug in a SD-Card with at least one partition in fat32 format.
mount /dev/mmcblk1p1 /mnt/
# Verify mount
mount | grep mmcblk1p1
# Write
echo "Test data" > /mnt/testfile
# Read
cat /mnt/testfile
SFTP
The SFTP server is running by default.
SFTP connection
Connect to the device's SFTP server using the sftp
command.
sftp root@<device-ip>
SSH
The SSH server is running by default.
SSH connection
Connect to the device's SSH server using the ssh
command.
ssh root@<device-ip>
Temperature Sensors
Temperature read
For on-board sensors like LM75:
cat /sys/class/hwmon/hwmon0/temp1_input
SOC temperature/s:
cat /sys/class/thermal/thermal_zone*/temp
Touch
General remarks
Since the switch from Rocko to Dunfell, some strange issues showed up for some touch devices:
- Some eeti touches had very bad latency, so that events were partially lost
- For ilitek touches, a very high CPU load was detected due to the ilitek_irq process
The reason for this is a high amount of i2c data caused by some touch controllers and handled too slowly by the i2c driver. These issues were not present with Rocko, because the used i2c driver was much faster in processing the touch data. In contrast to the Dunfell/Kirkstone version, the Rocko driver handles the i2c transfers within its ISR routine, which is much faster then using wait queues. To solve this, an option to perform i2c reads within the ISR was added in kirkstone (kernel 5.15.32) i2c driver.
fingerpaint
# Preperation
systemctl stop seco-show-demo
fingerpaint
fingerpaint rotated by 90 deg
# Preperation
systemctl stop seco-show-demo
sed -i 's/transform=.*$/transform=rotate-90/g' /etc/xdg/weston/weston.ini
systemctl restart weston
fingerpaint
USB
USB Host read and write
Plug in a USB-Stick with at least one partition in fat32 format.
mount /dev/sda1 /mnt/
# Verify mount
mount | grep sda1
# Write
echo "Test data" > /mnt/testfile
# Read
cat /mnt/testfile
Serial console on USB OTG port (SANTARO, SANTOKA, SANTINO, SANTINO-LT)
Start a console on the USB OTG port.
modprobe g_serial
setsid getty -L 115200 ttyGS0 vt100
Video playback
MPEG2 playback
# Preparation
systemctl stop seco-show-demo
curl http://support.garz-fricke.com/projects/TestFiles/Videos/cc-BigBuckBunny-Trailer-800x448-mpeg2-stereo.mpg > /tmp/video
gst-play-1.0 /tmp/video
MPEG4 ASP playback
# Preperation
systemctl stop seco-show-demo
curl http://support.garz-fricke.com/projects/TestFiles/Videos/cc-BigBuckBunny-Trailer-800x448-mpeg4-stereo.mp4 > /tmp/video
gst-play-1.0 /tmp/video
MPEG4 AVC playback
# Preperation
systemctl stop seco-show-demo
curl http://support.garz-fricke.com/projects/TestFiles/Videos/cc-BigBuckBunny-Trailer-800x448-h264-stereo.mp4 > /tmp/video
gst-play-1.0 /tmp/video
VP9 playback from qml
# Preperation
systemctl stop seco-show-demo
qmlscene /opt/ltp/scripts/video_playback.qml
Watchdog
Watchdog test
/opt/ltp/testcases/bin/watchdog-test
WiFi
Scan wireless networks (nmcli)
nmcli dev wifi list
Connect to wireles network (nmcli)
nmcli dev wifi connect <ssid> password "<password>"