2023-12-16 08:21 AM
Hello
I have an STM32MP135x-DK board and have built my own openstllinux image and rootfs for it as shown in this article.
https://wiki.st.com/stm32mpu/wiki/STM32MP1_Distribution_Package
Now I'm trying to get spi5 to show up in /dev so I can use spidev to write some user applications using spi5 as a generic spi master. The tl;dr is that I'm having issues even getting anything to show up in /sys/class/spi_master, much less /dev/spidev.
DETAILS:
I have followed the instructions here to configure the kernel and used a separate install of stm32cube IDE with the STM32MP135x-DK example project to generate my device tree with SPI5 enabled. Since then though, I have tried making a lot of hand-edits to my .dts file as I became more familiar with the syntax.
https://wiki.st.com/stm32mpu/wiki/SPI_overview
Here's what my .config file looks like in my kernel's build directory (with commented out options removed).
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
CONFIG_SPI_MEM=y
CONFIG_SPI_GPIO=m
CONFIG_SPI_STM32=m
CONFIG_SPI_STM32_QSPI=m
CONFIG_SPI_SPIDEV=m
CONFIG_SPI_SLAVE=y
CONFIG_SPI_DYNAMIC=y
CONFIG_SPMI=y
CONFIG_PPS=y
Right now the options I need are specified as kernel modules, but I have tried compiling them into the kernel as well. I had no issues selecting these options using "bitbake -c menuconfig virtual/kernel" and am experienced and comfortable doing kernel development in yocto using bitbake or in "bitbake -c devshell linux-stm32mp"
Now for the device tree. I have made the edit to the device tree recommended in this article, but tweaked them to accomodate the pinout for spi5 of my dev board.
https://wiki.st.com/stm32mpu/wiki/SPI_device_tree_configuration#cite_note-DT_MP15_pinctrl-8
Here is the part in particular I have been looking at, but I have also uploaded the entire .dts file to this post.
&spi5 {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&spi5_pins_a>;
pinctrl-1 = <&spi5_sleep_pins_a>;
status = "okay";
cs-gpios= <&gpioh 11 0>;
master@0 {
compatible = "rohm,dh2228fv";
reg = <0>;
spi-max-frequency = <10000000>;
};
};
I have been able to rebuild the device tree in a devshell and have no issues scp'ing it over to my target board and rebooting with it. However, I just can't for the life of me get any spidev device to show up in /dev or even get an spi master to show up in /sys/class/spi_master
I also don't see spidev in the output of lsmod and no spi related messages have shown up in dmesg for any of my attempts.
I have used to md5sum utility to verify that the kernel images and dtb's I have compiled are the ones on target and am comfortable making tweaks to kernel config and device tree options but now don't know where else to look for debug information. This is my first foray into device tree development, so I'm wondering if there is something very amateurish that I have overlooked in all of this.
Thank you for any support that can be provided on this issue.
Solved! Go to Solution.
2023-12-19 04:58 PM
Progress has been made.
The first issue was with my uboot environment. I got so preoccupied thinking my device tree edits were wrong that I didn't think of it earlier.
As part of my custom machine I gave my device tree blob a custom name ("iris.dtb") to distinguish it from the default for this dev board "stm32mp135f-dk.dtb". I made a recipe that places iris.dtb in the /boot directory instead of the default. The board booted up fine without modifying the uboot environment so I assumed it was picking up my customized device tree (the only device tree in the /boot directory). That is where I was wrong. I needed to modify the fdt_addr variable in uboot to point to the new file name.
so previously in the uboot environment:
STM32MP> printenv fdtfile
fdtfile=stm32mp135f-dk.dtb
but the needed value is
STM32MP> setenv fdtfile {custom dtb name}
STM32MP> saveenv
//or in my case
STM32MP> setenv fdtfile iris.dtb
STM32MP> saveenv
Saving Environment to MMC... Writing to MMC(0)... OK
Now I can see my SPI master show up in /sys
root@iris-machine:~# ls /sys/class/spi_master/spi0/
device of_node power spi0.0 statistics subsystem uevent
There is still now device in /dev yet, but now at least thinks aren't so confounding.
2023-12-19 02:30 AM
Hello @robo1340 ,
I do not see obvious error in the DTS extract you shared above, so we will need to process step by step.
1) Are you sure that your own compiled DTB is the one that is loaded by the system ?
2) Can you share all the boot logs in a text file ?
Kind regards,
Erwan.
2023-12-19 05:34 AM
Here's my boot log. I also added the output of a few commands at the end to help.
I am certain that the DTB I am placing in the target system's /boot directory is the one I'm creating from my DTS. I have been using the md5sum tool to verify its the one I expect.
robo1340@yocto-build-machine:~/stm32mp1/build-openstlinuxweston-stm32mp13-disco/tmp-glibc/work/iris_machine-ostl-linux-gnueabi/linux-stm32mp/6.1.28-stm32mp-r1-r0/build/arch/arm/boot/dts$ md5sum iris.dtb
c33d606f739a4560697b18ebfb518718 iris.dtb
...
root@iris-machine:/# md5sum /boot/iris.dtb
c33d606f739a4560697b18ebfb518718 /boot/iris.dtb
Come to think of it though. I have not actually checked to see if uboot is picking up the DTB from /boot. I assumed it is but will verify.
2023-12-19 04:58 PM
Progress has been made.
The first issue was with my uboot environment. I got so preoccupied thinking my device tree edits were wrong that I didn't think of it earlier.
As part of my custom machine I gave my device tree blob a custom name ("iris.dtb") to distinguish it from the default for this dev board "stm32mp135f-dk.dtb". I made a recipe that places iris.dtb in the /boot directory instead of the default. The board booted up fine without modifying the uboot environment so I assumed it was picking up my customized device tree (the only device tree in the /boot directory). That is where I was wrong. I needed to modify the fdt_addr variable in uboot to point to the new file name.
so previously in the uboot environment:
STM32MP> printenv fdtfile
fdtfile=stm32mp135f-dk.dtb
but the needed value is
STM32MP> setenv fdtfile {custom dtb name}
STM32MP> saveenv
//or in my case
STM32MP> setenv fdtfile iris.dtb
STM32MP> saveenv
Saving Environment to MMC... Writing to MMC(0)... OK
Now I can see my SPI master show up in /sys
root@iris-machine:~# ls /sys/class/spi_master/spi0/
device of_node power spi0.0 statistics subsystem uevent
There is still now device in /dev yet, but now at least thinks aren't so confounding.
2023-12-19 05:28 PM
Getting the device to show up in /dev after this point was pretty easy.
From this ST wiki article.
https://wiki.st.com/stm32mpu/wiki/SPI_overview#Kernel_configuration
"If the spidev driver is compiled into the kernel, the repository /dev contains all SPI device entries. They are numbered spix.y where:"
So I take that to mean I was wrong for compiling spidev as a kernel module. I changed the kernel config back to compile it into the kernel as well as st's driver below it and now I can see my device in /dev
root@iris-machine:~# ls /dev/spi*
/dev/spidev0.0
2023-12-19 11:36 PM
Hello @robo1340 ,
Thank you for your feedback and your confirmation, it can also help other community members.
Kind regards,
Erwan.