STM32MP157C-DK2 w/ Debian 10.9 has no /dev/spi* devices

I’ve built the Debian 10.9 image, and it boots with no issues. However, after ‘modprobe spidev’, I have no /dev/spi* devices. It did create /sys/class/spidev, but the directory is empty, as is /sys/class/spi-master and /sys/class/spi-slave (although I don’t care about SPI slave functionality).

I’ve decompiled the stm32mp157c-dk2.dtb device tree binary, and spi1 is present.

The goal is to have SPI on the RPi connector on physical pins 19, 21, 23, and 24 (standard RPi 40 pin mapping)

Any ideas why no SPI devices are enumerating?


Please share your *.dts file with the spi configuration such that i can take a look and see why it didn’t populate.


This is the decompiled version. The source files are the versions in 5.10.41-armv7-lpae-x41.

stm32mp157c-dk2.dts (103.7 KB)

Ah, so the default… Here’s my repo with all changes:

spidev is not enabled…

Which spi pin pairs are you looking at utilizing?


That’s the one I’m already using, from your repo per the instructions at

The SPI pinout I desire is per,

SCK == SPI5_SCK == PF7
NSS == SPI5_NSS == PF6

I don’t know if it’s relevant to the problem or not, but I noticed that when decompiling the DTB, I got these warnings:

debian@arm:~$ dtc -I dtb -O dts -f /boot/dtbs/5.10.41-armv7-lpae-x41/stm32mp157c-dk2.dtb -o stm32mp157c-dk2.dts
stm32mp157c-dk2.dts: Warning (unique_unit_address): /soc/spi@4000b000: duplicate unit-address (also used in node /soc/audio-controller@4000b000)
stm32mp157c-dk2.dts: Warning (unique_unit_address): /soc/spi@4000c000: duplicate unit-address (also used in node /soc/audio-controller@4000c000)
stm32mp157c-dk2.dts: Warning (unique_unit_address): /soc/spi@44004000: duplicate unit-address (also used in node /soc/audio-controller@44004000)

Hi @jcwren please test:

git clone
cd armv7-lpae-multiplatform/
git checkout origin/v5.13.x -b tmp
debian@arm:~$ ls -lha /dev/spidev*
crw-rw---- 1 root spi 153, 0 Jun 24 15:20 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 Jun 24 15:20 /dev/spidev1.0
debian@arm:~$ uname -r



I haven’t been able to test the actual SPI operation as I need to get some I/O reconfigured, but it is present in /dev.

It seems odd I’d be the first one reporting this. I’m guessing not many people are using the STM32MP1?

Well, I’d like to report success, but no :frowning:

I’m getting no activity on any of the SPI lines, and dmesg reports:

[  327.112984] spi_stm32 44005000.spi: DMA error (sr=0x00040012)

Hi @jcwren you are the first person that’s asked me… humm, i wonder if we disable dma on the spi?

Edit: thinking: stm32mp15xx-dhcom-drc02.dtsi « dts « boot « arm « arch - kernel/git/torvalds/linux.git - Linux kernel source tree

Which would be:

&spi5 {
	pinctrl-names = "default";
	pinctrl-0 = <&spi5_pins_a>;
	cs-gpios = <&gpiof 6 GPIO_ACTIVE_HIGH>;
	/* Use PIO Mode */
	status = "okay";

	spidev@0 {
		compatible = "spidev";
		reg = <0>;
		spi-max-frequency = <4000000>;
		st,spi-midi-ns = <4000>;


OK, what am I doing wrong? I’ve edited ./armv7-lpae-multiplatform/KERNEL/arch/arm/boot/dts/stm32mp157c-dk2.dts, but the ./armv7-lpae-multiplatform/ script seems to be pulling the file from the repo and overwriting the changes. How am I supposed to integrate your test changes? will always rewrite ./KERNEL/ directory…

After you make a change under ./KERNEL/, use ./tools/


OK, rebuilt with no DMA changes. Eliminated the DMA error, but still no activity on SCK, MOSI, or NSS. Nothing in dmesg, no errors from the application (which checks all return values). Checked the datasheet, PF6…9 are the correct pins, AF5 is the correct alternate function, no solder jumpers that need to be installed or removed according to the schematic, exact same code runs on a Raspberry Pi 4 correctly. I am at a loss.

Can you try the other SPI port pins?

My portable USB logic analyser is at the office, i’ll grab that on Monday…


My fault. I expected /dev/spidev0.0 to be the SPI device on the RPi bus. When I ls'ed the /dev/ tree, I read spidev1.0 as spidev0.1 (lysdexia!), which I’ve seen present on several implementations, but never used. I think that’s what used when there’s a second NSS pin on that SPI master.

So, from a hardware perspective, this is now working. However, I disabled spi4 (first tried setting it’s status to disabled instead of ok, and then commenting out the spi4 block completely), but spi5 was still appearing as /dev/spidev1.0. I think the RPi connector should be spidev0.0 and spi4 on the Arduino CN13 connector should be spidev1.0.

ST expects the Arduino header to be /dev/spidev0.0

You can tweak the label with:


ST has been wrong about lots of things before :slight_smile: I imagine more people are going to run RPi Linux code on the board than the Arduino people would, and, unfortunately, a lot of RPi apps assume that /dev/spidev0.0 is what’s connected to the RPi connector. But anyway…

Not sure if I should tack this on here or open a new report, but i2c5 isn’t “connected” to the RPi or Arduino connectors. The fix (right or wrong) that worked for me was adding:

&i2c5 {
       pinctrl-names = "default", "sleep";
       pinctrl-0 = <&i2c5_pins_a>;
       pinctrl-1 = <&i2c5_sleep_pins_a>;
       i2c-scl-rising-time-ns = <185>;
       i2c-scl-falling-time-ns = <20>;
       clock-frequency = <400000>;
       /* spare dmas for other usage */
       status = "okay";

Thanks for the SPI fixes. Are you going to merge those into the armv7-lpae-multiplatform repo now?