So, for everyone's who emailed me over the years, asking where is
capemanager, well it's time to test...
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-06-17
Notes:
echo "xyz" > /sys/devices/platform/bone_capemgr/slots
DOES NOT work..
Readme:
https://github.com/beagleboard/bb.org-overlays/blob/master/readme.md
Please take a look at /boot/uEnv.txt for configurations...
For "ANYTHING" that uses the eMMC/HDMI black pins on your cape, use:
dtb=am335x-boneblack-overlay.dtb
Current list of capes:
https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm
If you don't see your cape, please create a pull request against,
https://github.com/beagleboard/bb.org-overlays
Hints for cape porting from v3.8.x
3.8: &gpio[X] = 4.1: &gpio[X-1]
3.8: usart[X] = 4.1: usart[X-1]
Go Test!
Regards,
Downloaded the image. So where do I find the capes? For instance I want to enable BB–UART1. Where do I find this in the Image? Or should I git the overlay repository and compile https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART1-00A0.dts
(after getting the dtc compiler via /opt/scripts/tools/developers/dtc-overlay.sh)?
With the lxqt image's all those overlays are pre-built..
Just edit /boot/uEnv.txt and look for the v4.1. option and:
Change:
#cape_enable=bone_capemgr.enable_partno=
To:
cape_enable=bone_capemgr.enable_partno=BB-UART1
and reboot.
dmesg | grep cape
Regards,
Sorry, forgot to mention: the image I am using is bone-debian-console-armhf.
Apparently in these images the overlays are not available in /lib/firmware. I have to
do the stuff in https://github.com/beagleboard/bb.org-overlays,
so:
Sorry, forgot to mention: the image I am using is bone-debian-console-armhf.
Correct, with the console, no git by default, so the overlay repo
isn't installed..
cd ~
git pull GitHub - beagleboard/bb.org-overlays: Device Tree Overlays for bb.org boards
cd /opt/scripts/tools
git pull
sudo ./update_kernel.sh --beta-kernel
(the correct kernel is installed. 
)
cd ~/bb.org-overlays
./dtc-overlay.sh
./install.sh
Now I could add the BB-UART1 to uEnv.txt:
cape_enable=bone_capemgr.enable_partno=BB-UART1
and reboot.
Is there any way to enable an overlay while running?
Nope, doesn't 'work' at the moment..
Regards,
Robert:
Several questions about kernel 4.1
For kernel 3.14, you supported the dtb-rebuilder.
Are the universal-editable set of device tree source files that were
created for dtb-rebuilder branch 3.14 going to be brought forward
for 4.1?
I assume that when building “.dtb” files for 4.1-ti-, I should use the
4.1-ti branch of the dtb-rebuilder?
What is the difference between the 4.1-ti branch and the 4.1.x branch?
Can you say a few words about where the whole topic of device tree
management is headed on the BBB and BB-X15? What is likely to come next?
Thanks,
— Graham
Robert:
Several questions about kernel 4.1
For kernel 3.14, you supported the dtb-rebuilder.
Are the universal-editable set of device tree source files that were
created for dtb-rebuilder branch 3.14 going to be brought forward
for 4.1?
For one that don't work as a cape overlay, i'm planning to bring forward.
I assume that when building ".dtb" files for 4.1-ti-, I should use the
4.1-ti branch of the dtb-rebuilder?
What is the difference between the 4.1-ti branch and the 4.1.x branch?
For now, just use the "4.1.x" branch (aka mainline + overlays), while
the 4.1-ti branch will be tracking:
Can you say a few words about where the whole topic of device tree
management is headed on the BBB and BB-X15? What is likely to come next?
Hopefully, overlay's will finally go mainline.
But we will probably always have dtb-rebuilder, as it's so useful for
building clone designs.
Regards,
Robert:
OK, I have a overlay bug for you.
I have a SPI0 application, where I don’t want to use the CS0 output from the peripheral, but would rather bit bang the chip select line CS0 on the same pin as a GPIO. I have three SPI devices sharing the SPI bus, so I need to have three chip select lines, that are all GPIO lines, but the first one is P9.17. (The BBB does not pin out peripheral CS1 line, so you need to do something like this, anytime you have more than two SPI slaves.)
On kernel 3.14, all I had to do was comment out the appropriate lines regarding P9.17 in the “BB-SPIDEV0-00A0.dts” and the SPI interface would not claim the CS line, and I could then claim it as a GPIO and everything worked fine.
Under kernel 4.1, doing the same edit to the file and creating a “.dtbo”, even though I only reference the three core bus lines (clock, DI and DO) in the “.dts” the spi driver still claims all four lines, including the CS0, and I have a conflict on P9.17, so my GPIO “.dtbo” won’t load, and things go downhill from there.
The problem pin is P9.17, aka pin95, offset 0x17c.
Debian Image 2015-06-17
uname -a= Linux BBB2 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l
— Graham
A clarification. This worked as an overlay on 3.8, and worked as a dtb-rebuilder generated “.dtb” file on 3.14.
And you have to revert to bit banging the Chip Select lines via GPIO on the BBB any time you have more than one slave on the SPI bus.
— Graham