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.

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:

  1. Add "bluealsa" package to the image.
  2. Bring up a BT controller:
# rtk_hciattach ttymxc3 rtk_h5
# hciconfig hci0 up
  1. 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).
# 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
# 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
# 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

  1. Bring up a BT controller on Tanaro:
# rtk_hciattach ttymxc3 rtk_h5
# hciconfig hci0 up
  1. Connect to another PC/board with BT device and which is capable of using rfcomm.
# 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
  1. On Tanaro, start listening on /dev/rfcomm0 port via rfcomm tool:
# rfcomm --raw listen /dev/rfcomm0 0
Waiting for connection on channel 0
  1. 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.
  1. 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
  1. Transfer some data via /dev/rtcomm0 between Tanaro and the second PC/board:

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

Test

  1. 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
  1. On the device under test start candump.
candump can0
  1. On the reciver device run cangen and cansend.
cangen can0 -n 10 -v
cansend can0 '5A1#11.22.33.44.55.66.77.88'
  1. On the device under test stop stop candump. On both boards check interface statistics.
ifconfig can0
  1. 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

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
[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:


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.

Otherwise the original eeprom values may get lost.

# 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

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


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


MDB test

Test

  1. Start slave test on SantVend board with slave part of the MDB cable:
mdbtest_slave ttymxc3
  1. 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


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:

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

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


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:

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:

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>"