Using the U-Boot Extension Board Manager – BeagleBone Boards Example

This article follows two earlier blog posts about Device Tree overlays: Using Device Tree Overlays, example on BeagleBone boards Device Tree: Supporting Similar Boards – The BeagleBone Example Introduction As explained in the first two blog posts, the BeagleBone boards are supported by a wide number of extension boards, called capes. When such a cape is plugged in, the description of the devices connected to the board should be updated accordingly. As the available hardware is described by a Device Tree, the added devices on the cape should be described using a Device Tree Overlay, as described in the first … Continue reading Using the U-Boot Extension Board Manager – BeagleBone Boards Example

Device Tree: Supporting Similar Boards – The BeagleBone Example

Most of the BeagleBone boards from BeagleBoard.org share the same form factor, have the same headers and therefore can accept the same extension boards, also known as capes in the BeagleBoard world. Of course, a careful PCB design was necessary to make this possible. This must have been relatively easy with the early models (BeagleBone Black, Black Wireless, Green, Green Wireless, Black Industrial and Enhanced) which are based on the same Sitara AM3358 System on Chip (SoC) from Texas Instruments. However, the more recent creation (2019) of the BeagleBone AI board and keeping compatibility with existing capes must have been … Continue reading Device Tree: Supporting Similar Boards – The BeagleBone Example

Using Device Tree Overlays, example on BeagleBone Cape add-on boards

The concept of Device Tree overlays The Device Tree language is a way to describe hardware that is present in a system and cannot be automatically detected. That’s the case of devices directly implemented on a System on a Chip, such as serial ports, Ethernet or Nand flash controllers. That’s also the case of devices connected to a number of buses, such as I2C and SPI, that do not provide mechanisms for dynamic enumeration and identification of devices. For a given CPU architecture (ARM, PowerPC, etc), such a description allows to have a unique kernel supporting many different systems with … Continue reading Using Device Tree Overlays, example on BeagleBone Cape add-on boards

Improving usage of device trees

Using device trees is one of the most complicated and important, and sometimes risky, elements of using a Beagle to make use of add-on hardware. With the addition of the AM5729-based BeagleBone AI to the family of boards sporting BeagleBone headers, the complications have increased, requiring additional considerations with dependencies on different processor pins connected to different header pins and a different peripheral mix. Further, AM5729 won’t be the last processor where Beagle uses on a board with BeagleBone headers! Further, in community efforts to add dynamic support for device tree overlays into the upstream Linux, much has changed for … Continue reading Improving usage of device trees

Device Tree Overlay Support Lands Upstream

Pantelis Antoniou originated device tree overlay support for the purpose of enabling dynamic hardware configuration under Linux on devices like BeagleBone that use device tree for hardware configuration. Device tree was introduced to Linux for the purpose of putting the description of hardware into data structures, rather than building it up programmatically, greatly reducing the amount of code required to be maintained within the Linux kernel sources. Until now, the device tree data structure was only processed at boot time and that simply can’t work for devices that might change hardware configurations after boot. While many BeagleBone capes can be … Continue reading Device Tree Overlay Support Lands Upstream