I'm trying to utilise some spare GPIO pins from the BBB for soft SPI to control my APA102 LED strip in a bit banging fashion.
My project constraints require the use of the Analog I/O and as I understand I can't use the HW SPI0 and Analog I/O at the same time on BBB. Additionally I can see what I believe is soft SPI setup for CTAG via the /lib/firmware/BB-BELA-CTAG-SPI-00A0.dtbo overlay which I used to seed my soft SPI attempts.
I'm using a rev B5 board and Bela v0.5.0alpha2. I'm attempting to use P8.39 and P8.40 (after referring to the P8 pin outs) as I only need CLK and MOSI. I want to try use the cAPA102 lib as mentioned in https://forum.bela.io/d/1284-capa102-not-working, which I found here: https://github.com/CoorFun/cAPA102/blob/master/README.md -- it appears to use /dev/spidevX.X under the hood.
So far I've had no success loading ANY device tree overlays other than the defaults for BBB. Each time my Bela goes into a reboot cycle and powers down, at which point I restore the uEnv.txt and try again. I've tried following the instructions to enable config-pin usage via /lib/firmware/cape-universalh-00A0.dtbo, I cloned the repo and ran make all install which appeared to copy successfully, and changing my uEnv.txt having universalh being the only overlay, being the first and being the last. All failed to boot. I'm not quite sure what the debugging procedure is for the overlays from boot.
As for the spare GPIO pins, I've gone and created an overlay that compiles successfully:
/*
* Copyright (C) 2017 Henrik Langer henni19790@googlemail.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green";
/* identification */
part-number = "BELA-DOTSTAR";
version = "00A0", "A0";
/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P8.39", /* spi_sclk */
"P8.40", /* spi_mosi */
/* the hardware ip uses */
"spi_gpio";
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
bb_spi_gpio_pins: pinmux_bb_spi_gpio_pins {
pinctrl-single,pins = <
0x0B8 0x37 /* spi_sclk, MODE7 | INPUT_PULLUP | SPI_SCLK P8_39 */
0x0BC 0x17 /* spi_mosi, MODE7 | OUTPUT_PULLUP | SPI_MOSI P8_40 */
>;
};
};
};
fragment@1 {
target = <&spi_gpio>;
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bb_spi_gpio_pins>;
channel@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "spidev";
reg = <0>;
spi-max-frequency = <100000>;
};
channel@1 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "spidev";
reg = <1>;
spi-max-frequency = <100000>;
};
};
};
};I don't quite understand why the need for 2 channels, and may be a hangover from copy&paste of the CTAG overlay. I haven't found any decent docs for the spi_gpio fragment (https://www.kernel.org/doc/Documentation/devicetree/bindings/spi/spi-gpio.yaml -- best I could find).
I then compile the above overlay with $ dtc -O dtb -o BELA-DOTSTAR-00A0.dtbo -b 0 -@ BELA-DOTSTAR-00A0.dts and move it to /lib/firmware, finally updating the uEnv.txt:
uenvcmd=echo loading ${fdtfile}; load mmc ${mmcid}:2 ${fdtaddr} boot/dtbs/${uname_r}/${fdtfile}; if env exists uboot_overlay_addr0; then setenv overlay ${uboot_overlay_addr0}; run bela_loadoverlay; fi; if env exists uboot_overlay_addr1; then setenv overlay ${uboot_overlay_addr1}; run bela_loadoverlay; fi; if env exists uboot_overlay_addr2; then setenv overlay ${uboot_overlay_addr2}; run bela_loadoverlay; fi; if env exists uboot_overlay_addr3; then setenv overlay ${uboot_overlay_addr3}; run bela_loadoverlay; fi; if env exists uboot_overlay_addr4; then setenv overlay ${uboot_overlay_addr4}; run bela_loadoverlay; fi; if env exists uboot_overlay_addr5; then setenv overlay ${uboot_overlay_addr5}; run bela_loadoverlay; fi; if env exists uboot_overlay_addr6; then setenv overlay ${uboot_overlay_addr6}; run bela_loadoverlay; fi; if env exists uboot_overlay_addr7; then setenv overlay ${uboot_overlay_addr7}; run bela_loadoverlay; fi; load mmc ${mmcid}:2 ${loadaddr} /boot/vmlinuz-${uname_r}; setenv bootargs console=${console} root=/dev/mmcblk${mmcid}p2 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet; bootz ${loadaddr} - ${fdtaddr};
bela_loadoverlay=echo loading ${overlay}; load mmc ${mmcid}:2 ${rdaddr} ${overlay}; fdt addr $fdtaddr; fdt resize 0x60000; fdt apply ${rdaddr}; fdt resize 0x60000;
uboot_overlay_addr2=/lib/firmware/BB-BELA-00A1.dtbo
uboot_overlay_addr3=/lib/firmware/BB-BELA-CTAG-SPI-00A0.dtbo
uboot_overlay_addr4=/lib/firmware/BB-BELA-DOTSTAR-00A0.dtbo
console=ttyS0,115200n8
uname_r=4.14.108-ti-xenomai-r143
mmcid=0As mentioned above my Bela gets stuck in a reboot cycle and eventually powers down. I've also tried it as the only overlay and the first.
I noticed else where that BBB are deprecating /slots which adds up with why I can't find it to manually try load my overlay at runtime to check dmesg. Any help most appreciated!
