BBB, device tree seems to work, but no /dev/spidev?

GoogleGroups
1

I’m trying to activate SPI on a BBB. I think it’s nearly there, save for a lack of anything in /dev, which is mysterious.

I’m trying for SPI0 (I understand SPI1 requires HDMI deactivation).

Brand new A5C board, uname -a is
Linux beaglebone 3.8.13 #1 SMP Tue Jun 18 02:11:09 EDT 2013 armv7l GNU/Linux

Followed http://elinux.org/BeagleBone_Black_Enable_SPIDEV, save for

  • my /lib/firmware already had BB-SPI0, so I used that

  • I didn’t understand “Go to My Computer>BeagleBone Getting Started>”. The mounted USB drive device is read-only. I modified the uEnv.txt in /boot, seems to work.

Slots shows it there:

root@beaglebone:~# cat /sys/devices/bone_capemgr.8/slots
0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0

root@beaglebone:~# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
registered pin groups:

…
group: pinmux_bb_spi0_pins
pin 84 (44e10950)
pin 85 (44e10954)
pin 86 (44e10958)
pin 87 (44e1095c)
…

It appears in the dmesg output

root@beaglebone:/dev# dmesg |grep SPI
[ 0.000000] Kernel command line: console=ttyO0,115200n8 quiet drm.debug=7 capemgr.enable_partno=BB-SPI0 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
[ 0.399220] bone-capemgr bone_capemgr.8: enabled_partno part_number ‘BB-SPI0’, version ‘N/A’
[ 0.399293] bone-capemgr bone_capemgr.8: slot #7: ‘Override Board Name,00A0,Override Manuf,BB-SPI0’
[ 0.404238] bone-capemgr bone_capemgr.8: loader: before slot-7 BB-SPI0:00A0 (prio 0)
[ 0.404261] bone-capemgr bone_capemgr.8: loader: check slot-7 BB-SPI0:00A0 (prio 0)
[ 0.404286] bone-capemgr bone_capemgr.8: loader: after slot-7 BB-SPI0:00A0 (prio 0)
[ 0.404315] bone-capemgr bone_capemgr.8: slot #7: Requesting part number/version based 'BB-SPI0-00A0.dtbo
[ 0.404345] bone-capemgr bone_capemgr.8: slot #7: Requesting firmware ‘BB-SPI0-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 0.404401] bone-capemgr bone_capemgr.8: slot #7: dtbo ‘BB-SPI0-00A0.dtbo’ loaded; converting to live tree
[ 0.409351] bone-capemgr bone_capemgr.8: loader: done slot-7 BB-SPI0:00A0 (prio 0)

But no /dev/spi*. Am I expected to mkdev for that? What am I missing ?

2

The BB-SPI0 does not acativate the /dev/spidev device at the moment, so you can not use that. You have to use the one from the elinux site.

During boot up, the uEnv.txt from /media/BEAGLEBONE is used, so changes i uEnv.txt are not used.

After boot you can use the
echo BB-SPI0 > > /sys/devices/bone_capemgr.*/slots
to activate your dts overlay.

3

Aah - the -01- bit should have given me a hint that it was different. Thanks for the pointers.

I can now get a /dev device (though it’s created /dev/devspi1.0; I was expecting /dev/devspi0.0 - I assume that doesn’t really matter).

The only thing that doesn’t work is the uDev boot option. I’ve tried various different options, none of which are happy. Now what I also know is that I
must do
echo BB-SPI0-01 > /sys/devices/bone_capemgr./slots
to get it working, and /not/
echo BB-SPI0 > /sys/devices/bone_capemgr./slots

The latter actually still executes (despite me removing the files from /lib/firmware), but neither are happy on the uEnv.txt boot line. I assume there’s some kind of cache somewhere that’s getting things confused?

4

There;s been a discussion over that, apparently the emmc memory is a cape, and the SPIO dts is also a cape, but if the emmc memory is not loaded yet, the overlays from /lib/firmware (which do not reside in the kernel, because a lot of the ‘standard’ overlays do reside in the kernel) can not be loaded.

See: https://groups.google.com/d/msg/beagleboard/Iem_mHknIUM/MVoSG560SxEJ

5

Hi everyone,

I am runing Linux version 4.1.21-bone-rt-r20 from Robert Nelson repository and I have the same issue.
The DTS seems ok but the SPI module does’t appear under /dev/.
my uEnv.txt look like this:

`
uname_r=4.1.21-bone-rt-r20
optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
cape_enable=bone_capemgr.enable_partno=BB-SPI0-01

`
If I do cat $SLOTS I have :

`
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-SPI0-01

`

I have also attached my Kernel Config file and the bootloog.
Is Anyone to guide me how to solve this issue?

thanks,

config4.1.21-bone-rt-r20.txt (130 KB)

bootlog4.1.21.txt (25.8 KB)

6

I have also attached my Kernel Config file and the bootloog.
Is Anyone to guide me how to solve this issue?

I do believe that SPI has to be loaded earlier in the boot stage. I seem to recall this fix for this to be loading SPI from within the main board file.

7

Hello William,

do you mean to configure SPI in the am335x-boneblack-overlay.dts?
an set spi module to be set as built-in in the kernel?

Can you explain a bit? Isn’t clear for me.

8

Hello William,

do you mean to configure SPI in the am335x-boneblack-overlay.dts?
an set spi module to be set as built-in in the kernel?

Can you explain a bit? Isn’t clear for me

Yes, sorry I was not clearer, however I’ve not personal hands on, only remember Robert mentioning it before. However, if we search the board file for “SPI”, and include for something SPI _ dtsi should stand out. Let me see if I can find something quicly.

9

So, this is the file I remember seeing Robert talk about: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4.x/src/arm/am33xx-overlay-edma-fix.dtsi

Which if we look at this it’s already loaded . . . https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-boneblack-overlay.dts#L12

investigating further . . .

10

Ok, so are these modules loaded ?

william@beaglebone:~/dev$ lsmod | grep spi
spidev 7523 0
spi_omap2_mcspi 11148 0

I show . . .

william@beaglebone:~/dev$ ls /dev | grep spi
spidev1.0
spidev1.1
spidev2.0
spidev2.1

I am however using Charles’ universal IO, and loading univ-all at boot plus cape_universal=enabled in /boot/uEnv.txt. I am using a newer kernel version however . . .

william@beaglebone:~/dev$ uname -r
4.4.14-ti-r34

One thing you can check in /boot/uEnv.txt though is to make sure that this line:

cmdline=coherent_pool=1M quiet cape_universal=enable

is commented out. Or at east remove the cape_universal=enable part is removed.

11

I Will recompile the dtb from Robert git and flash the SD care. I Will keep my Kernel version since I have already use it for the PRU. I will let you know if this is work. I will also try to modify the uEnv.txt however I don't know if this will work with the 4.1.21 I am using.
Thanks William

12

I Will recompile the dtb from Robert git and flash the SD care. I Will keep my Kernel version since I have already use it for the PRU. I will let you know if this is work. I will also try to modify the uEnv.txt however I don’t know if this will work with the 4.1.21 I am using.
Thanks William

As far as the uEnv.txt file , and all that it’s going to be identical between 4.4.x, and 4.1.x. Or close to it. The problem is going to lay in drivers, implementations of drivers, and things of that nature.

13

Hello William,

I did realize that the spidev.ko and spi-omap2-mcspi.ko were missing in the /lib/modules/“uname-r”/kernel/drivers/spi/, so I have sent the two files via scp.
Then I have made sure that the module are loadable first manually and automatically, I use the insmod command.
so the modules were loaded under /dev/.
I wanted to load them automatically at boot by using the following command:
`
$ ln -s /lib/modules/4.1.21-bone-rt-r20/kernel/drivers/spi/spidev.ko /lib/modules/‘uname -r’$
$ depmod -a
$ sudo modprobe spidev

`

after reboot the driver spi was loaded.

Thanks for your help.