Okay, I finally found one way to run the spi-loopback-test module.
The trick here was to use anyspi Device-Tree overlay, to avoid the dependency of spidev module.
I got my inspiration from this commit.
- First of all, the kernel must be recompiled to include the test feature “spi-loopback-test”.
I followed this guide, cross-compiling from a Ubuntu VM.
- Enable SPI loopback module via “menuconfig” before compiling:
CONFIG_SPI_DEBUG=y and CONFIG_SPI_LOOPBACK_TEST=m
- Load the kernel image and its device-tree onto the target system (RPi4).
- Run the following commands on the RPi4:
$ sudo dmesg -n 8
$ lsmod | grep spi
$ sudo dtoverlay anyspi spi0-1 dev="linux,spi-loopback-test" speed=125000000
$ lsmod | grep spi
spi_loopback_test 28672 0
spidev 20480 0
spi_bcm2835 24576 0
$ dmesg | grep spi > spi-loopback-test.log
$ $ head spi-loopback-test.log -n 15
[ 48.170758] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/spidev@1/status
[ 48.170785] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/spi@7e204000/status
[ 48.182921] spi-bcm2835 fe204000.spi: registered master spi0
[ 48.183056] spi spi0.1: setup: forcing CS_HIGH (use_gpio_descriptors)
[ 48.183075] spi spi0.1: setup mode 0, cs_high, 8 bits/w, 125000000 Hz max --> 0
[ 48.183187] spi-bcm2835 fe204000.spi: registered child spi0.1
[ 48.183217] spi spi0.0: setup: forcing CS_HIGH (use_gpio_descriptors)
[ 48.183232] spi spi0.0: setup mode 0, cs_high, 8 bits/w, 125000000 Hz max --> 0
[ 48.183327] spi-bcm2835 fe204000.spi: registered child spi0.0
[ 48.269732] spi-loopback-test spi0.1: Executing spi-loopback-tests
[ 48.269946] spi-loopback-test spi0.1: Running test tx/rx-transfer - start of page
[ 48.270204] spi-loopback-test spi0.1: with iteration values: len = 0, tx_off = 0, rx_off = 1
[ 48.270431] spi-loopback-test spi0.1: with iteration values: len = 0, tx_off = 0, rx_off = 2
[ 48.270657] spi-loopback-test spi0.1: with iteration values: len = 0, tx_off = 0, rx_off = 3
[ 48.270883] spi-loopback-test spi0.1: with iteration values: len = 0, tx_off = 1, rx_off = 0
$ tail spi-loopback-test.log
[ 51.878516] spi-loopback-test spi0.1: with iteration values: len = 1024, tx_off = 0, rx_off = 0
[ 51.881159] spi-loopback-test spi0.1: with iteration values: len = 1031, tx_off = 0, rx_off = 0
[ 51.883826] spi-loopback-test spi0.1: with iteration values: len = 4093, tx_off = 0, rx_off = 0
[ 51.886892] spi-loopback-test spi0.1: with iteration values: len = 4096, tx_off = 0, rx_off = 0
[ 51.889950] spi-loopback-test spi0.1: with iteration values: len = 4099, tx_off = 0, rx_off = 0
[ 51.893862] spi-loopback-test spi0.1: with iteration values: len = 65536, tx_off = 0, rx_off = 0
[ 51.905280] spi-loopback-test spi0.1: with iteration values: len = 65537, tx_off = 0, rx_off = 0
[ 51.916708] spi-loopback-test spi0.1: with iteration values: len = 131071, tx_off = 0, rx_off = 0
[ 51.937417] spi-loopback-test spi0.1: with iteration values: len = 131072, tx_off = 0, rx_off = 0
[ 52.057851] spi-loopback-test spi0.1: Finished spi-loopback-tests with return: 0
So it looks like the SPI tests succeeded, as expected. Now I know a bit better how to interface the kernel modules to the hardware.
I hope this can be useful to somebody else too.
However, I wonder if there is a simpler solution to load and run this kernel module??
Can it be done without relying on anyspi DT overlay, by only setting the compatible parameter of spi-loopback-mode module?