R-Pi ARM-side source for BCM2835 SoC graphics driver released

Posted on Thursday, October 25th, 2012 in ARM, code, open source, R-Pi by the machinegeek

The Raspberry Pi crew reports that the VideoCore driver code which runs on the ARM is now available under a FOSS license (3-Clause BSD to be precise. “The BCM2835 used in the Raspberry Pi is the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers, and that Broadcom is the first vendor to open their mobile GPU drivers up in this way.”

The code is available on the R-Pi GitHub page including the source code for the ARM side libraries used on Raspberry Pi.

Squonk via the contact form.

This entry was posted on Thursday, October 25th, 2012 at 12:01 am and is filed under ARM, code, open source, R-Pi. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

12 Responses to “R-Pi ARM-side source for BCM2835 SoC graphics driver released”

  1. llg says:

    Ah, so you’re replicating more FUD. I’d guess the more the merrier. But really ?

  2. David Ross says:

    @llg are i see you are using yet another alias to spread your FUD & sour grapes again. It really is getting annoying.

  3. llg says:

    Kindly post my other aliases so the audience won’t be misled.

  4. tuxfool says:

    Frankly, If you read the comments from anybody who is involved with gfx drivers in Linux, they say that this isn’t a driver.

    It is merely a shim and the real driver is hidden away in the firmware blob. Having the source to methods to invoke rpc is nice, but calling this an opensource driver is completely misleading (possibly just media bait).

  5. Joe Desbonnet says:

    My understanding of the situation is this: GPU architecture/algorithms is a patent minefield. If you’re in this market you will almost certainly have to deal with patent law suits. Any documentation/source code that is not absolutely necessary is just ammunition which will be used against you. So if you’re in charge of such business, what do you do?

  6. Squonk says:

    I totally agree with Joe: since the acceptance of “mandatory” patents for using a standard like MPEG, the whole graphic processing domain is a patent minefield. If you disclose anything important, you will be pushed out of business by your competitor’s layers.

    Then, you must understand that Broadcom does not owe you anything: they did this after lengthy discussions with the RPi Foundation to obtain this, at their own will. Coming from this market, this is a big step forward and should be appreciated as it is.

    Next, it is a big news for the Linux kernel that can now be installed untainted and for other OSes too, which were up to now kept out of the game.

    The problem here is not with the chip manufacturer, nor the fact that the ARM-side is just an RPC stub to the actual GPU, but it all comes down to the flawed patent system that turns now into a lawyer’s weapon against inventors, which is in total contradiction with the original patent purpose.

  7. tuxfool says:

    All of what you said is perfectly true. Raspberry Pi and Broadcom owe me nothing. The issue here is their claim that somehow releasing a stub, somehow qualifies them as having fully open source drivers, and that this is some kind of great achievement (Linux graphics devs say that this driver could have easily been reversed, had it been worthwhile).

    I would also like to point out that Intel does have fully open source drivers despite the patent system.

  8. Squonk says:

    It looks like this story has taken too much journalistic spin: if you listen to the original announcement video ( and its transcript, Alex Bradbury says:

    The Linux kernel module, which we use to communicate with the GPU, is fully open-sourced, GPL and BSD licensed. And the — what we’re open sourcing now are the libraries which run on the ARM side, the GL, the GL ES implementation, the OpenVG implantation, VGL, and so on. So really, how the architecture of the video core works is that there is some code that’s running on the video core side that is quite proprietary, and that’s unlikely to change in the near future, but what we’ve now been able to do is open up everything which runs on the ARM side. So everything which runs from Linux kernel up is now open source, essentially.

    As for Intel, they probably own the key patents, and they are not running on ARM ;)

  9. tuxfool says:

    The question here is that how is this any different from just simply using the OpenGL ES, openVG etc apis that all the other manufacturers offer? I suspect, By openGL implementation he is talking api shim (the implementation is in VideoCore).

    I should note that this model is perfectly fine for most users, but you’re going to suffer issues when there are more advanced requirements. An example of which is X acceleration which supposedly does not map well to the implementation. X developers have no access to lower levels to see where the issues are.

  10. Squonk says:

    Yes, I agree with you: as this is just a stub, there will be no way to make improvements, correct bugs in OpenGL etc.

    The RPi is very good when it comes to make hype ;)

    The main advantage I can see from all this is to open the way to other OSes and the fact that the ARM side is now “clean” of any proprietary blobs.

  11. Joe Desbonnet says:

    Yes, Pi have been very good at their marketing. Net result 500k units shipped with a estimate of 1M for the year. This can only be good news.

  12. hak8or says:

    Super good technical read on why this release is not as awesome as it was thought to be.

    ” It turns out that Broadcom shoved much more into their firmware binary blob than just some basic setup routines and other non-critical tasks. Broadcom’s OpenGL ES (GLES) implementation is even lodged within this GPU driver firmware. “

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Recent Comments

  • Noy: Yuuup
  • KH: I guess this is a failed attempt at making a pass/fail cable tester out of discrete ICs. A single pass/fail LED is not that useful....
  • Max: Considering it only seems to test that all wires conduct, I'm not sure what exactly does this show you that 7 LEDs each powered through...
  • David: Please
  • Dan: Such comment. Wow.