All News | Boards | Chips | Devices | Software | Archive | About | Contact | Subscribe
Follow LinuxGizmos:
Twitter Facebook Pinterest RSS feed
*   get email updates   *

Introducing the BeagleBone Black's Linux 3.8 kernel

May 23, 2013 — by Guest Contributor 15,489 views

This guest column by 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.


Introducing the BeagleBone Black’s Linux 3.8 Kernel
by Jason Kridner, co-founder of


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 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?


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


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, a robust community where software developers and hobbyists share solutions, showcase new projects, ask questions and offer feedback.


(advertise here)

Print Friendly, PDF & Email

5 responses to “Introducing the BeagleBone Black's Linux 3.8 kernel”

  1. Ben Voigt says:

    So are these improvements to the video drivers “coming soon”, or can I see them in action today? I haven’t been able to find SGX PowerVR drivers that load, at least for the Angstrom distro 05/08 running “opkg install omap3-sgx-modules” told me there weren’t any packages matching the current kernel version.

    About to try the 05/20 image which just appeared on the CircuitCo site, and see if I can get the SGX OpenGL demos to run.

  2. Jason Kridner says:

    SGX on 3.8 and newer kernels using DRM is still a work-in-progress.

    BTW, here is another nice write-up on the 3.8 kernel from some of the folks that did the heavy lifting:

  3. Otti says:

    Hi there, brilliant work on the BBB, or so I thought. Last night I was running my BBB off a standalone battery (5V, 2.1A) with a 4D capescreen and keyboard attached. I’d had the thing booted for not more than two minutes with firmware I’d used several times before without any issues, but last night every time I clicked out of vi to test a function the keyboard flashed and wouldn’t enter text. It was just too much of a coincidence to be a simple hardware glitch. Unplugged it a couple of times, no joy. I was still able to navigate through the command history to close down using the up and down buttons on the cape, but I’m convinced this was some sort of security breach. Please tell me what was the most likely source? The screen? The keyboard? Surely not the BBB itself? It’s really a critical issue for me, since I like to know that if something goes wrong in general it’s worthwhile trying to track down the source of the problem, rather than chasing my own tail with some hacker leading me a merry dance. I only use the BBB offline since first installing a few bits and pieces, and the OS was Kali. The BBB was kinda my last hope for unmolested programming. Thanks in advance. And PS – don’t hesitate to get technical; for me following any tips through is well worth the effort.

Please comment here...