How to enable SPI devices on 3.14 kernel?

[Dallas Clement]

Hi All,

I am trying to enable both SPI devices in the 3.14 kernel for a beaglebone black.  I understand that the capemgr support is no longer there.  I need some tips on how to enable these devices in the kernel.  I don't care if it is done statically at kernel build time.  My application has no need to runtime enabling/disabling as is possible with capemgr and device tree overlays.

I see device tree source for spi0 but not spi1 in the 3.14 kernel source.

./arch/arm/boot/dts/am335x-bone-spi0-spidev.dtsi

Looks like SPI support is half-baked.  I am pulling my source from here:

https://github.com/beagleboard/linux.git

Am I going down the wrong path with 3.14?  Building from the 3.8 branch in this repo has compilation errors.

Thanks,

Dallas

[Robert Nelson]

Well, looks we have a volunteer.. Apply this on top of the latest 3.14
branch (i force pushed out an update about an hour ago)

Just enable either spi1/spi1a via:

#include "am335x-bone-spi1-spidev.dtsi"
(or)
#include "am335x-bone-spi1a-spidev.dtsi"

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Robert Nelson]

btw:

crap, forgot to update the spidev node names: if you have spi0-spidev
or the bottom am335x-bone-basic-proto-cape.dtsi enabled, you'll get
this error:

ERROR (duplicate_label): Duplicate label 'spidev0' on
/ocp/spi@481a0000/spi@0 and /ocp/spi@48030000/spi@0
ERROR (duplicate_label): Duplicate label 'spidev1' on
/ocp/spi@481a0000/spi@1 and /ocp/spi@48030000/spi@1
ERROR: Input tree has errors, aborting (use -f to force output)
Makefile:121: recipe for target 'src/arm/am335x-boneblack.dtb' failed
make[1]: *** [src/arm/am335x-boneblack.dtb] Error 2

This fixes that..

diff --git a/arch/arm/boot/dts/am335x-bone-spi1-spidev.dtsi
b/arch/arm/boot/dts/am335x-bone-spi1-spidev.dtsi
index 24013d8a6b..5bc03e8 100644
--- a/arch/arm/boot/dts/am335x-bone-spi1-spidev.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-spi1-spidev.dtsi
@@ -11,14 +11,14 @@
pinctrl-0 = <&spi1_pins>;
status = "okay";

- spidev0: spi@0 {
+ spidev2: spi@0 {
compatible = "spidev";
reg = <0>;
spi-max-frequency = <16000000>;
spi-cpha;
};

- spidev1: spi@1 {
+ spidev3: spi@1 {
compatible = "spidev";
reg = <1>;
spi-max-frequency = <16000000>;
diff --git a/arch/arm/boot/dts/am335x-bone-spi1a-spidev.dtsi
b/arch/arm/boot/dts/am335x-bone-spi1a-spidev.dtsi
index b2185dd..3aded7b 100644
--- a/arch/arm/boot/dts/am335x-bone-spi1a-spidev.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-spi1a-spidev.dtsi
@@ -11,14 +11,14 @@
pinctrl-0 = <&spi1a_pins>;
status = "okay";

- spidev0: spi@0 {
+ spidev2: spi@0 {
compatible = "spidev";
reg = <0>;
spi-max-frequency = <16000000>;
spi-cpha;
};

- spidev1: spi@1 {
+ spidev3: spi@1 {
compatible = "spidev";
reg = <1>;
spi-max-frequency = <16000000>;


you know.. half baked.. ;) Just got all the lcd's working today, spi1
hasn't been a priorty as i don't have a cape that uses it...

[Dallas Clement]

Hi Robert, many thanks for this.  How dost one actually enable the spi devices in 3.14?  I'm used to working with the overlays and capemgr, i.e. echoing to capemgr slots etc.

[Robert Nelson]

On Tue, Aug 26, 2014 at 10:25 PM, Dallas Clement
<dallas.a...@gmail.com> wrote:
> Hi Robert, many thanks for this. How dost one actually enable the spi
> devices in 3.14? I'm used to working with the overlays and capemgr, i.e.
> echoing to capemgr slots etc.

Well it's still in it's infancy.

Here's what works today:
http://elinux.org/Beagleboard:Capes_3.8_to_3.14

Take a look at the main am335x-boneblack.dts file:

https://github.com/beagleboard/linux/blob/3.14.17-ti-r15/arch/arm/boot/dts/am335x-boneblack.dts#L31

If you need usart1:

Just change:

/* #include "am335x-bone-ttyO1.dtsi" */

to:
#include "am335x-bone-ttyO1.dtsi"

and rebuild.

I'm working on a second repo, so that you don't have to rebuild the
kernel, just for dts changes:

https://github.com/RobertCNelson/dtb-rebuilder/tree/3.14-ti

Just issue "make all" and all *.dtb's will be rebuilt (these match the
full kernel tree (3.14.17-ti-r15)) above.

Haven't finished the "make install" so you still have to manually copy
the *.dtb's.

So, just make the *.dts change, rebuild, copy *.dtb, reboot, new
device enabled..

[Robert Nelson]

Okay just added the "make install"

Follow:
http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb

edit ./src/arm/am335x-boneblack.dts

To rebuild/install:

make
sudo make install

Then, reboot..

[Dallas Clement]

Wow!  Thanks for the quick response.  Will give it a shot.

[Dallas Clement]

Hi Robert, everything builds clean and I can see SPI0 after booting.  The devices are spi1.0 and spi1.1.  However, I'm not able to see any SPI1 devices.  Suspecting HDMI conflict, I set the status for the HDMI device to "disabled" in 

am335x-base0033.dts.  But that didn't seem to help.  Anything else you can think of that I should check?

Thanks,

Dallas

[Robert Nelson]

On Wed, Aug 27, 2014 at 8:59 PM, Dallas Clement
<dallas.a...@gmail.com> wrote:
> Hi Robert, everything builds clean and I can see SPI0 after booting. The
> devices are spi1.0 and spi1.1. However, I'm not able to see any SPI1
> devices. Suspecting HDMI conflict, I set the status for the HDMI device to
> "disabled" in
> am335x-base0033.dts. But that didn't seem to help. Anything else you can
> think of that I should check?

Okay, i should probally remove all non "bb.org" boards.. am335x-base0033.dts

am335x-base0033.dts - Device Tree file for IGEP AQUILA EXPANSION

The only two you should touch:

am335x-bone.dts (BeagleBone White)
am335x-boneblack.dts (BeagleBone Black)

If you want to pastebin.com your current *.dts I'll look at it..

[Robert Nelson]

btw, i added some more notes to:

http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb

This feedback always helps us tune the wiki for the next new user..

[Dallas Clement]

I just pasted my am335x-boneblack.dts to   http://pastebin.com/PwccRatb

[Robert Nelson]

On Wed, Aug 27, 2014 at 9:41 PM, Dallas Clement
<dallas.a...@gmail.com> wrote:
> I just pasted my am335x-boneblack.dts to http://pastebin.com/PwccRatb

Here you go:

http://pastebin.com/rSg1h46h

(just disabled the last line, proto-cape, as it'll inerfear)

[Dallas Clement]

You're my hero! :)  Working like a champ now!  Thanks a million.

[Jason Lange]

Hello Robert,

I've just tried to duplicate your instructions here to get both spidev 0 and 1 using your dts from the pastebin link above and I am only getting /dev/spidev1.0 and /dev/spidev1.1 -- no spidev0.N or spidev2.N

uname -a:

Linux SQR-3 3.14.17-ti-r16 #1 SMP Thu Aug 28 23:18:48 UTC 2014 armv7l GNU/Linux

I just updated from 3.8 using your latest install-me.sh from rcn-ee.org

and did:

git clone -b 3.14-ti https://github.com/RobertCNelson/dtb-rebuilder.git

make and make install did not complain but no joy.

[Robert Nelson]

On Fri, Aug 29, 2014 at 12:20 PM, Jason Lange <j.b....@gmail.com> wrote:
> Hello Robert,
>
> I've just tried to duplicate your instructions here to get both spidev 0 and
> 1 using your dts from the pastebin link above and I am only getting
> /dev/spidev1.0 and /dev/spidev1.1 -- no spidev0.N or spidev2.N
>
> uname -a:
>
> Linux SQR-3 3.14.17-ti-r16 #1 SMP Thu Aug 28 23:18:48 UTC 2014 armv7l
> GNU/Linux
>
> I just updated from 3.8 using your latest install-me.sh from rcn-ee.org
>
> and did:
>
> git clone -b 3.14-ti https://github.com/RobertCNelson/dtb-rebuilder.git
>
> make and make install did not complain but no joy.

/dev/spidev1.[0/1] is enabled by:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack.dts#L102

as that enables:
#include "am335x-bone-spi0-spidev.dtsi"

For /dev/spidev2.[0/1] you have two choices:

Uncomment:
https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack.dts#L43

or
https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack.dts#L50

then make/sudo make install/sudo reboot

[Robert Nelson]

2nd thought, the uart conflicts..
so disable:

#include "am335x-bone-basic-proto-cape.dtsi"
->
/* #include "am335x-bone-basic-proto-cape.dtsi" */

Then add spi0:
#include "am335x-bone-spi0-spidev.dtsi"

Then spi1:
#include "am335x-bone-spi1-spidev.dtsi"
or
#include "am335x-bone-spi1a-spidev.dtsi"

[Jason Lange]

Hello Robert,

I had done just as you've described, but the system I started with had uboot and company installed in /boot/uboot rather than /boot and your 'make install' in ../dtb-rebuilder.git didn't seem to be touching /boot/uboot. I guessed that that was why I wasn't seeing the changes I was hoping for ( that is: /dev/spidev2.[0/1] ) so i tried completing the install for my setup by moving files into /boot/uboot/dtbs and bricked my board.

This morning I began with:

https://rcn-ee.net/deb/testing/2014-08-19/lxde/BBB-eMMC-flasher-debian-7.6-lxde-armhf-2014-08-19-2gb.img.xz

flashed my bone...

did:

apt-get install linux-image-3.14.17-ti-r16

then:

git clone -b 3.14-ti https://github.com/RobertCNelson/dtb-rebuilder.git

then changed ../dtb-rebuilder.git/src/arm/am335x-boneblack.dts following your guidelines below:

2nd thought, the uart conflicts..
so disable:

#include "am335x-bone-basic-proto-cape.dtsi"
->
/* #include "am335x-bone-basic-proto-cape.dtsi" */

Then add spi0:
#include "am335x-bone-spi0-spidev.dtsi"

Then spi1:
#include "am335x-bone-spi1-spidev.dtsi"
or
#include "am335x-bone-spi1a-spidev.dtsi"

then make/sudo make install/sudo reboot

The system this gives me has everything in /boot and nothing in /boot/uboot and 'make install' does what it is supposed to, and sure enough after reboot:

ls /dev/spidev*

gives me:

/dev/spidev1.0  /dev/spidev1.1  /dev/spidev2.0  /dev/spidev2.1

Thanks for the time and the tools.

[William Hermans]

Jason,

/boot/uboot should have been nothing more than a mount point for /dev/mmcblk0p1. Which is the fat16 formatted partition that u-boot.img, MLO, and uEnv.txt reside.

/boot/uEnv.txt should be nothing more than . ..

root@arm:~# cat /boot/uEnv.txt
uname_r=3.8.13-bone64.1
cmdline=quiet init=/lib/systemd/systemd
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

Or something similar.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Tue, Sep 2, 2014 at 6:15 PM, William Hermans <yyr...@gmail.com> wrote:
> Jason,
>
> /boot/uboot should have been nothing more than a mount point for
> /dev/mmcblk0p1. Which is the fat16 formatted partition that u-boot.img, MLO,
> and uEnv.txt reside.

How would you guys feel about nuking that fat16 "boot" partition. ;)

[William Hermans]

How would you guys feel about nuking that fat16 "boot" partition. ;)

Quite honestly Robert. It's been around since I first got my A5A last year, so I'm used to it. But I suppose having one partition formatted as ext2/3/4 would be more convenient

[Robert Nelson]

On Tue, Sep 2, 2014 at 5:33 PM, Jason Lange <j.b....@gmail.com> wrote:
> Hello Robert,
>
> I had done just as you've described, but the system I started with had uboot
> and company installed in /boot/uboot rather than /boot and your 'make
> install' in ../dtb-rebuilder.git didn't seem to be touching /boot/uboot. I
> guessed that that was why I wasn't seeing the changes I was hoping for (
> that is: /dev/spidev2.[0/1] ) so i tried completing the install for my setup
> by moving files into /boot/uboot/dtbs and bricked my board.

Sorry about that, i need to add backwards compatibility to that script.

I promise i only have one more earth shaking change coming down the pipe.

[Robert Nelson]

On Tue, Sep 2, 2014 at 6:45 PM, William Hermans <yyr...@gmail.com> wrote:
>> How would you guys feel about nuking that fat16 "boot" partition. ;)
>
>
> Quite honestly Robert. It's been around since I first got my A5A last year,
> so I'm used to it. But I suppose having one partition formatted as ext2/3/4
> would be more convenient

done ;)

dd if=MLO of=/dev/sdX count=1 seek=1 conv=notrunc bs=128k
dd if=u-boot.img of=/dev/sdX count=2 seek=1 conv=notrunc bs=384k

only works on omap4+ bootrom's (so the old omap34xx/omap36xx family is out)

I'm close to rolling out a new testing image that uses this feature..
The flasher gets more interesting as i need to remember to include the
MLO/u-boot.img somewhere in the ext4 partition for later flashing..

[William Hermans]

done ;)

dd if=MLO of=/dev/sdX count=1 seek=1 conv=notrunc bs=128k
dd if=u-boot.img of=/dev/sdX count=2 seek=1 conv=notrunc bs=384k

only works on omap4+ bootrom's (so the old omap34xx/omap36xx family is out)

I'm close to rolling out a new testing image that uses this feature..
The flasher gets more interesting as i need to remember to include the
MLO/u-boot.img somewhere in the ext4 partition for later flashing..

Wait a minute, is this creating two partitions that are raw contents of each file ? Not sure what this is doing actually seems more like you're dumping the raw content of each file onto the same partition. But I've actually never seen dd used this way.

[William Hermans]

OK, so I think I got that figured out. Was not familiar with "seek", but am now. So what about uEnv.txt ?

[Robert Nelson]

On Tue, Sep 2, 2014 at 6:57 PM, William Hermans <yyr...@gmail.com> wrote:

OK, so I think I got that figured out. Was not familiar with "seek", but am now. So what about uEnv.txt ?

/boot/uEnv.txt can be in any partition ( /dev/mmcblkXp1 -> /dev/mmcblkXp7* )

7: is the usual max enabled by default for most normal mmc host controllers in linux.

Regards,

[William Hermans]

/boot/uEnv.txt can be in any partition ( /dev/mmcblkXp1 -> /dev/mmcblkXp7* )

7: is the usual max enabled by default for most normal mmc host controllers in linux.

Regards,

Right, I get that, but in the case of NFS rootfs, how is uboot supposed to know to look over an NFS share ?

Right now, we have the main uEnv.txt file that resides where uboot.img, and MLO reside. This points to yet another( optional ? ) uEnv.txt for loading possibly common setenv variables. Will this just be hard coded to search /boot, no matter it's location ?

--

[William Hermans]

Oh, and nearly forgot for the fifth time heh. What about g_multi file "share" ? The one that gets auto mounted on Windows machines. I do not use this myself, but I'm sure there are people out there who do use it.

[Robert Nelson]

On Tue, Sep 2, 2014 at 8:22 PM, William Hermans <yyr...@gmail.com> wrote:
>> /boot/uEnv.txt can be in any partition ( /dev/mmcblkXp1 -> /dev/mmcblkXp7*
>> )
>>
>> 7: is the usual max enabled by default for most normal mmc host
>> controllers in linux.
>>
> Regards,
>
> Right, I get that, but in the case of NFS rootfs, how is uboot supposed to
> know to look over an NFS share ?
>
> Right now, we have the main uEnv.txt file that resides where uboot.img, and
> MLO reside. This points to yet another( optional ? ) uEnv.txt for loading
> possibly common setenv variables. Will this just be hard coded to search
> /boot, no matter it's location ?

So as of right now, it'll search for these files in this order:

(microSD)

Partition: 1 (fat/extX)
/uEnv.txt
/boot.scr
/boot/boot.scr

Then it'll loop thru partition's: 1 -> 7:
/boot/uEnv.txt

(eMMC)

Partition: 1 (fat/extX)
/uEnv.txt
/boot.scr
/boot/boot.scr

Then it'll loop thru partition's: 1 -> 7:
/boot/uEnv.txt

I've left the logic for the first partition for compatibility sake.

[Robert Nelson]

On Tue, Sep 2, 2014 at 8:23 PM, William Hermans <yyr...@gmail.com> wrote:
> Oh, and nearly forgot for the fifth time heh. What about g_multi file
> "share" ? The one that gets auto mounted on Windows machines. I do not use
> this myself, but I'm sure there are people out there who do use it.

That's why we've been moving every "critical" file out of that partition.

For the official lxde image, the fat partition will still be there,
but NO critical boot files will exist in. (a windows user can add a
'uEnv.txt/boot.scr/boot/boot.scr' and it will change the boot..

"In" theory, windows users should be able to re-format the drive too,
when it's shown in windows over the usb-gadget connection.

[William Hermans]

That's why we've been moving every "critical" file out of that partition.

For the official lxde image, the fat partition will still be there,
but NO critical boot files will exist in. (a windows user can add a
'uEnv.txt/boot.scr/boot/boot.

scr' and it will change the boot..

"In" theory, windows users should be able to re-format the drive too,
when it's shown in windows over the usb-gadget connection.

It is kind of sad that this is even necessary. In the context that the BBB is a dev board, and as such *some* knowledge / common sense should be implied.

[Robert Nelson]

On Tue, Sep 2, 2014 at 8:58 PM, William Hermans <yyr...@gmail.com> wrote:

That's why we've been moving every "critical" file out of that partition.

For the official lxde image, the fat partition will still be there,
but NO critical boot files will exist in. (a windows user can add a
'uEnv.txt/boot.scr/boot/boot.

scr' and it will change the boot..

"In" theory, windows users should be able to re-format the drive too,
when it's shown in windows over the usb-gadget connection.

It is kind of sad that this is even necessary. In the context that the BBB is a dev board, and as such *some* knowledge / common sense should be implied.

It keeps things interesting. ;)  It Feels like bullet proofing the perfect mouse trap!

Regards,

[William Hermans]

heh whatever you like Jason. Simply using lsblk, and mount should make things crystal clear.

On Wed, Sep 3, 2014 at 2:57 PM, Jason Lange <j.b....@gmail.com> wrote:

On Tuesday, 2 September 2014 16:15:58 UTC-7, William Hermans wrote:

Jason,

/boot/uboot should have been nothing more than a mount point for /dev/mmcblk0p1. Which is the fat16 formatted partition that u-boot.img, MLO, and uEnv.txt reside.

For a while the fat16 partition was mounted at /boot/uboot  so that the kinds of things that frequently go in boot like different kernel images could be kept there without filling up the tiny FAT16 partition (similar to /boot/efi).

The factory images from May which are labeled "BeagleBoard.org Latest Firmware Images" are that way.  From /etc/fstab:  "/dev/mmcblk0p1  /boot/uboot  auto  defaults    0  0".

Scripts that manipulate /boot should take this possibility into account.

[Jason Lange]

On Friday, 29 August 2014 10:37:09 UTC-7, RobertCNelson wrote:

2nd thought, the uart conflicts..
so disable:

#include "am335x-bone-basic-proto-cape.dtsi"
->
/* #include "am335x-bone-basic-proto-cape.dtsi" */

Then add spi0:
#include "am335x-bone-spi0-spidev.dtsi"

Then spi1:
#include "am335x-bone-spi1-spidev.dtsi"
or
#include "am335x-bone-spi1a-spidev.dtsi"

then make/sudo make install/sudo reboot

 

..I think I should add this for completion

Also do:

#include "am335x-boneblack-nxp-hdmi-audio.dtsi"

to:

/*#include "am335x-boneblack-nxp-hdmi-audio.dtsi"*/

and if you want hdmi do:

/* #include "am335x-boneblack-nxp-hdmi-no-audio.dtsi"*/

to:

 #include "am335x-boneblack-nxp-hdmi-no-audio.dtsi"

[Dallas Clement]

Hey Robert, I know this thread is getting long in the tooth.  Originally I had asked for help on enabling the SPI devices on the 3.14 kernel.  You got me past that with some patches.  However, I just did a merge from the latest upstream and now my SPI devices are not enabled any more when I boot the kernel.  This is what I have on the command line:

capemgr.enable_partno=BB-SPIDEV0,BB-SPIDEV1

Do these parts have different names now?

Thanks,

Dallas

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/_qhb4wumgpU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Dallas Clement]

I got it figured out.  The SPI dev include dtsi were commented out after my merge.  I guess the default state is SPI devices disabled.

[Drew Fustini]

On Friday, August 29, 2014 at 12:35:19 PM UTC-5, RobertCNelson wrote:

all did not complain but no joy.

/dev/spidev1.[0/1] is enabled by:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack.dts#L102

as that enables:
#include "am335x-bone-spi0-spidev.dtsi"

I'd like to use SPI1 with 4.1 kenrel.  I didn't see a similar line in:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1.x/src/arm/am335x-bone.dts

Is there another approach for 4.1?

thanks,
drew

[Robert Nelson]

Hey Drew,

Do you want to test the 4.1 spi overlays?? ;)

if so do this:


sudo apt-get update
sudo apt-get install linux-image-4.1.0-rc6-bone6
sudo reboot

overlays:

git clone https://github.com/beagleboard/bb.org-overlays
cd bb.org-overlays

update dtc (only for 4.1.x + (breaks 3.8.x))

./dtc-overlay.sh

build/install overlays:

./install.sh

add overlays via: /boot/uEnv.txt

bone_capemgr.enable_partno=BB-SPIDEV0

(notice the name changed from "capemgr" -> "bone_capemgr" so update
the example in /boot/uEnv.txt

Future images have both listed..


Regards,

--
Robert Nelson
https://rcn-ee.com/

[Drew Fustini]

Thanks for the quick response! I will give it a try this weekend.

My goal is to get 1.8" Adafruit TFT working with 4.1's staging/ftbtft.
Matt Porter's old post had it wired up on SPI1:
http://engineersofthecorn.blogspot.com/2012/06/beaglebone-and-adafruit-18-spi-lcd.html

> --
> For more options, visit http://beagleboard.org/discuss
> ---

> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Drew Fustini]

On Fri, Jun 5, 2015 at 2:14 PM, Drew Fustini <pdp7...@gmail.com> wrote:
> My goal is to get 1.8" Adafruit TFT working with 4.1's staging/ftbtft.

oops, I meant fbtft. This is the driver:
https://github.com/torvalds/linux/blob/master/drivers/staging/fbtft/fb_st7735r.c

[Drew Fustini]

On Fri, Jun 5, 2015 at 2:01 PM, Robert Nelson <robert...@gmail.com> wrote:

> Do you want to test the 4.1 spi overlays?? ;)

thanks, that did work for me. although the uEnv.txt settings seemed
to have no effect. I had to echo the cape name into slots:

root@beaglebone:/# uname -a
Linux beaglebone 4.1.0-rc6-bone6 #1 Mon Jun 1 22:44:52 UTC 2015 armv7l GNU/Linux

root@beaglebone:/# cat /sys/devices/platform/bone_capemgr/slots
0: 54:PF---- -1
1: 55:PF---- -1
2: 56:PF---- -1
3: 57:PF---- -1

root@beaglebone:/# cat /boot/uEnv.txt |egrep -v '^(#|$)'
uname_r=4.1.0-rc6-bone6
cmdline=quiet init=/lib/systemd/systemd
bone_capemgr.enable_partno=BB-SPIDEV0
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

root@beaglebone:/# echo 'BB-SPIDEV0' > /sys/devices/platform/bone_capemgr/slots

root@beaglebone:/# cat /sys/devices/platform/bone_capemgr/slots
0: 54:PF---- -1
1: 55:PF---- -1
2: 56:PF---- -1
3: 57:PF---- -1
4: ff:P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-SPIDEV0

root@beaglebone:/# ls -la /dev/spi*
crw-rw---T 1 root spi 153, 1 Jun 7 21:03 /dev/spidev1.0
crw-rw---T 1 root spi 153, 0 Jun 7 21:03 /dev/spidev1.1

Here is additional output:
https://gist.github.com/pdp7/14a813bd3254254b94fe


thanks,
drew

[William Hermans]

root@beaglebone:/# cat /boot/uEnv.txt |egrep -v '^(#|$)'
uname_r=4.1.0-rc6-bone6
cmdline=quiet init=/lib/systemd/systemd
bone_capemgr.enable_partno=BB-SPIDEV0
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G

cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0

[William Hermans]

"cape_enable" is a variable that places the following text into the Linux boot time parameters.

If you ...

debian@beaglebone:~$ cat /proc/cmdline
console=tty0 console=ttyO0,115200n8 beaglebone-capemgr.enable_partno=BB-CAN1 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait fixrtc

You most likely will see that your uEnv.txt modification did not "stick.

[Drew Fustini]

On Sun, Jun 7, 2015 at 5:46 PM, William Hermans <yyr...@gmail.com> wrote:
> cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0

thanks!

[Drew Fustini]

On Fri, Jun 5, 2015 at 2:01 PM, Robert Nelson <robert...@gmail.com> wrote:

> sudo apt-get install linux-image-4.1.0-rc6-bone6

I want to compile modules in drivers/staging/fbtft.

How can I get the source for 4.1.0-rc6-bone6?

I don't see a tag for it in:
https://github.com/RobertCNelson/linux-dev

I did compile the capemgr branch:
4.1.0-rc6-capemgr-r13-00154-g37ef164

But it doesn't seem the capemgr exists when booting that kernel:

# cat /sys/devices/platform/bone_capemgr/slots
cat: /sys/devices/platform/bone_capemgr/slots: No such file or directory

thanks,
drew

[William Hermans]

I do not think you can build *bone6 per se. Unless Robert gives you exact steps, but  there is this.

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel

Which if I'm not mistaken Roberts scripts should pull in all the latest patches. Perhaps you can dissect the scripts and figure out whats going on. Or wait until tomorrow for Robert to reply.

[William Hermans]

Drew, Oh hey did you check this out ? https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md

Specifically

Kernel with CONFIG_BONE_CAPEMGR support:

zcat /proc/config.gz | grep CONFIG_BONE_CAPEMGR
CONFIG_BONE_CAPEMGR=y

[Robert Nelson]

It's all in the bb-kernel repo now..

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.1

no longer just experimental, but all merged in our 4.1.x branch, so
there's no turning back!!! ;)

[Drew Fustini]

On Sun, Jun 7, 2015 at 9:13 PM, William Hermans <yyr...@gmail.com> wrote:
> CONFIG_BONE_CAPEMGR=y

thanks, good point!

[Drew Fustini]

On Sun, Jun 7, 2015 at 9:37 PM, Robert Nelson <robert...@gmail.com> wrote:
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.1

thanks, cloning it now and will do a build.

[Drew Fustini]

On Sun, Jun 7, 2015 at 9:37 PM, Robert Nelson <robert...@gmail.com> wrote:
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.1

thanks, boots and loads the SPI1 cape:

root@beaglebone:~# uname -a
Linux beaglebone 4.1.0-rc6-bone6.6-00066-g75ea467 #1 Sun Jun 7
23:18:32 CDT 2015 armv7l GNU/Linux

root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots

0: 54:PF---- -1
1: 55:PF---- -1
2: 56:PF---- -1
3: 57:PF---- -1

4: ff:P-O-L- 0 Override Board Name,00A0,Override Manuf,BB-SPIDEV1

root@beaglebone:~# ls -la /dev/spidev1.*
crw-rw---T 1 root spi 153, 1 Mar 1 20:46 /dev/spidev1.0
crw-rw---T 1 root spi 153, 0 Mar 1 20:46 /dev/spidev1.1


I'm still trying to work out how to use fbtft in 4.1. this is where
I've gotten so far:

root@beaglebone:~# modprobe fbtft_device name=adafruit22

[ 1310.480992] fbtft: module is from the staging directory, the
quality is unknown, you have been warned.
[ 1310.494031] fbtft_device: module is from the staging directory, the
quality is unknown, you have been warned.
[ 1310.499966] fbtft_device: SPI devices registered:
[ 1310.500017] fbtft_device: spidev spi1.1 16000kHz 8 bits mode=0x00
[ 1310.500044] fbtft_device: spidev spi1.0 16000kHz 8 bits mode=0x01
[ 1310.500061] fbtft_device: 'fb' Platform devices registered:
[ 1310.500215] fbtft_device: spi_busnum_to_master(0) returned NULL
[ 1310.506730] fbtft_device: failed to register SPI device


thanks,
drew

[William Hermans]

https://github.com/notro/fbtft/issues/49

Perhaps related, but according to what they're saying spi_busnum_to_master(0) returned NULL == invalid argument. Which means perhaps the SPI bus driver is blacklisted ?

Good luck.

[Dallas Clement]

Hi Everyone.  I'm trying to get the SPI devices working in the 4.1 kernel, but I don't really want to use the cape manager / overlays.  I don't see any dtsi files for the SPI devices in the 4.1 source.  The am335x-bone-spi0-spidev.dtsi and am335x-bone-spi1-spidev.dtsi are missing.  I had experienced similar issues in the early days of the 3.14 kernel.  Perhaps these files need to be updated for the 4.1 kernel?

[jeys...@gmail.com]

Robert,
I followed these steps and got it changed to the version  4.1.0-rc6-bone6. Modified the /boot/uEnv.txt etc. I also see the file /lib/firmware/BB-SPIDEV0-00A0.dtbo etc. I however, do not see the file /sys/devices/bone_capemgr*. Hence, I also don't see /dev/spi*. I am using the BBB, and not the Beaglebone White.
Any idea, why the bone_capemgr* is not running? I am trying to enable the SPI0, so that I can talk to my own cape via SPI0.

Thx
jey