User: Password:
Subscribe / Log in / New account Weekly Edition for December 12, 2013

Taking BeagleBone Black for a walk

By Nathan Willis
December 11, 2013

Linux powered single-board computers (SBCs) are not quite a dime a dozen, although the price is dropping rapidly enough that such a milestone is not entirely out of the question. While the news in this space over the past two years has been dominated by the Raspberry Pi, there are plenty of other choices. One of the more popular options is the BeagleBone Black, which is more than a match for the Pi in terms of hardware power, and offers a software selection worth exploring, too. Determining which system is right for which task depends on weighing a lot of factors.

Getting around the dog

The BeagleBone Black is the fourth generation SBC from the BeagleBoard project. The first and second devices were called "BeagleBoards;" the BeagleBone moniker referenced the significantly smaller physical dimensions of the third generation product. The BeagleBone Black uses the same form factor as the preceding model. But it also includes updated components and a lower price: $45.

[BeagleBone Black]

The basic makeup of the board is straightforward. It is powered by a Sitara AM3358 System-on-Chip (SoC) from Texas Instruments (TI), which is built around a Cortex-A8 CPU from the ARMv7 line. There is 512MB of DDR3 RAM on board, plus 2 GB of built-in flash storage and a slot for an additional microSD card. Connectivity includes a wired Ethernet port, one mini USB client port, one full-sized USB host port, and a micro HDMI connector that outputs both audio and video.

But in these modern times, of course, single-board computers need to provide hardware expansion capabilities. This is where the BeagleBone Black first begins to differentiate itself. The long sides of the board include a full spread of pin headers, right up to where the PCB mounting holes get in the way. In grand total there are 92 pins available, which is considerably more than most competing boards. 65 of those pins are available for digital I/O; eight of the 65 can serve as pulse-width modulators (PWMs) for analog output, and four can be configured to serve as timers. Various subsets of these digital pins can also be configured to provide two I2C ports, two SPI ports, and two serial ports (there is also a separate serial debugging header that cannot be used for general purposes).

In addition to the digital I/O pins, there are seven analog input pins, plus an assortment of 3.3V, 5V, and ground pins. If that is not enough, there is also a pad on the back of the board where enterprising users can solder on a JTAG debugging header. Other nice touches include a 5.5mm DC power connector (the device can run off of power supplied by the USB Client port, but having two options is more convenient), hardware power and reset switches, and a built-in array of four programmable LEDs.

The onboard flash storage come pre-loaded with the Ångström distribution—and numerous tools to get started. When the system boots up, it starts a web server running on (either over Ethernet or using Linux's USB Gadget API to provide networking if the board is connected to a host computer via USB). This server provides access to the board's documentation (the same documentation and tutorials available at, and there is also a Cloud9-based IDE running on port 3000. The IDE comes preconfigured to make use of BoneScript, a JavaScript library tailored to provide access to the board's hardware expansion features.

Of course, BoneScript is not the only option. One can also SSH into the board and explore it from a terminal like any other Linux system or hook up USB peripherals and an HDMI monitor and use Ångström's lightweight graphical environment. Out of the box, the BeagleBone Black I tested (revision A5C, for the record) runs kernel 3.8.13. Access to the array of expansion pin headers is simple, using sysfs. The traditional first project is to blink an external LED; to do this one should attach the LED's anode to a GPIO pin header, the cathode to a nearby ground header, and export the GPIO pin:

    echo 60 > /sys/class/gpio/export

brings up pin number "12" on the left-side expansion header, so that it is accessible as /sys/class/gpio/gpio60 (the GPIO number for the pin has to be looked up in the documentation). Set it as an output pin with:

    echo out > /sys/class/gpio/gpio60/direction

and the LED can be flashed on and off by echoing 1 or 0 to /sys/class/gpio/gpio60/value. The only real tricky part of the process is figuring out the correct GPIO number; the numbers on the expansion header do not map cleanly to the various GPIO numbers because of all the positive voltage, ground, and other assorted pins mixed in—and because the board tries to spread the pins around evenly to provide some flexibility when attaching components. The reference manual PDF has a table that provides the correct numbers.

Kicking it up a notch

As exhilarating as flashing an LED can be, eventually one needs more from one's hardware, which is where BeagleBone capes come into play. Capes are the equivalent of Arduino shields: pin-compatible circuit boards that fit into the expansion headers on the BeagleBone itself. Most capes have expansion headers on top to match the pins on the bottom that fit into the BeagleBone's headers; that way multiple capes can be stacked, and the pin compatibility means a +5V location on one board does not get turned into a ground pin by a board in between.

Currently the crop of BeagleBone Black capes is somewhat limited because the "Black" model introduced some variations over the original BeagleBone (which was white in color, although it is usually just referred to as "BeagleBone"). The eLinux wiki includes an up-to-date page of available capes, with those that are compatible with the BeagleBone Black marked as such. The simpler capes (such as those providing a breadboard or through-hole prototyping board) are compatible with both models; there are also Black-compatible capes available for attaching small LCD screens, serial ports, GPS receivers, electrical relays, and camera modules.

More specialized capes are slowly appearing, too; there is a CAN Bus cape (for automotive usage), an unmanned aerial vehicle (UAV) altitude-and-orientation cape, and a cape designed to run a RepRap 3D printer. As with Arduino, most of the capes are community-design products, so what is available depends mostly on what itches need scratching. However, CircuitCo (who manufactures the BeagleBone original and Black) has been systematically taking Creative Commons–licensed capes from the original BeagleBone and updating the design to match the Black model's pinout, so in many cases a refreshed cape is on the way if it is not already available. Since the original BeagleBone is no longer being manufactured (and was twice the price of the Black), the old capes will probably disappear from production anyway.

On the software side, updates to the Ångström release on the board are available from the site. Separate kernel sources are available on GitHub for those who cannot wait for a new release, although only minor 3.8 updates are available now. The kernel used is the mainline Linux kernel, but it may be simpler to recompile for the device when starting from the exact sources and configuration used in the official build; the official kernel is also updated periodically with support for new capes.

Perhaps more interesting is the array of other Linux distributions available. Ubuntu, Debian, Arch, Gentoo, Sabayon, and Fedora releases are all available. Although the board is not an officially-supported platform for these distributions, the relatively recent ARM revision and simple hardware of the BeagleBone evidently make an ARM distribution relatively easy to get running, either by overwriting Ångström on the internal storage or by installing an image on the microSD card slot (which is faster to experiment with, since overwriting the onboard storage can take close to an hour). For the more adventurous, there is also an Android port available (from TI), as well as QNX and FreeBSD releases.

One reason installing outside distributions is comparatively simple is that the BeagleBone Black uses standard distribution components like the U-Boot bootloader, and that it does not require binary blobs to boot. The graphics chip is a PowerVR GPU that does come with a binary-only OpenGL ES firmware blob, but the board will run non-OpenGL applications fine without it.

Comparing apples and raspberries

The binary blob issue is one of the more frequently cited issues where BeagleBone supporters feel their hardware has an advantage over the Raspberry Pi, which by size and price is the nearest competitor (and one which gets noticeably more news attention). The Pi, of course, uses a Broadcom BCM2835 SoC with an open source user-space component that speaks to a proprietary firmware blob. More importantly, though, the Pi uses a non-standard boot sequence that actually starts up the board's VideoCore GPU first, and the binary VideoCore OS subsequently loads the Linux operating system.

There are other differences as well, starting with the fact that the Pi uses a generation-older ARMv6 core at a lower clock speed. The Pi also includes expansion headers, but fewer of them than the BeagleBone Black, and some of them can be difficult to access. From a practical standpoint, the BeagleBone Black's DC power plug is another nice touch, since the Pi can only be powered over its micro USB connector. The Pi also lacks a hardware reset switch, which is inconvenient. In addition, although both boards are roughly the same size as an Altoid mint tin (which in recent years has become the standard international unit for circuit-board size), the BeagleBone is an exact fit, while the Pi's slightly larger size and sharp corners make it a mismatch. Finally, BeagleBone capes are designed to be stackable, while Pi expansion boards are generally not stackable due to the asymmetry of the expansion headers (on a side note, it is also odd that Pi expansion boards do not have an official nickname akin to "capes" or "shields;" "toppings" or "meringues" would seem to be the obvious choice).

On the other hand, Pi supporters will be quick to point out that the Pi has nice features of its own, such as a dedicated camera module connector using the standard Camera Serial Interface (CSI), built-in support for Display Serial Interface (DSI) output, full-size HDMI, RCA video out, 3.5mm audio out, and the availability of hardware multimedia decoding.

It is definitely true that the Pi offers an easier multimedia experience than the BeagleBone Black. The Pi has more connector options, and its GPU is capable of handling 1080p video—capable enough that there are several active media center distribution options for the Pi.

That is why it always comes down to matching the product with the project. The BeagleBone Black will likely not be useful as an XBMC or video gaming front end for the home theater, while the Pi is considerably more limited in how many sensors, servos, and hardware relays it can control. For free software advocates, the BeagleBone Black product is not quite devoid of binary blobs, but it is possible to boot and run it with free software.

Not everyone cares about the presence or absence of binary blobs, of course. And no doubt the Raspberry Pi Foundation has already heard a lot about this subject; it seems plausible that in the virtually inevitable Pi follow-up, the result will have less reliance on proprietary firmware. The BeagleBone Black can exert some market pressure on the Pi in that area, demonstrating that an almost-totally-free software SBC system is possible to make today.

That is fair play, though, since the success of Pi clearly pushed the reduction in size and price seen in the Black as compared to earlier BeagleBoard/BeagleBone revisions. Earlier BeagleBoards were noticeably bigger than the Pi, and the first BeagleBone retailed at $89. At $45, the Black is a little more expensive than the Pi, but not by much. There is also a gray area between the "hobbyist" uses targeted by the BeagleBone Black and the "educational" projects envisioned by the Pi, of course. But any cheap Linux-powered SBC is an educational opportunity, which can quickly turn into a hobby—or more.

Comments (23 posted)

A multiprocess Firefox

By Nathan Willis
December 11, 2013

Unlike several of the other well-known web browsers, Firefox runs a single process that handles the browser application and the rendering of web content. This is not a policy decision; Firefox has always been single-process. But in 2008, Internet Explorer and Google Chrome both adopted a multiprocess architecture. Mozilla has had restructuring Firefox to also run in multiple processes on its to-do list for quite a while, but the importance of other projects (and the inherent complexity of such a deep change) often kept it on the back burner. Fortunately, that situation has changed in recent months, and on December 5 the first experiments with multiprocess Firefox were made available to the public at large.

There are several potential benefits to splitting up Firefox from a single process into several. For example, running the user interface and the rendering of tab content in separate processes would allow the interface to remain responsive—even if a complex page takes a long time to load. Similarly, separate content processes would make better use of multiple CPU cores. Separate processes can also add more layers of security, so that a malicious site can less easily exploit a bug in Firefox itself to attack a host system, or the OS can sandbox the process rendering page content . But perhaps the most visible advantage would be to isolate crashes and hangs that occur when rendering a page; one page process crashing could leave Firefox itself running, and if each tab runs in a separate process, other pages could survive a crash as well.

Mozilla has known about the benefits for years, of course; the Electrolysis project started exploring a multiprocess redesign back in 2009. In 2010, Firefox 3.6.4 introduced out-of-process plugins (OOPP), which isolated Flash, Java, and the like into a separate process, plugin-container. But Mozilla put Electrolysis on hold in 2011, saying that other work had to take precedence—primarily work on existing responsiveness problems like sluggishness from memory leaks, event loop tuning, garbage collection, and improving the performance of the Places database.

Ironically, though, one of Mozilla's other recent efforts spawned a resurgence in Electrolysis development: the "Boot to Gecko" mobile platform now known as Firefox OS. Firefox OS needed multiple processes for multiple applications, as well as a reliable inter-process communication (IPC) mechanism, which were imported from Electrolysis. In early 2013, serious work on Electrolysis resumed, and was even the subject of a summer internship.

On December 5, Bill McCloskey wrote a blog post explaining the scope and design of the work, and announced that multiprocess was now a configuration option in Firefox nightly builds.

To take the new feature for a spin, users need to launch the nightly build, visit the about:config settings page, and set the browser.tabs.remote to true. Upon restart, Firefox will run the user interface in one process and render web content in another. For now, all web content (i.e., all tabs in all windows) is running in one process, which McCloskey described as a decision to start conservatively, although eventually the plan is to utilize multiple content processes. In particular, he notes that it will take some work to optimize memory consumption in multiprocess mode:

There are many different caches and other shared data structures in Firefox where this might be a problem. We have plans to mitigate these issues. For example, it should be possible for processes to store some of this data in read-only shared memory. A process would be able to observe that it is holding local data that is identical to some data already stored in the read-only cache. In that case, it would drop its own copy of the data and use the shared version instead. Periodically, processes could add new data to the cache and mark it read-only. Processes would want to avoid sharing data that might include sensitive information like credit card numbers or bank data. However, it would probably be safe to share image data, JavaScript scripts, and the like.

In the nightly build, tab titles are underlined to indicate that multiprocess has been enabled, but users should really only encounter the feature if a content process crashes. In that case, a "Tab crashed, try again?" message appears, akin to the message currently shown when a plugin crashes, but the parent Firefox process continues to run undisturbed. For now, basic navigation, search, and bookmark features work in multiprocess mode, but page printing, saving pages locally, and the web developer tools do not. Extensions are a gamble; some work fine, but some do not. I tested the nightly for an hour or so, and apart from the underlined tab titles, did not observe much difference. That should not be taken as a scientific significant study, of course; I followed instructions to test with a separate Firefox profile to minimize the odds of corrupting my existing profile data, and although browsing did seem faster that could just as easily be the result of having no extensions or profile data (bookmarks and history in particular).

A birds-eye view of the feature is that starting multiprocess Firefox launches a parent process that handles the XUL browser window, accepts user input events, and manages IPC with the child (i.e., content) process. Each tab object in the browser process contains an IPC link to the "content" layer for that tab, which is rendered by the content process. All of the operations that cross the browser/content barrier are now performed by sending IPC messages. That list includes a lot of different functionality: navigation functions like forward and back, storing and retrieving cookies, opening WebSockets, handling input, responding to JavaScript onLoad events, and much more. The IPC mechanism also isolates the content process from the filesystem, providing security sandboxing.

There is some reference documentation for many IPC messages online, though there is not a formal API description. McCloskey noted that there are a great many places where IPC is required (which is part of what makes the project so intrusive), although in many cases the mechanism simply has to forward a message from the UI to the Gecko rendering engine. There is additional documentation on the message manager framework itself, and Mozilla's Tim Taubert wrote an introduction to the IPC message-passing system in August.

The current Firefox nightlies include some workarounds like object wrappers that allow the parent process to sit and wait for a response from the content process. This is a no-no from the responsiveness standpoint, but the long term fix means rewriting Firefox to be completely asynchronous, which is far from a simple task. The object wrappers are only used where lag in responsiveness is unlikely to be observed by the user, McCloskey said, but they may be phased out eventually anyway.

Of course, how the internal message passing works is likely to be of far more interest to Firefox extension authors than to the general public, but add-on developers represent an important sector to mozilla. As is, the multiprocess nightlies break a lot of extensions: extensions are not web content, so they run inside the parent process, which in turn means they cannot directly access the content process as they can in normal Firefox releases. McCloskey said that Mozilla is committed to working with extension developers to adapt their code, and that he hopes to follow up on the subject with a series of blog posts, and even update some popular extensions himself.

For users, there is no set ETA for when multiprocess Firefox will become the norm. As the Electrolysis team notes, this is a large project with a lot of pieces to consider, from memory performance to add-on compatibility. But the benefits certainly outweigh the costs, so it is clear that at some point in the future, users will get to run Firefox without worrying that one bad page will take down the entire application—or, worse, lead to a serious security breach.

Comments (11 posted)

2013 Linux and free software timeline - Q3

By Nathan Willis
December 11, 2013

Here is LWN's sixteenth annual timeline of significant events in the Linux and free software world for the year. As per tradition, we will divide up the timeline up into quarters; this is our account of July–September 2013. January through March was covered two weeks ago and April through June last week; timelines for the final quarter of the year will appear next week.

There are almost certainly some errors or omissions; if you find any, please send them to

LWN subscribers have paid for the development of this timeline, along with previous timelines and the weekly editions. If you like what you see here, or elsewhere on the site, please consider subscribing to LWN.

For those readers in a historical mood, our timeline index page includes links to the previous timelines and other retrospective articles that date all the way back to 1998.


Kernel 3.10 is released [technically, late on Sunday, June 30]. With 13,637 changesets, 3.10 is the busiest kernel development cycle seen to date (announcement; development statistics; merge window summaries 1, 2, 3; KernelNewbies page).

EuroPython is held in Florence, July 1 to 8 (LWN coverage).

Pro-tip: "Automatic conflict resolution" is actually pronounced "snake oil"

-- Miguel de Icaza

Fedora 19 is released (Main blurb; ARM and Power releases).

Oracle changes the license of Berkeley DB to AGPLv3, prompting concerns about license compatibility for Debian and other projects. Among others, Bradley Kuhn weighs in (LWN article).

Debian launches, a public web repository of all Debian source code (announcement).

[Qt logo]

Qt 5.1 is released. (announcement).

GNU Radio 3.7.0 is released (announcement).

A "marked for implementation" draft of the HTTP 2.0 specification is released (announcement; LWN article).

[Rust logo]

Version 0.7 of the Rust language is released. (announcement).

GNU Health 2.0 is released (announcement).

The Fedora community mourns the loss of longtime contributor Seth Vidal (blurb).

Akademy is held in Bilbao, July 13 to 19 (LWN coverage).

[Slackware logo]

Slackware celebrates 20 years (announcement; a retrospective from OSNews).

Wayland / Weston 1.2 is released (announcement).

I'm cantankerous, and hard to please. Send me too much and I yell, and send me too little and I yell. Because I'm the Goldilocks of kernel development, and I want my pull requests "just right".

-- Linus Torvalds

Community Leadership Summit 2013 is held in Portland, July 20 to 21 (LWN article).

Open source camera firmware project Magic Lantern implements a feature not even the official Canon firmware can perform: the ability to shoot one frame with two interleaved exposures (LWN article).

CyanogenMod implements an "incognito" privacy mode blocking app access to user personal information (LWN article) and incorporates SELinux (announcement).

Differentiation is key... floppy support is a key differentiator and a really smart move. Someone is going to kickstart a retro-computing tablet that looks just like a 5 1/4 inch floppy, with a slot for a 3 1/2 inch not-so-floppy disk.. and we will be there on day one..and it will be glorious.

-- Jef Spaleta

[Android logo]

Android 4.3 is released (announcement).

Wine 1.6 is released (announcement).

The Razor and LXDE-Qt desktop projects decide to merge (announcement).

Apache OpenOffice 4.0 is released (announcement).

Version 2013.07 of the U-Boot bootloader is released, adding support for cryptographically verified boot (announcement).

FOSS news site The H shuts down (announcement).

OSCON is held in Portland, July 22 to 26 (LWN article).


LibreOffice 4.1 is released (announcement).

This whole issue of privacy is utterly fascinating to me. Who's ever heard of this information being misused by the government? In what way?

-- Larry Ellison shares his thoughts with The Register

GUADEC is held in Brno, August 1 through 8, coinciding with a record heat wave in Central Europe (LWN coverage).

[Tor logo]

A vulnerability in the Tor Browser Bundle (TBB) is discovered which can potentially identify users. The project quickly releases an update to fix the problem (blurb, LWN article).

Lead developer Jean-Baptiste Quéru leaves the Android Open Source Project, unhappy about increasing amounts of proprietary code used for flagship Android devices (blurb).

We seem to have reached the point in kernel development where "security" is the magic word to escape from any kind of due process (it is, in fact, starting to be used in much the same way the phrase "war on terror" is used to abrogate due process usually required by the US constitution).

-- James Bottomley

Bison 3.0 is released (announcement).

Debian celebrates its 20th birthday (announcement).

SourceForge initiates a service through which hosted projects are allowed to bundle third-party Windows installers for "side-loaded applications" into their downloadable packages, drawing considerable criticism (LWN article).

Samsung releases an official version of its exFAT filesystem implementation under the GPLv2, a month after an unofficial copy leaked out (announcement).

Pamela Jones announces that Groklaw will shut down in reaction to the NSA surveillance revelations (announcement).

[Groklaw logo]

It is so alpha that it begins the Greek alphabet. It is so alpha that Jean-Luc Godard is filming there. It is so alpha that it's 64-bit RISC from the 1990s. It's so alpha that it'll try to tell you that you belong to everyone else. It's so alpha that when you turn it sideways, it looks like an ox. It's so alpha that the Planck constant wobbles a little bit whenever I run the unit tests.

-- Nick Mathewson

TypeCon is held in Portland, known for the weekend as "Portl&," August 21 to 25 (LWN coverage).

The free software e-book manager Calibre reaches version 1.0 (announcement, LWN article).


Those of us who experienced the heady days of Nokia's forays into Linux will continue to think on the what-might've-been's had Nokia taken a risk and pulled the trigger on something new and innovative. We had a short glimpse into that future when Nokia announced the N9 and MeeGo as their new flagship platform, but the Elopocalypse brought an end to that future. Perhaps the appliances that represent today's mobile device options would include a more open, accessible, and interesting mobile general computing platform had things gone differently.

-- Maemo Weekly News

The first Firefox OS devices hit the market (LWN article).

[Kernel 3.11 logo]

Linux for Workgroups, also known as kernel 3.11, is released (announcement; merge window summaries 1, 2, 3; development statistics; KernelNewbies page).

Google pushes more Android functionality into its proprietary Google Play Services component. Ars technica, among others, views the change as hostile to the project's openness.

Ubuntu launches its "app store" service, courting third-party developers to write apps for Ubuntu devices with a contest (LWN article).

Apache Cassandra 2.0 is released (announcement).

The LibreOffice team leaves SUSE and joins Collabora (announcement).

The NSA's actions are making us all less safe. They're not just spying on the bad guys, they're deliberately weakening Internet security for everyone—including the good guys. It's sheer folly to believe that only the NSA can exploit the vulnerabilities they create. Additionally, by eavesdropping on all Americans, they're building the technical infrastructure for a police state.

-- Bruce Schneier

[Plasma logo]

KDE's Plasma Active 4.0 is released (announcement).

LinuxCon North America is held in New Orleans, September 16 to 18. Here and there, some jazz is heard (LWN coverage).

The OpenZFS project launches, with the goal of developing the filesystem independent of Solaris (announcement).

Linux Plumbers Conference is held in New Orleans, September 18 to 20 (LWN coverage. The Linux Security Summit is also held on site, on September 19 and 20 (LWN coverage).

We've conquered the game-show market with an unblemished record.

-- IBM's Brad McCredie, on the Linux-based Watson

[Cyanogen logo]

Steve "Cyanogen" Kondik and friends form Cyanogen, Inc. to further develop the CyanogenMod Android replacement. (announcement).

NVIDIA agrees to provide GPU documentation to the open source Nouveau driver project (announcement).

[SteamOS logo]

Game maker Valve announces Steam OS, a Linux-based operating system the company is making that will power its future gaming consoles (announcement).

GStreamer 1.2 is released (announcement).

GTK+ 3.10 (announcement) and GNOME 3.10 (announcement) are released.

It seems too many programmers see documentation as unpleasant red tape they want to cut through as quickly as possible, instead of an opportunity to communicate with their *users*. To the contrary: users should be the most important people in the world if you're writing code that's worth documenting at all.

-- Guido van Rossum

Fedora celebrates ten years (announcement).

[GNU logo]

The GNU project celebrates its 30th birthday (announcement).

Comments (none posted)

Page editor: Jonathan Corbet

Inside this week's Weekly Edition

  • Security: Secure text messaging for CyanogenMod; New vulnerabilities in chromium, kernel, mozilla, php, ...
  • Kernel: A Btrfs introduction; Fixing FS_IOC_GETFLAGS; Memory barriers for TSO architectures.
  • Distributions: A look at CyanogenMod 11M1; RHEL, ...
  • Development: Returning error codes from close(); KDevelop 4.6.0; Firefox 26; Liability for third-party DRM-busting code; ...
  • Announcements: The Linux Foundation's "AllSeen Alliance", ...
Next page: Security>>

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds