Unable to obtain /dev/spi1

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

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

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
<Dropbox - File Deleted - Simplify your life; 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....)

BeagleBone Black Enable SPIDEV - eLinux.org 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

Redirecting to Google Groups 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

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:

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...

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...

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:

Likely means one must "modprobe" or similar to activate them.

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: