This guest column by BeagleBoard.org co-founder Jason Kridner introduces the BeagleBone Black’s cutting-edge Linux 3.8 kernel, up from the original BeagleBone’s 3.2 kernel. The new kernel incorporates a new Direct Rendering Manager (DRM) display driver architecture, as well as full support for the Device Tree data structure introduced in Linux 3.7 in order to streamline ARM Linux development and hardware support.

 

BeagleBone Black is out! At just $45 for a 1GHz Sitara ARM AM335x Cortex-A8 board configured and ready to use over the provided USB cable in just seconds, these tiny boards are flying off the shelves and making a big splash. In addition to the new built-in HDMI output, 2GB on-board eMMC flash storage and upgraded RAM now at 512MB, there is also an updated kernel, jumping from Linux version 3.2.x to 3.8.x, and updated BoneScript with the start of a very helpful live running tutorial. These software improvements are critical for enabling the next generation of Beagle users and are having a big impact.

Chasing newer kernels has been an on-going mission of Beagle development as we seek to best enable the largest body of kernel developers to advance and utilize the project. While we haven’t yet succeeded in using a vanilla kernel (one that hasn’t been patched outside of Linus’s kernel sources), many of the patches we’ve applied have come directly from the Linux mailing lists where the patches have been submitted to upstream maintainers already. We actually started BeagleBone Black integration with the 3.7 kernel and switched to 3.8 shortly before launch — needing to base off of the latest stable kernel available to provide support. This summer, we’ll be tapping the TI kernel development team and a number of interns to help the BeagleBoard.org community and key developers in cleaning up patches that aren’t yet submitted and pushing them to the upstream maintainers as well. We’ve skipped 3.9 and will be hopping back on the mainline train for the 3.11-rc.

While we always strive to be aggressive in adopting newer kernels to provide with the boards, launching on such a relatively new kernel wasn’t a straight-forward decision. The 3.2 kernel has been pretty stable with a lot of support and some projects have already made patches to enable BeagleBone Black on their older code revisions, such as the “Rowboat” project that provides Android 4.1 (aka. “Jelly Bean”) in an open source publicly developed repository. However, a few key features in the new 3.8.x kernel made it so compelling that we simply wouldn’t want developers to continue spending their time on the older code.

The first critical update is “device tree.” In the old style, each platform would have its own identifier and run-time logic to configure all of the various peripherals included in the platform. The hundreds of ARM platforms made all of this run-time logic something virtually unmaintainable and the upstream maintainers declared that no new platforms would be supported with the old style. That means, if we didn’t switch to device tree, no matter how good of quality work we did, we’d always be stuck maintaining it ourselves and we’d never be able to benefit from the work from other Linux developers. That simply wasn’t acceptable, and it was best that we paid the tax as early as possible to make sure new contributions would be as compatible as possible.

Device tree isn’t just a burden though, it is actually a huge benefit. Instead of all that run-time logic written up as C code, there are now simple data structures created to describe the peripherals on the platform. Where this pays off for us, is in the development of capes. By standardizing all of the logic in the kernel and providing the device tree information as data files, it becomes rather easy for a new cape developer to simply create a device tree description of their board and provide it to end users without them ever needing to recompile the kernel! As all of this gets documented, cape development is being greatly simplified and few cape developers should ever have to touch a line of code and end-users should rarely need to change their kernel binary itself based on simply using new capes.

BeagleBone Black is one of the first completely device tree enabled ARM platforms, so we’ve been pushing the envelope of what device tree can support. In many cases, we’ve fixed issues in the core device tree support from which all future development can benefit. We’ve also introduced some compelling new features to device tree, such as run-time overlays that enable loading and configuring device drivers at any time. Not only does this improvement simplify prototyping, but enables loading drivers based on user input for components that cannot be probed by the hardware.

The second critical update is the use of a more modern display driver architecture built on the Direct Rendering Manager (DRM), rather than a simple framebuffer. This turns out to be critical to support run-time determined resolutions for monitors that are probed for their capabilities over the HDMI cable using EDID. Work is still on-going to improve the support of various monitors, but the solution on earlier kernels involved hard-coding values into the boot arguments to specify the boot resolution. Being able to simply plug in a monitor and have it work at the highest supported resolution is an incredibly welcome feature of the new kernel.

Our process of maintaining kernel patches has also had a significant overhaul. To best clarify what patches are outside of the mainline, we’ve been maintaining all of our patches filed neatly into subdirectories outlining the subsystems they impact and making it very clear what is living outside of the mainline code.

While we still haven’t caught mainline and haven’t enabled support for all capes with this new kernel release, we are well along the way and cape enablement has been greatly simplified. We are closing the chase and using bleeding edge features with great success. Those who don’t want to come along for the ride are also having great success. With BeagleBone Black, the question is rarely, “will it run my software?,” but “which of the numerous solutions do I want to use?.” It is a pretty wonderful world, to have so many choices!

Given the dynamic growth of cape add-on boards for BeagleBone Black and wide degree of users and usage, I believe our choice to perform this significant kernel update has been very rewarding for developers and end users. Why not have some fun and join the chase?
 

References

Further details regarding the topics in this announcement are available from the references below.

• AM335x kernel v3.2
• Using capemgr and devicetree overlays to configure a pinmux on the BeagleBone
• DRM Driver Development For Embedded Systems (pdf download)
• Linux DRM Developer’s Guide
• Direct Rendering Manager background
• BeagleBone Capes portal

About the author: Jason Kridner is Software Architecture Manager for Applications Processors, at Texas Instruments. A well-known open-source software architect, Kridner is the co-founder of BeagleBoard.org, a robust community where software developers and hobbyists share solutions, showcase new projects, ask questions and offer feedback.