ARM Code for Raspberry Pi Goes Open Source (Video)

"The Raspberry Pi project relies heavily on Open Source and Free Software — heck, it's targeted by more than one Linux distro. But some of the hardware stack that makes up the Pi itself needs closed-source code to run; the code that runs all kinds of low-level hardware is often closed source and closed off. I got wind from project instigator and lead Eben Upton that the system-on-a-chip at the Raspberry Pi's heart is about to get a lot more open. Says Upton: "We're about to open source all of the remaining closed source ARM code for the Pi. This will make BCM2835 the first ARM multimedia SoC with a fully-open-source ARM user and kernel implementation." I spoke for a few minutes with Alex Bradbury, who runs the Linux software work for the project, about licensing and what the new code means not only for Raspberry Pi but for users and other OS projects." (Note: the sound quality on this translantic Skype call is poor. We suggest reading the transcript.) Get the code while it's hot.

Comments

Re:Count me stunned

[Unknown Lamer]

Hiding under the video is a "Hide/Show Transcript" link that displays a full transcript if you can't watch the video (or just prefer reading).

Looks like the heavy lifting is done elsewhere

[brian.swetland]

Haven't had a chance to wade through all the code here, but it looks an awful lot like it's basically rpc stubs and glue (allocator, buffer management, etc) to remote the OGLES calls to the media processor, which presumably handles all the actual translation of OGLES API to whatever the internal architecture of the GPU looks like. Which is a perfectly reasonable approach, just not necessarily 1:1 with the other SoCs (which don't have a GPU block capable of speaking remoted OGLES, thus requiring knowledge of the underlying hardware "secret sauce" in the GL libraries or drivers on the host side).

Awesome that they're releasing this as open source rather than insisting on keeping it closed -- much easier to work with this way.

Re:Looks like the heavy lifting is done elsewhere

[ebenupton]

That's a fair observation. We're lucky that, with firmware installed, the VideoCore GPU exposes a much higher-level interface to the ARM side than some other architectures. This has allowed us to provide a viable, useful open source stack while also addressing Broadcom's (completely legitimate) interest in protecting the fine detail of the underlying IP from competitors and patent trolls.

To help people get the most out of this, we hope to sponsor some efforts to formally document the interface exposed by the GPU over the next few months.

Re:Looks like the heavy lifting is done elsewhere

[ebenupton]

Apart from purists who want to have source for every programmable block on the SoC, everybody wins.

That's my hope. My issue with the purists is that it's not obviously clear why they want to see the microcode running on a proprietary RISC core inside the GPU, but not for example the Verilog. Stallman is one of the few people who has a self-consistent model of what he wants to be able to see, arguing that code which is "equivalent to a circuit" (i.e. in ROM) need not be made visible. Now we don't meet this criterion as our microcode lives on the SD card, but that's largely a cost and flexibility issue and we may yet go there to get the FSF endorsement.

From one point of view the cost to Broadcom to making this open source is not nearly the same as for the other GPU vendors -- I suspect this RPC glue is not among the crown jewels of Broadcom's IP

I should have kept some of my notes from those meetings :)

Does this (or will this) support future / higher end parts using the same VideoCore architecture? It definitely increases my interest in the BCM SoC family if so...

While I can't commit to this, I'm certainly a very vigorous advocate for this position, from a commercial and a community relations standpoint. Fingers crossed.

Re:Looks like the heavy hiding is done elsewhere

[ebenupton]

That was our feeling. This model is an order of magnitude easier to sell to the chip vendor, and provides all the benefits normally associated with open source drivers (provided the interface is adequately documented, which it will be in the near future).

Re:I'm confused

[ebenupton]

You're correct. The VideoCore GPU exposes a fairly high-level interface to the ARM side, so passing messages *is* the interface. We're lucky that VideoCore provides for a good tradeoff between the Broadcom's legitimate desire to maintain a degree of secrecy around the register-level operation of the hardware (read concern about competitors and patent trolls) and FOSS users' need for source code access and control.

Re:Interesting, interesting...

[ebenupton]

Actually, if you look at Broadcom's recent behaviour around Bluetooth drivers, I think there's good (public) evidence of a sea change in the attitude towards open source.

Re:Count me stunned

[drinkypoo]

A lot of people have been complaining very loudly about this, because they announced that they had ICS running two months ago and there's been nothing released since, and the community has been unable to assist because not only has there not been any source release, but they haven't even released the videocore binary. Well, here's the sources needed to make it happen.

For the last month or so, I have been advocating the alternatives to the R-Pi specifically because the graphics driver has not only been closed, but has had an inadequate release schedule. This release should address that issue nicely.

Re:Extremely Good News

[ebenupton]

Now the question is how much of the work is done by the firmware on the GPU rather than the driver running on the CPU?

Easy answer - the majority of the intricate register-level work is done by the firmware, rather than by the driver. This is how we've been able to reconcile the legitimate interests of Broadcom in keeping the fine detail of the implementation private, while also providing a workable FOSS driver suitable for use in (for example) porting other operating systems to the Pi.

Re:Count me stunned

[lkcl]

Also, maybe the chineese promissing* that the A10 will have an entirely free stack helped a bit on this decision.

* As far as I know, they still didn't deliver it... But just the promisse should be enough to change Broadcom's strategy.

yes, that's the whole point. you play one company off against the other. the first one that *actually* goes and releases full GPL-compliant source code of their 3D GPU for example, i will INSTANTLY be recommending it to our clients. our clients are PRC State-Sponsored companies: one of them has a production capacity of 20 million units a *week*.

regarding the A10: *sigh* yeah i know. they can't actually release the source code of MALI, because that's locked down by ARM playing silly-buggers, including deleting public requests on ARM's forums for them to release the source code, *and* despite loads of ARM employees repeatedly advising ARM that releasing the source code is in ARM's best interests.

so we have to rely on the limadriver project, basically, which is making good progress.

we know that Allwinner made a promise to look at releasing the source code of the CedarX audio/video engine, but again, there, i think there will be more mileage out of reverse-engineering it. a "wrapper" has been written which traps system calls, giving a clear idea of what's going on.

the last part, the DDR3 "setup" phase, has already been reverse-engineered. it was a few hundred lines of assembler, that's all. so, the boot process is at least entirely free software.