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.
aplay /usr/share/sounds/alsa/*
wget -P /tmp/ http://support.garz-fricke.com/projects/TestFiles/Audio/short_click_4_times.wav
aplay /tmp/short_click_4_times.wav
#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
Test
Start speaker-test for HDMI card.
speaker-test -c 2 -t wav -D sysdefault:CARD=DWHDMI
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 is currently only basically supported. Commands used for a basic hardware test:
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
BT was tested on Tanaro via Audio profile according to the following methodology:
# rtk_hciattach ttymxc3 rtk_h5
# hciconfig hci0 up
# 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
# rtk_hciattach ttymxc3 rtk_h5
# hciconfig hci0 up
# 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
# rfcomm --raw listen /dev/rfcomm0 0
Waiting for connection on channel 0
$ 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.
# 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 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.
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
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
Test Setup
Test
ifconfig can0 down
ip link set can0 up type can bitrate 1000000
ifconfig can0 up
ifconfig can0
candump can0
cangen can0 -n 10 -v
cansend can0 '5A1#11.22.33.44.55.66.77.88'
ifconfig can0
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.
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
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.
#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
Test
Run prepared backlight-test.sh.
sh /tmp/backlight-test.sh
Expected results
During the test:
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.
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.
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.
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.
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
gfeeprom --show
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
Test Setup
iperf3 -s -p 5201
nslookup north.seco.com
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.
Basic test of the iptables
functionality.
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.
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
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.
Check if a HDMI DRM device was created.
ls /sys/class/drm/ | grep HDMI
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
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.
#Test Setup
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.
#Test Setup
Test
mdbtest_slave ttymxc3
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.
#Test Setup
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".
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:
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
echo +5 > /sys/class/rtc/rtc1/wakealarm && echo standby > /sys/power/state
# The device should wake up after 5 seconds
echo enabled > /sys/class/tty/ttymxc0/power/wakeup && echo standby > /sys/power/state
# Device has to wake up after keypress on the serial console
echo +5 > /sys/class/rtc/rtc1/wakealarm && echo mem > /sys/power/state
# The device should wake up after 5 seconds
echo enabled > /sys/class/tty/ttymxc0/power/wakeup && echo mem > /sys/power/state
# Device has to wake up after keypress on the serial console
#Test Setup
echo 8 > /proc/sys/kernel/printk
.Test
echo +30 > /sys/class/rtc/rtc1/wakealarm && echo standby > /sys/power/state
Expected results
The device should wake up after 5 seconds.
Test
echo enabled > /sys/class/tty/ttymxc0/power/wakeup && echo standby > /sys/power/state
Expected results
Device has to wake up after keypress on the serial console.
Test
echo +30 > /sys/class/rtc/rtc1/wakealarm && echo mem > /sys/power/state
Expected results
The device should wake up after 5 seconds.
Test
echo enabled > /sys/class/tty/ttymxc0/power/wakeup && echo mem > /sys/power/state
Expected results
Device has to wake up after keypress on the serial console.
#Test Setup
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.
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.
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>
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
# Preperation
systemctl stop seco-show-demo
qt5-opengles2-test
# When you touch the display, a rectancle should show up under the finger
# Preperation
systemctl stop seco-show-demo
sed -i 's/"URL":.*$/"URL": "https:\/\/north.seco.com\/suchen?",/' /etc/qt-kiosk-browser.conf
qt-kiosk-browser /etc/qt-kiosk-browser.conf --no-sandbox
# You can verfiy the virtual keyboard functionality by clicking the search field and entering text
Start a console on the second RS232 interface if present.
setsid getty -L 115200 ttymxc1 vt100
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
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
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
At the moment sconfig values can not be modified.
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
The SFTP server is running by default.
Connect to the device's SFTP server using the sftp
command.
sftp root@<device-ip>
The SSH server is running by default.
Connect to the device's SSH server using the ssh
command.
ssh root@<device-ip>
For on-board sensors like LM75:
cat /sys/class/hwmon/hwmon0/temp1_input
SOC temperature/s:
cat /sys/class/thermal/thermal_zone*/temp
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.
# Preperation
systemctl stop seco-show-demo
fingerpaint
# Preperation
systemctl stop seco-show-demo
sed -i 's/transform=.*$/transform=rotate-90/g' /etc/xdg/weston/weston.ini
systemctl restart weston
fingerpaint
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
Start a console on the USB OTG port.
modprobe g_serial
setsid getty -L 115200 ttyGS0 vt100
# 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
# 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
# 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
# Preperation
systemctl stop seco-show-demo
qmlscene /opt/ltp/scripts/video_playback.qml
/opt/ltp/testcases/bin/watchdog-test
nmcli dev wifi list
nmcli dev wifi connect <ssid> password "<password>"