i‎ > ‎9‎ > ‎


Mmm... Free Pi code —

Raspberry Pi maker says code for ARM chip is now open source

Open sourced GPU drivers will boost graphics acceleration and software ports.

Jon Brodkin - Oct 24, 2012 6:35 pm UTC

The makers of the Raspberry Pi credit card-sized computer today announced every last piece of code running on the computer’s ARM chip has been open sourced. While the computer could already run several Linux-based operating systems, not all the drivers were open source. Going fully open source prevents users from having to use drivers that are proprietary or reverse-engineered, and it should make it easier to create new Raspberry Pi-targeted OS ports.

The announcement said all the VideoCore driver code has been made available on GitHub under the 3-clause BSD license, making the Pi’s BCM2835 chip “the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers.” As of today, “everything running on the ARM is now open source.” (UPDATE: As some astute readers note, this isn't strictly true; see the Editor's Pick comments for more details.)

“Broadcom is the first vendor to open their mobile GPU drivers up in this way,” wrote Raspberry Pi Foundation lead Linux developer Alex Bradbury. “We at the Raspberry Pi Foundation hope to see others follow.”

The additional open source code will also make it easier for new operating system ports to take advantage of the Pi’s full hardware-accelerated graphics capabilities. Bradbury specifically mentioned progress in bringing FreeBSD, NetBSD, Plan9, RISC OS, Haiku, and other operating systems to the Pi.

"Aside from being exciting to FOSS enthusiasts for philosophical reasons, it’s also going to make it much easier for third party developers to (for instance) implement Wayland EGL client and EGL server support, or to provide better integration of GLES/VG with X.Org," Bradbury wrote.

Promoted Comments

  • YumaSmack-Fu Master, in training Unforunately it's not really open source at all. I'm not too familiar with Broadcom's SoC, but it seems like the bulk of the driver is running on a side processor. The open sourced code simply passes commands and data back and forth between the user's code and the real driver doing the work. Now, a lot of hardware uses firmware these days, so it's tempting to think of what's running on the side processor as firmware, but when the driver running on the main CPU is just an RPC layer and most of the magic (including things like the shader compiler) is happening on the side processor then I would think that any person familiar with the hadware/software interface would rightly say that the "driver" is really the code on the side processor and not the open source code.

    Now, having the CPU layer as open source is better than not having it, but this is nowhere near an open source GPU driver. TI does the same sort of thing with their DSP and some auxiliary processors on their OMAP chips, most of the "driver" is running on another processor.
  • MattyArs Praetorian Yuma wrote:Unforunately it's not really open source at all.

    Unfortunately very correct.

    Even the shader compiler is in the closed source blob. All they open sourced was some marshalling shim that does RPC to the firmware which does the real work (and hasn't been opened).

    So it still doesn't have an open source driver. Which means that only Broadcom can implement things like OpenCL and many future OpenGL versions and extensions.

    Which is probably unlikely.

    Check out this example:

    https://github.com/raspberrypi/userland ... ent.c#L488
  • normally buttersWise, Aged Ars Veteran The biggest advantage of an open-source driver is that it can be ported to other operating systems. Broadcom's shim, as I understand it, provides that benefit. The whole point of OpenGL and friends is to provide a hardware-independent interface to the rendering pipeline. I don't think it's unreasonable for the device vendor to own the implementation of those standard interfaces as long as they open any nonstandard glue associated with those interfaces.

    This is about ensuring that developers have all the information they need to talk to the hardware. Developers don't really need to know how the firmware implements OpenGL on the underlying hardware. The details might be interesting in an academic sense but not for practical OS development.
Jon Brodkin Jon is Ars Technica's senior IT reporter, covering the FCC and broadband, telecommunications, wireless technology, and more. Email jon.brodkin@arstechnica.com // Twitter @JBrodkin

You must login or create an account to comment.

← Previous story Next story →


Subpages (2): 5 q