Do the SPI connections on the M4 header work?

Has anyone had any luck in getting the general purpose SPI port to work on the M4? The documentation I have found so far is a little vague, suggesting that the device tree needs to be changed along with the kernel configuration. As best I can tell, .config has all the appropriate flags set (CONFIG_SPI, CONFIG_SPI_DEBUG, CONFIG_SPI_MASTER, CONFIG_SPI_BITBANG, CONFIG_SPI_SPIDEV and CONFIG_SPI_RTK129X), and the kernel build reports success. However, none of the corresponding kernel objects are being built, and none seem to exist in the stock image for the M4, although they are in the stock image for the BPI-64. I have seen a number of other questions about SPI on this forum, but none of the answers seem helpful for this situation and none are specifically for the M4.

this is BPI-W2 gpio ,you can reference this

Please help me understand this answer. My entire issue is that all pins appear to be in GPIO mode and none of the SPI support modules appear to be compiling with a kernel build. The script at https://github.com/BPI-SINOVOIP/BPI-files/blob/master/others/logfile/bpi-w2/20181017/bpi-w2-gpio40-led.sh appears to only cycle the GPIO, particularly the pin attached to the user LED. It does not appear to address SPI in any way. Did I miss something?

BPI-M4 GPIO demo:

source code:

That is a very nice video of GPIO being used as GPIO. It shows nothing about the pins being used for their SPI function. Are you trying to explain with minimum words that GPIO works, but that you either don’t know whether SPI works or that it does not work and you would rather not say so?

Hi Jack,

Did you manage to get the SPI working? This would simplify my setup not using an USBSPI adapter.

cheers, Martijn

SPI like I2C should usually show up in the device tree like /dev/spidev0. This is the communication port that a program will operate on. If this isn’t there it most likely mean the SPI driver is not loaded. Driver could have been compiled into the kernel, but most likely it is supposed to be loaded dynamically. For later Kernels this is done via DTS and config file:

$ cat /boot/config.txt | grep spi
dtparam=spi=on

However you should also be able to load it via command line like:

$ modprobe spidev
$ ls -l /dev/spi*

There should be actually 2 spi device drivers loaded, one is the chip driver and the other spidev is to map it to the userland.

You said your .config file includes the SPI tags, however you not seem to indicate if they are set to ‘Y’ (build in) or ‘M’ (dynamic module) nor did I read that you actually tried to build your own kernel, nor if you then copied the necessary modules to the module folder. Eventually check what following commands return:

$ grep spidev /lib/modules/$(uname -r)/modules.builtin
$ modprobe -v spidev
$ lsmod | grep spidev
$ dmesg | grep spidev
$ dtc -I fs /proc/device-tree | grep spi

I don’t know what you connected to your SPI to test this interface, but already from the shell you should be able to send data via:

$ echo -ne "\xff" > /dev/spidev0.0

which would send the value 255 to your SPI device

I was looking at this page. Do we need to enable stuff in the DTS as wel? Trying to do I2C as well, but also no luck. No activity on the pins using a Saleae Logic analyzer.

I have made some progress towards getting SPI to work but got stuck because the chip select pin is not working. Thread about this issue here: