Unable to obtain /dev/spi1

[joant...@gmail.com]

Hi,

I'm trying to use spi1 on a BeagleBone Black. Since I don't know how to deal with cape manager and to load dtbo files I decided to modify am335x-boneblack.dts file. DTS file Also I've learnt that I needed to deactivate HDMI and MCASP0. Despite so /dev/spi1 device is not created.

The results of the commands below would indicate that the dts file is properly modified but it seems there is still missing something. I've used buildroot (LTS version) configured as "beaglebone_defconfig"

[root@buildroot]# find / -name spi1
/sys/devices/platform/ocp/481a0000.spi/spi_master/spi1
/sys/class/spi_master/spi1
/sys/firmware/devicetree/base/__symbols__/spi1
/sys/firmware/devicetree/base/aliases/spi1

[root@buildroot]# find / -name spidev@1
/sys/firmware/devicetree/base/ocp/spi@481a0000/spidev@1

[root@buildroot]# find / -name spi
/sys/bus/spi
/lib/modules/4.14.40/kernel/drivers/spi

[root@buildroot]# ll /dev/ |grep -i spi
[root@buildroot]#

[root@buildroot]# dmesg |grep -i spi
[root@buildroot]#

I've also tried by manually loading spi-ti-qspi-ko kernel driver without success.

Any help?

Thanks,

Joan

[Dennis Lee Bieber]

{blast -- forgot to use email reply, so I'm going to be dinged by the
autoresponder again <G>}

On Fri, 22 Nov 2019 01:54:48 -0800 (PST), in
gmane.comp.hardware.beagleboard.user

joantavlas-Re5JQ...@public.gmane.org wrote:

>Hi,
>
>I'm trying to use spi1 on a BeagleBone Black. Since I don't know how to
>deal with cape manager and to load dtbo files I decided to modify
>am335x-boneblack.dts file. DTS file

><https://www.dropbox.com/s/s4vdtpebwo56fxu/am335x-boneblack.dts?dl=0> Also

>I've learnt that I needed to deactivate HDMI and MCASP0. Despite so
>/dev/spi1 device is not created.
>

You haven't mentioned compiling your modified DTS file... Really, if
you can understand the device tree source enough to modify it, compile it,
and place it into the correct location for subsequent boots, playing with
/boot/uEnv.txt should be trivial...

>The results of the commands below would indicate that the dts file is
>properly modified but it seems there is still missing something. I've used
>buildroot (LTS version) configured as "beaglebone_defconfig"
>
>[root@buildroot]# find / -name spi1
>/sys/devices/platform/ocp/481a0000.spi/spi_master/spi1
>/sys/class/spi_master/spi1
>/sys/firmware/devicetree/base/__symbols__/spi1
>/sys/firmware/devicetree/base/aliases/spi1
>

Even the STOCK LXQT image (I have done nothing with device trees)
https://debian.beagleboard.org/images/bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz
shows

debian@beaglebone:~$ sudo find / -iname "spi1"
[sudo] password for debian:
/sys/devices/platform/ocp/48030000.spi/spi_master/spi1
/sys/class/spi_master/spi1
/sys/firmware/devicetree/base/__symbols__/spi1
/sys/firmware/devicetree/base/aliases/spi1
debian@beaglebone:~$

so your above check is likely meaningless. The following rambling is being
done with the IoT image (I'd thought it might have already disabled HDMI,
but nooooo....)

https://elinux.org/BeagleBone_Black_Enable_SPIDEV appears to be quite
out-of-date, since everything they mention finding via "ls" is shown
without ever changing a device tree. And especially the
echo BB-SPI1-01 > /sys/devices/bone_capemgr.*/slots
as there is no capemgr directory in /sys/devices anymore. There is one in
/sys/firmware/devicetree/base

https://groups.google.com/forum/#!topic/beagleboard/RShjePl0noY is more
up-to-date with current images

>[root@buildroot]# find / -name spidev@1
>/sys/firmware/devicetree/base/ocp/spi@481a0000/spidev@1

No such critter... Actually, no .../spidev@anything (there ARE
.../channel@0 and .../channel@1 )

And to confuse matters it appears that
OVERLAY /dev
BB-SPIDEV0-00A0 /spidev1.x
BB-SPIDEV1-00A0 /spidev2.x

Disabling all the system overlays and adding the SPIDEV overlays
(difference in /boot/uEnv.txt shown next)

debian@beaglebone:~$ diff /boot/uEnv.txt mod_uEnv.txt
19c19,20
< #uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
---
> uboot_overlay_addr4=/lib/firmware/BB-SPIDEV1-00A0.dtbo
> uboot_overlay_addr5=/lib/firmware/BB-SPIDEV0-00A0.dtbo
28,32c29,33
< #disable_uboot_overlay_emmc=1
< #disable_uboot_overlay_video=1
< #disable_uboot_overlay_audio=1
< #disable_uboot_overlay_wireless=1
< #disable_uboot_overlay_adc=1
---
> disable_uboot_overlay_emmc=1
> disable_uboot_overlay_video=1
> disable_uboot_overlay_audio=1
> disable_uboot_overlay_wireless=1
> disable_uboot_overlay_adc=1
debian@beaglebone:~$

seems to work (once I figured out I had /spidev1.x jumpered wrong for the
test program)

Note: other than the "disable" lines above, the spi overlays were not
mandatory -- config-pin is sufficient!

#/dev/spidev1.x
debian@beaglebone:~$ sudo config-pin p9_21 spi
debian@beaglebone:~$ sudo config-pin p9_18 spi
debian@beaglebone:~$ sudo config-pin p9_17 spi_cs
debian@beaglebone:~$ sudo config-pin p9_22 spi_sclk
#/dev/spidev2.x
debian@beaglebone:~$ sudo config-pin p9_30 spi
debian@beaglebone:~$ sudo config-pin p9_29 spi
debian@beaglebone:~$ sudo config-pin p9_28 spi_cs
debian@beaglebone:~$ sudo config-pin p9_31 spi_sclk
#with jumper p9_21 <> p9_18 and p9_30 <> p9_29
#even without having the book, you can get/build the test program
# http://exploringbeaglebone.com/source/
debian@beaglebone:~$ ./exploringBB/chp08/spi/spidev_test/spidev_test -D
/dev/spidev2.0
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)

FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D
debian@beaglebone:~$ ./exploringBB/chp08/spi/spidev_test/spidev_test -D
/dev/spidev1.0
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)

FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D
debian@beaglebone:~$

HMMM! looks like "sudo" wasn't needed anymore, either.

SEQUENCE to enable both SPI devices!:

EDIT /boot/uEnv.txt
CHANGE
#disable_uboot_overlay_video=1
TO
disable_uboot_overlay_video=1
REBOOT
EXECUTE... (I put them into a shell script as I was doing so many reboots)
debian@beaglebone:~$ cat setspi.sh
#!/usr/bin/env bash
#/dev/spidev1.x aka overlay spidev0
config-pin p9_21 spi
config-pin p9_18 spi
config-pin p9_17 spi_cs
config-pin p9_22 spi_sclk
#/dev/spidev2.x aka overlay spidev1 Conflicts with HDMI overlay
config-pin p9_30 spi
config-pin p9_29 spi
config-pin p9_28 spi_cs
config-pin p9_31 spi_sclk

(if you do not disable video, the above will result in errors for pins 28,
29, and 31, used by HDMI)

debian@beaglebone:~$ ./setspi.sh
P9_29 pinmux file not found!
sudo: no askpass program specified, try setting SUDO_ASKPASS
Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state
P9_28 pinmux file not found!
sudo: no askpass program specified, try setting SUDO_ASKPASS
Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_28_pinmux/state
P9_31 pinmux file not found!
sudo: no askpass program specified, try setting SUDO_ASKPASS
Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_31_pinmux/state


Putting the SPIDEV overlays into /boot/uEnv.txt will result in locking
the pins to SPI, removing them from config-pin set-up.

--
Dennis L Bieber

[joant...@gmail.com]

Dennis,

Thanks for your feedback. Regarding your comment about whether I had compiled the dts source file, I used the mechanism provided by buildroot: “make linux-rebuild” and then “make”. Since I’m not and expert in modifying dts files and I made some mistakes, I had to correct them in that file. So, I’m sure am335x-boneblack.dtb file used by uboot contains the modifications I made to dts.

As for the list of commands I launched in order to pinpoint the problem, I might agree with you that it is meaningless. Which commands would you try in order to identify the problem? My understanding is that spidev_test program is useless unless you have those /dev/spi* devices created beforehand.

I'm beginning to think that the cause of the problem is in the kernel configuration rather than in the dts files. Specifically in spidev. The command "lsmod" reports no modules loaded when bootstrapping the BBB using the images generated by buildroot. In case of using Debian images provided "lsmod" reports a list of modules, one of them being "spidev".

Ideas?

Thanks again,

Joan Salvat

El dilluns, 25 novembre de 2019 0:20:11 UTC+1, Dennis Bieber va escriure:

{blast -- forgot to use email reply, so I'm going to be dinged by the
autoresponder again <G>}

[Dennis Lee Bieber]

On Wed, 27 Nov 2019 06:15:05 -0800 (PST), in
gmane.comp.hardware.beagleboard.user

joantavlas-Re5JQ...@public.gmane.org wrote:

>
>I'm beginning to think that the cause of the problem is in the kernel
>configuration rather than in the dts files. Specifically in spidev. The
>command "lsmod" reports no modules loaded when bootstrapping the BBB using
>the images generated by buildroot. In case of using Debian images provided
>"lsmod" reports a list of modules, one of them being "spidev".
>

Do you really need to create a system using buildroot? My initial
response was predicated on the comment about capemgr/u-boot, et al.

I'll have to confess I've never done that level of work (build a system
from scratch) and am now following {bloody google tracking overhead}
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwiL59Sv5YrmAhVKYKwKHTb7DSsQFjAAegQIBhAC&url=https%3A%2F%2Fbootlin.com%2Fdoc%2Ftraining%2Fbuildroot%2Fbuildroot-labs.pdf&usg=AOvVaw3X6KTtUbYmciE32KFOvibu

I note that under target-packages/hardware-handling there is a spi-tools
entry (also some pru packages). Suspect buildroot config has been updated
since that PDF, I'm finding some options not covered, and some wording
changes.

I also don't have the wireless model, so may have further problems.
Besides just the tediousness of trying to make sense of the config options.
Without the PRU stuff flagged, and getting the proper u-boot config to
allow building it seems to be doing something...

NOTE:
Took a chance while it is still working on the build and found this...

wulfraed@debian:~/buildroot$ grep -i "spi" build.log
HOSTCC tools/rkspi.o
CC cmd/spi.o
CC drivers/mtd/spi/sf_probe.o
CC drivers/mtd/spi/spi_flash.o
CC drivers/mtd/spi/spi_flash_ids.o
CC drivers/mtd/spi/sf.o
LD drivers/mtd/spi/built-in.o
CC drivers/spi/spi.o
CC drivers/spi/omap3_spi.o
LD drivers/spi/built-in.o
This board does not use CONFIG_DM_SPI. Please update
This board does not use CONFIG_DM_SPI_FLASH. Please update
the board to use CONFIG_SPI_FLASH before the v2019.07 release.
wulfraed@debian:~/buildroot$

Don't know if spidev will appear at some point...
--
Dennis L Bieber

[Dennis Lee Bieber]

On Wed, 27 Nov 2019 13:39:50 -0500, in gmane.comp.hardware.beagleboard.user
Dennis Lee Bieber <dennis.l.bieber-Re5...@public.gmane.org>
wrote:

Follow up... I seem to have had a successful completion (testing it on the
BBB is another matter)

>
wulfraed@debian:~/buildroot$ grep -i "spi" build.log
HOSTCC tools/rkspi.o
CC cmd/spi.o
CC drivers/mtd/spi/sf_probe.o
CC drivers/mtd/spi/spi_flash.o
CC drivers/mtd/spi/spi_flash_ids.o
CC drivers/mtd/spi/sf.o
LD drivers/mtd/spi/built-in.o
CC drivers/spi/spi.o
CC drivers/spi/omap3_spi.o
LD drivers/spi/built-in.o
This board does not use CONFIG_DM_SPI. Please update
This board does not use CONFIG_DM_SPI_FLASH. Please update
the board to use CONFIG_SPI_FLASH before the v2019.07 release.

CC kernel/locking/spinlock.o
CC kernel/locking/spinlock_debug.o
CC drivers/base/regmap/regmap-spi.o
CC lib/bust_spinlocks.o
AR drivers/media/spi/built-in.a
AR drivers/net/can/spi/built-in.a
AR drivers/mtd/nand/spi/built-in.a
CC drivers/spi/spi.o
CC drivers/spi/spi-mem.o
CC drivers/spi/spi-omap2-mcspi.o
AR drivers/spi/built-in.a
CC [M] drivers/iio/accel/st_accel_spi.o
CC [M] drivers/iio/common/st_sensors/st_sensors_spi.o
CC [M] drivers/iio/pressure/bmp280-spi.o
CC [M] drivers/mtd/spi-nor/spi-nor.o
CC [M] drivers/spi/spi-ti-qspi.o
CC [M] drivers/media/rc/ir-spi.o
CC [M] drivers/net/wireless/ti/wlcore/spi.o
LD [M] drivers/net/wireless/ti/wlcore/wlcore_spi.o
CC drivers/iio/accel/st_accel_spi.mod.o
CC drivers/iio/common/st_sensors/st_sensors_spi.mod.o
CC drivers/iio/pressure/bmp280-spi.mod.o
CC drivers/media/rc/ir-spi.mod.o
CC drivers/mtd/spi-nor/spi-nor.mod.o
CC drivers/net/wireless/ti/wlcore/wlcore_spi.mod.o
CC drivers/spi/spi-ti-qspi.mod.o
LD [M] drivers/iio/accel/st_accel_spi.ko
LD [M] drivers/iio/common/st_sensors/st_sensors_spi.ko
LD [M] drivers/iio/pressure/bmp280-spi.ko
LD [M] drivers/media/rc/ir-spi.ko
LD [M] drivers/mtd/spi-nor/spi-nor.ko
LD [M] drivers/net/wireless/ti/wlcore/wlcore_spi.ko
LD [M] drivers/spi/spi-ti-qspi.ko
INSTALL drivers/iio/accel/st_accel_spi.ko
INSTALL drivers/iio/common/st_sensors/st_sensors_spi.ko
INSTALL drivers/iio/pressure/bmp280-spi.ko
INSTALL drivers/media/rc/ir-spi.ko
INSTALL drivers/mtd/spi-nor/spi-nor.ko
INSTALL drivers/net/wireless/ti/wlcore/wlcore_spi.ko
INSTALL drivers/spi/spi-ti-qspi.ko
wulfraed@debian:~/buildroot$

No spidev, but there do seem to be a number of spi related kernel
object...
--
Dennis L Bieber

[joant...@gmail.com]

Denis,

I'm using BeagleBone Black as a kind of starter kit to develop some software to be used later in a much constrained hardware environment. Ready to download Beaglebone images are 1G in size while I can obtaind images that occupy 80Mb using buildroot. As for the SPI1 I managed to have that /dev/spidev1.0 device created. I've reviewed the Kernel configuration (make linux-menuconfig; in buildroot) and found that SPI support was implemented as a module (whatever this means). I changed it to "built-in", re-generated the system and those spidev devices appeared. However I haven't succeeded yet: spidev_test sends some bytes but receives none (it displays 0's for the data received) despite having a jumper between P9-29 and P9-30. With the help of an oscilloscope I've been able to see that CS pin and CLK pin output the proper signal. However data that were supposed to be output through DO, was output through DI; although I believe I've properly reversed the default functions of DO and DI. It seems that I still need to tweak that dts file.

Thanks for your support.

Joan Salvat 

El dimecres, 27 novembre de 2019 20:16:21 UTC+1, Dennis Bieber va escriure:

On Wed, 27 Nov 2019 13:39:50 -0500, in gmane.comp.hardware.beagleboard.user

Dennis Lee Bieber <dennis.l.bieber-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[Dennis Lee Bieber]

On Sun, 1 Dec 2019 10:16:41 -0800 (PST), in
gmane.comp.hardware.beagleboard.user

joantavlas-Re5JQ...@public.gmane.org wrote:


>/dev/spidev1.0 device created. I've reviewed the Kernel configuration (make
>linux-menuconfig; in buildroot) and found that SPI support was implemented
>as a module (whatever this means). I changed it to "built-in", re-generated

Likely means one must "modprobe" or similar to activate them.
--
Dennis L Bieber

[joant...@gmail.com]

Dennis,

I finally managed to have spi1 working using D0 as an output and D1 as an input. The missing line in DTS file was:

ti,pindir-d0-out-d1-in = <1>;

It wasn't enough to change D0 and D1 functionality in pin definition.

Best regards,

Joan Salvat

El dilluns, 2 desembre de 2019 19:54:22 UTC+1, Dennis Bieber va escriure:

On Sun, 1 Dec 2019 10:16:41 -0800 (PST), in
gmane.comp.hardware.beagleboard.user