Infinetix has designed a SmartMesh IP™ Gateway system utilizing a BeagleBone Black (BBB) single board computer and a custom designed add-on board (known as a cape in BeagleBone nomenclature) built around the Linear Technology’s SmartMesh IP™ technology
In the BeagleBone Black ecosystem, each cape needs a means to determine pin definition and usage. This is done using a device tree methodology (reference 1, reference 2). The purpose of this post is to walk through the steps taken to get the Infinetix SmartMesh cape device tree properly defined and operational.
Starting Point
Hardware: The two boards used in this discussion are the BeagleBone Black, Rev C (BBB) and the Infinetix SmartMesh IP Gateway cape, Rev B.
The two boards (unstacked) are shown below.
Operating System: Ubuntu 14.04 was used for this project, running off of the BBB micro SD card. The steps to install the OS are described next. For the latest information on Ubuntu revisions and getting them running on a BeagleBone Black, check out reference 3.
- Get a pre-configured (prebuilt) image. This example is for the 2015-0219 version of Ubuntu 14.04, Trusty Tahr, for the BeagleBone Black.
wget https://rcn-ee.net/rootfs/2015-02-19/ubuntu-14.04.2-console-armhf-2015-02-19.tar.xz
- Use the md5sum function to verify the image. The md5sum result will change depending on the version downloaded.
md5sum ubuntu-14.04.2-console-armhf-2015-02-19.tar.xz 2621ee08f9476534df01a4d6013e6f7d ubuntu-14.04.2-console-armhf-2015-02-19.tar.xz
- Untar the image
tar xf ubuntu-14.04.2-console-armhf-2015-02-19.tar.xz
- Copy the image to the SD card using the setup script included in the download. Note that /dev/mmcblk0 is the location of the SD card for this example. Your card may be at a different location. See reference 3 for information on how to determine your SD card location.
cd ubuntu-14.04-console-armhf-2015-02-19/ sudo ./setup_sdcard.sh --mmc /dev/mmcblk0 --dtb beaglebone
- A clean-up item: At the time these notes were put together, the build script generated a file named bbb-uEnv.txt, while the bootloader (U-Boot) looks for a file named uEnv.txt. Copying and renaming the bbb-uEnv.txt file to uEnv.txt (at the /boot directory level) caused the SD card boot to be successful.
Device Tree source
As discussed in reference 4, the device tree overlay describes the pin usage for a specific cape.
For this cape design, the pins are mostly associated with UART communication between the BBB and the SmartMesh IP network manager. There are two UARTs: one for the command line interface (CLI) and one for the application programming interface (API). (See the Linear Technology API and CLI guides for more information on these interfaces). Standard flow control is not utilized for these UARTs, but the pins were called out and reserved for potential future use. The API UART transmit CTS line is pulled low as a standard GPIO definition to communicate always ready for data to the network manager. This step was required to make the Linear Technology DustLink demonstration software operate.
Besides the UARTs, the other pins specific for this cape design are a reset for the SmartMesh IP manager and a test pin for general GPIO operation.
There are many documents available for how the pins are multiplexed and set up for operation. This reference 5 was one of the ones I found to be particularly useful.
Shown next is the actual device tree source (dts) file that defines the pin usage for the SmartMesh IP Gateway cape. Refer to the comments in the dts file below for more specifics on the pin set up and control. Using the gpio-of-helper driver as shown in fragment@3 was the key to having the GPIO pins properly exported and set by the kernel.
/*
* Copyright (C) 2015 Infinetix Corp
*
* Filename: SmartMeshGateway-00B0.dts
*
* 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.
*
* This is a device tree overlay file for Infinetix SmartMesh(R) Gateway Beaglebone Black Cape.
* This code initializes UART1, UART4, and various GPIOs for command and control associated
* with the on-board Linear Technology SmartMesh Network Manager module.
*
* 2015-0313 DRS
*/
/dts-v1/;
/plugin/;
/{
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "SmartMeshGateway";
version = "00B0";
/* State resources this cape uses */
exclusive-use =
/* the pin header and pins used */
"P9.11", /* UART4 RXD */
"P9.13", /* UART4 TXD */
"P9.24", /* UART1 TXD */
"P9.26", /* UART1 RXD */
"P9.12", /* GPIO1_28: UART_TX_CTSn- Driven low to communicate always ready for data */
"P9.15", /* GPIO1_16: UART_TX_RTSn- Set up as input but not used. **Reserved** */
"P9.23", /* GPIO1_17: UART_RX_CTSn- Set up as input but not used. **Reserved** */
"P9.25", /* GPIO3_21: UART_RX_RTSn- Set up as input but not used. **Reserved** */
"P9.27", /* GPIO3_19: MOTE_RESET- Active high. Initialized to low */
"P9.42", /* GPIO0_7: TP13- Driven high as a GPIO test signal. Could be reclaimed */
/* the hardware IP uses */
"uart4",
"uart1";
/* Pinmux Fragments */
/*
* General form for Pad Control register (reference AM3358 Technical Reference Manual)
* Bits 31-7 reserved. Read returns 0
* Bit 6: Slew Control: 0- Fast, 1- Slow
* Bit 5: Rx Active. Input enable value for the pad. Set to 0 for output only.
* Set to 1 for input or output: 0- Receiver disabled, 1- receiver enabled
* Bit 4: Pullup/pulldown type selection: 0- pulldown selected, 1- pullup selected
* Bit 3: Pullup/pulldown enable: 0- pullup/down enabled, 1- pullup/down disabled
* Bits 2-0: Pad functional signal mux select: 0 through 7 to select multiplexer mode used
*
* The pin control address (also called muxRegOffset in some documents) came from:
* https://github.com/bradfa/beaglebone_pinmux_tables
* Another useful reference is:
* ./KERNEL/firmware/capes/cape-universal-00A0.dts
*/
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
/* Configure UART1 */
uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
0x184 0x00 /* P9_24 = uart1_txd.uart1_txd, OUTPUT Mode0 */
0x180 0x20 /* P9_26 = uart1_rxd.uart1_rxd, INPUT Mode0 */
>;
};
/* Configure UART4 */
uart4_pins: pinmux_uart4_pins {
pinctrl-single,pins = <
0x074 0x06 /* P9_13 = gpmc_wpn.uart4_txd_mux2, OUTPUT Mode6 */
0x070 0x26 /* P9_11 = gpmc_wait0.uart4_rxd_mux2, INPUT Mode6 */
>;
};
/* Configure GPIO */
/* All set to Slew control: Fast, Pullup/Pulldown: Enabled */
gpio_pins: pinmux_gpio_pins{
pinctrl-single,pins = <
0x078 0x07 /* P9.12, UART_TX_CTSn, gpio1_28, Pulldown, OUTPUT Mode7 */
0x040 0x27 /* P9.15, UART_TX_RTSn, gpio1_16, Pulldown, INPUT Mode7 */
0x044 0x27 /* P9.23, UART_RX_CTSn, gpio1_17, Pulldown, INPUT Mode7 */
0x1ac 0x27 /* P9.25, UART_RX_RTSn, gpio3_21, Pulldown, INPUT Mode7 */
0x1a4 0x07 /* P9.27, MOTE_RESET, gpio3_19, Pulldown, OUTPUT Mode7 */
0x164 0x17 /* P9.42, TP13, gpio0_7, Pullup, OUTPUT Mode7 */
>;
};
};
};
/*Turn on UART2*/
fragment@1 {
target = <&uart2>; /* really uart1 */
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins>;
};
};
/*Turn on UART4*/
fragment@2 {
target = <&uart5>; /* really uart4 */
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart4_pins>;
};
};
/*Turn on GPIO*/
fragment@3 {
target = <&ocp>;
__overlay__ {
// Note: gpio-of-helper &gpio pointers are off-by-one compared with the hardware:
// For example: hardware GPIO bank 0 = &gpio1
SmartMesh_GPIO {
compatible = "gpio-of-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&gpio_pins>;
P9_12 {
gpio-name = "TX_CTSn";
gpio = <&gpio2 28 0>;
output;
init-low;
};
P9_15 {
gpio-name = "Rsvd-TX_RTSn";
gpio = <&gpio2 16 0>;
input;
};
P9_23 {
gpio-name = "Rsvd-RX_CTSn";
gpio = <&gpio2 17 0>;
input;
};
P9_25 {
gpio-name = "Rsvd-RX_RTSn";
gpio = <&gpio4 21 0>;
input;
};
P9_27 {
gpio-name = "MOTE_RESET";
gpio = <&gpio4 19 0>;
output;
init-low;
};
P9_42 {
gpio-name = "TP13";
gpio = <&gpio1 7 0>;
output;
init-high;
};
};
};
};
}
Kernel Source
The device tree source file needs to be compiled as an overlay to be loaded and applied as part of the system start-up. This can be done as a stand-alone step (described below in the ‘Useful Tools’ section) but in normal operation, it is preferred for the overlay to be compiled as part of the kernel build process and loaded at the system boot.
The steps to get a fresh version of the kernel set up and compiled are discussed next. See reference 6 for more specifics on these steps.
- Execute the following to set up a bb-kernel directory structure with appropriate files
git clone https://github.com/RobertCNelson/bb-kernel.git
- Change to that directory
cd bb-kernel/
- Check out the kernel source. This example is for the 3.8.x branch
git checkout origin/am33x-v3.8 -b tmp
- Grab the device tree compiler
sudo apt-get update sudo apt-get install device-tree-compiler lzma lzop u-boot-tools
- Build the kernel: This script will compile the kernel, gather the modules and place them in a directory ./bb-kernel/deploy. Note that part of the way through this script the Kernel Configuration GUI will open. Press the escape key twice to exit the GUI and continue.
./build_kernel.sh
Device Tree Compilation and Distribution
This series of steps will take the dts file described previously with the example for this design, compile it into the kernel and redistribute the files on to the BBB SD card such that the updated kernel will be utilized.
The next several actions occur on a Linux workstation.
- Place the dts file (SmartMeshGateway-00B0.dts for this example) at the capes directory:
cd to whatever directory has the dts file of interest cp SmartMeshGateway-00B0.dts ./bb-kernel/KERNEL/firmware/capes/.
- Edit the ./bb-kernel/KERNEL/firmware/Makefile to include:
# the Infinetix SmartMesh Gateway cape fw-shipped-$(CONFIG_CAPE_BEAGLEBONE) += \ SmartMeshGateway-00B0.dtbo
- Recompile the kernel to generate and link in this device tree overlay blob object (dtbo) At the ./bb-kernel level execute: (again escape out of the Kernel configuration manager)
./tools/rebuild.sh
- After the compile is complete you should see various compressed files in the ./bb-kernel/deploy directory. For this example they were:
3.8.13-bone70-dtbs.tar.gz 3.8.13-bone70-firmware.tar.gz 3.8.13-bone70-modules.tar.gz 3.8.13-bone70.zImage config-3.8.13-bone70
- Next, upload the files to the BBB SD card. This example assumes a tmp_deploy directory was created on the SD card and that the BBB IP address is 192.168.7.2.
scp * ubuntu@192.168.7.2:/home/ubuntu/tmp_deploy/.
On the BBB, distribute the files and reboot:
- Do a secure shell login to the BBB. For this example, IP address is 192.168.7.2.
The login is ubuntu, and the typical password is temppwd.
ssh ubuntu@192.168.7.2
- Untar the files that were placed in the tmp_deploy directory. Note the -C option places the unpacked files at the directory location specified. Look at the file structure built into the compressed files before unpacking to see what directory to start with. One can use the tar -tf command to examine the file structure. For this example, the first tar command places the files at the root directory, the second at /lib/firmware and the third at /boot/dtbs/3.8.13-bone70. Note that these paths may need to be created prior to the unpacking.
sudo tar -xzvf 3.8.13-bone70-modules.tar.gz -C / sudo tar -xzvf 3.8.13-bone70-firmware.tar.gz -C /lib/firmware/ sudo tar -xzvf 3.8.13-bone70-dtbs.tar.gz -C /boot/dtbs/3.8.13-bone70/
- Copy the zImage and rename to match the expected convention
sudo cp 3.8.13-bone70.zImage /boot/vmlinuz-3.8.13-bone70
- Edit the /boot/uEnv.txt file to include the following line such that the new kernel will be booted.
uname_r=3.8.13-bone70
- Reboot the BBB:
sudo reboot
- Use the uname command to check the kernel revision after booting:
uname -r 3.8.13-bone70
Cape EEPROM
For the device tree overlay information to be loaded by the kernel when booting, there must be matching information in the cape EEPROM. Here is an excellent reference 7 that was the primary source for this section.
The above reference mentions a couple of ways that can be used to generate the content of the EEPROM. It turns out that only the part number and version are read and used by the kernel to determine if there is a matching device tree overlay, which is then loaded and utilized. What was done for this example was to take the referenced C routine, make a version that hard-coded all of the details for this version of the cape, but still prompted for the specific serial number for the cape of interest.
The routine generates a data.eeprom file that is then loaded to the BBB. Some of the contents of the data file as read by the hexdump command are shown below.
$ hexdump -C data.eeprom 00000000 aa 55 33 ee 41 30 49 6e 66 69 6e 65 74 69 78 20 |.U3.A0Infinetix | 00000010 53 6d 61 72 74 4d 65 73 68 20 47 61 74 65 77 61 |SmartMesh Gatewa| 00000020 79 00 00 00 00 00 30 30 42 30 49 6e 66 69 6e 65 |y.....00B0Infine| 00000030 74 69 78 20 43 6f 72 70 00 00 53 6d 61 72 74 4d |tix Corp..SmartM| 00000040 65 73 68 47 61 74 65 77 61 79 00 14 30 30 30 30 |eshGateway..0000| 00000050 30 30 30 30 30 30 30 32 00 00 00 00 00 00 00 00 |00000002........|
Assuming the data.eeprom file was generated on a separate workstation, use the following steps to copy the file to the BBB and load it on to the EEPROM
- First copy the file to the BBB, assuming the IP address is 192.168.7.2. For this example, new_dust is the base directory for the SmartMesh code.
scp data.eeprom ubuntu@192.168.7.2:/home/ubuntu/new_dust/.
- Next, load the image into the eeprom using the cat command. First, you have to open up the write permissions The EEPROM address (listed as 0054 below) will depend on the jumper pins on the cape. This example assumes that both address jumpers are loaded.
cd /sys/bus/i2c/devices/1-0054 sudo chmod 666 eeprom cat /home/ubuntu/new_dust/data.eeprom >eeprom
Cape Conflicts
For the BBB, the onboard HDMI pin muxing and setup are treated as a cape, even though it is hardware on the BBB. It turns out that the HDMI overlay with audio (BB-BONELT-HDMI) would lock up the SmartMesh API UART. The HDMIN overlay seemed to work (or at least not cause conflicts).
When the device tree overlay set P9.25 as used by the SmartMesh cape, a conflict was generated with respect to the HDMI cape. As the SmartMesh cape was loading in slot 0, it took priority and locked out the HDMI cape. Instead, the HDMIN cape was loaded.
As long as P9.25 was set, the right things would happen with respect to the HDMI capes, but to make it explicit the HDMI cape was disabled. This done by putting the following in the /boot/uEnv.txt file:
optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI
The dmesg buffer is very useful in debugging cape manager issues. Here are some examples of various situations associated with cape conflicts. What is shown are edits from the dmesg buffer dumped to a file for the various cases.
- This section shows where the SmartMesh cape is recognized for slot 0 and the HDMI cape for slot 5.
[ 0.542137] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,0A5C,3513BBBK3278' [ 0.542176] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black [ 0.566370] bone-capemgr bone_capemgr.9: slot #0: 'Infinetix SmartMesh Gateway,00B0,Infinetix Corp,SmartMeshGateway' [ 0.596317] bone-capemgr bone_capemgr.9: slot #1: No cape found [ 0.633424] bone-capemgr bone_capemgr.9: slot #2: No cape found [ 0.670533] bone-capemgr bone_capemgr.9: slot #3: No cape found [ 0.676793] bone-capemgr bone_capemgr.9: slot #4: specific override [ 0.676829] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4 [ 0.676854] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G' [ 0.676995] bone-capemgr bone_capemgr.9: slot #5: specific override [ 0.677027] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5 [ 0.677052] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
- Later in the same run, where the device trees are loaded, one can see the conflict where HDMI cape fails to load.
[ 3.833254] bone-capemgr bone_capemgr.9: slot #0: dtbo 'SmartMeshGateway-00B0.dtbo' loaded; converting to live tree [ 3.848916] bone-capemgr bone_capemgr.9: slot #0: Applied #4 overlays. [ 3.848936] bone-capemgr bone_capemgr.9: loader: done slot-0 SmartMeshGateway:00B0 (prio 0) [ 3.848985] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2) [ 3.849011] bone-capemgr bone_capemgr.9: loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1) [ 3.849025] bone-capemgr bone_capemgr.9: loader: after slot-5 BB-BONELT-HDMI:00A0 (prio 1) [ 3.849046] bone-capemgr bone_capemgr.9: slot #5: Requesting firmware 'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version '00A0' [ 3.849077] bone-capemgr bone_capemgr.9: slot #5: dtbo 'cape-boneblack-hdmi-00A0.dtbo' loaded; converting to live tree [ 3.849386] bone-capemgr bone_capemgr.9: slot #5: BB-BONELT-HDMI conflict P9.25 (#0:SmartMeshGateway) [ 3.859091] bone-capemgr bone_capemgr.9: slot #5: Failed verification [ 3.865835] bone-capemgr bone_capemgr.9: loader: failed to load slot-5 BB-BONELT-HDMI:00A0 (prio 1)
- Here is a case with the HDMI cape disabled from loading in the /boot/uEnv.txt file.
[ 0.542824] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,0A5C,3513BBBK3278' [ 0.542863] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black [ 0.542927] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI [ 0.567097] bone-capemgr bone_capemgr.9: slot #0: 'Infinetix SmartMesh Gateway,00B0,Infinetix Corp,SmartMeshGateway' [ 0.596925] bone-capemgr bone_capemgr.9: slot #1: No cape found [ 0.634032] bone-capemgr bone_capemgr.9: slot #2: No cape found [ 0.671140] bone-capemgr bone_capemgr.9: slot #3: No cape found [ 0.677402] bone-capemgr bone_capemgr.9: slot #4: specific override [ 0.677439] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4 [ 0.677464] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G' [ 0.677605] bone-capemgr bone_capemgr.9: slot #5: specific override [ 0.677636] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5 [ 0.677661] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI' [ 0.677786] bone-capemgr bone_capemgr.9: slot #6: specific override [ 0.677817] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6 [ 0.677841] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN' [ 0.678096] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI
- And in that same run, where the device trees are loaded, where both the SmartMesh and HDMIN capes are successfully loaded.
[ 3.883754] bone-capemgr bone_capemgr.9: slot #0: dtbo 'SmartMeshGateway-00B0.dtbo' loaded; converting to live tree [ 3.884183] bone-capemgr bone_capemgr.9: slot #0: #4 overlays [ 3.902106] bone-capemgr bone_capemgr.9: slot #0: Applied #4 overlays. [ 3.902125] bone-capemgr bone_capemgr.9: loader: done slot-0 SmartMeshGateway:00B0 (prio 0) [ 3.902167] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2) [ 3.902192] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 3.902207] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 3.902229] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0' [ 3.902246] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree [ 3.902572] bone-capemgr bone_capemgr.9: slot #4: #2 overlays [ 3.933048] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays. [ 3.933073] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1) [ 3.933283] bone-capemgr bone_capemgr.9: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2) [ 3.933303] bone-capemgr bone_capemgr.9: loader: after slot-6 BB-BONELT-HDMIN:00A0 (prio 2) [ 3.933332] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version '00A0' [ 3.933363] bone-capemgr bone_capemgr.9: slot #6: dtbo 'cape-boneblack-hdmin-00A0.dtbo' loaded; converting to live tree [ 3.934101] bone-capemgr bone_capemgr.9: slot #6: #2 overlays
Useful tools
Some useful device tree commands are listed below. They can be easily scripted if desired.
- List what capes are currently loaded
cat /sys/devices/bone_capemgr.9/slots
- List the current classes of the BBB GPIO signals
ls -al /sys/class/gpio
- List the current states of the BBB GPIO signals
cat /sys/kernel/debug/gpio
- Compile the dts file and copy it to the proper location. This example is for the 00B0 revision of the SmartMeshGateway dts
dtc -O dtb -o SmartMeshGateway-00B0.dtbo -b 0 -@ SmartMeshGateway-00B0.dts cp SmartMeshGateway-00B0.dtbo /lib/firmware/.
- To load this cape on to the operational system
echo SmartMeshGateway:00B3 >/sys/devices/bone_capemgr.9/slots
- To ‘de-compile’ a device tree blob: (example looking at bb-kernel/KERNEL/arch/arm/boot/dts/am335x-boneblock.dtb)
dtc -I dtb -O dts am335x-boneblack.dtb | less (or > file.txt to cat to a file)
Acknowledgements
This work relied on many sources of information. Here is a list of links included in this discussion, along with a couple of others that I found useful.
- Infinetix SmartMesh IP Gateway system
- Linear Technology’s SmartMesh IP™ technology
- BeagleBone Black
- BBB and the 3.8 Kernel
- Adafruit Device Tree background
- Adafruit Device Tree Overlays
- Linux on ARM: BeagleBone Black
- BeagleBoard Ubuntu
- BBB Pin multiplexing
- BBB Cape Expansion Headers
- BBB Cape Mux register offset values
- BBB Cape EEPROMS
Linear Technology, Dust, Dust Networks, SmartMesh® and the Linear logo are registered trademarks and SmartMesh IP™ and the Dust Logo are trademarks of Linear Technology Corporation. The INFINETIX logo is a trademark of INFINETIX Corp. All other trademarks are the property of their respective owners.