ARM Code for Raspberry Pi Goes Open Source (Video)

← Back to Stories (view on slashdot.org)

ARM Code for Raspberry Pi Goes Open Source (Video)

Posted by Roblimo on Wednesday October 24, 2012 @12:51AM from the more-open-than-ever-before dept.

"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.

31 of 91 comments (clear)

Min score:

Reason:

Sort:

Hallelujah by drinkypoo · 2012-10-24 01:00 · Score: 4, Interesting

Hopefully this means we can get a working CyanogenMod for R-Pi. There will allegedly eventually be an official (foundation) release of ICS, and hopefully this announcement helps pave the way for that since allegedly releasing the videocore was part of the problem, but since R-Pi now has 512MB it's likely the official release will target that.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
1. Re:Hallelujah by DeTech · 2012-10-24 09:13 · Score: 3, Insightful
  
  I feel like the tech press really dropped the ball on this and swallowed the hype from the Raspberry Pi Foundation. The drivers are not open source. The userspace stubs are.The stubs just use RPC to talk to the real driver which is still closed. Go look at the source code linked:
  https://github.com/raspberrypi/userland/blob/master/interface/khronos/glxx/glxx_client.c#L488
  The code here does nothing except RPC – this is not a driver. Which means that it’s not possible add OpenCL or new OpenGL versions. This announcement is a disgusting lie.
Re:Count me stunned by Unknown+Lamer · 2012-10-24 01:07 · Score: 5, Informative

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).

--

HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Extremely Good News by folderol · 2012-10-24 01:08 · Score: 2

This just totally changes the ball game. I think we can expect the FOSS community to descend on this like a storm of locusts! Hats off to Broadcom and the RasPi people for hammering out this deal.
1. Re:Extremely Good News by chill · 2012-10-24 01:44 · Score: 2
  
  This *partially* changes the ball game. ARM isn't a chip, it is a CPU component on the processor. The "chip" is comprised of many different parts, like Legos. That is why it is called a System on a Chip (SoC).
  Other components, for example the GPU, are still very proprietary and closed.
  
  --
  Learning HOW to think is more important than learning WHAT to think.
2. Re:Extremely Good News by amiga3D · 2012-10-24 02:27 · Score: 2
  
  It's a step. Another step towards freedom. We may not get there all at once but if we keep taking steps we'll make it eventually. This is a big step.
3. Re:Extremely Good News by ebenupton · 2012-10-24 03:23 · Score: 3, Informative
  
  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.
Not the first. by Anonymous Coward · 2012-10-24 01:15 · Score: 3, Interesting

"ARM multimedia SoC with a fully-open-source ARM user and kernel implementation"
No. It's the first from Broadcom. I've got chips on my desk right now from TI (DaVinci series), with a fully open-sourced UBL and U-Boot (primary and secondary bootloaders), and a full GPL'd kernel. All ARM-connected interfaces also use open-source drivers. The only binary/proprietary part of this is the DSPBIOS and DSPlink section, but that applies to the C64x DSP processor half of the chip. The ARM part is ALL fully open-source.
1. Re:Not the first. by ebenupton · 2012-10-24 02:15 · Score: 2
  
  Sorry - slightly loose use of language in the post on the blog. I wouldn't consider the DaVinci to be a "multimedia SoC" because it doesn't have a 3d accelerator. YMMV however, and there are certainly several examples of video-only ARM SoCs with FOSS driver stacks.
2. Re:Not the first. by Andy+Dodd · 2012-10-24 02:45 · Score: 2
  
  That's not really a multimedia SoC - it has no GPU.
  It doesn't have a PVR subcomponent, so it manages to be fully open-source by not having a GPU... Which is the component that is usually closed-source.
  This announcement is the first example of a GPU with open source support.
  
  --
  retrorocket.o not found, launch anyway?
Re:Count me stunned by fuzzyfuzzyfungus · 2012-10-24 01:18 · Score: 5, Funny

I'm told that authorities are awaiting the results of an MRI for confirmation; but there are strong suspicions that Richard Stallman succeeded in burrowing in to Scott A. McGregor, concealing himself inside the host body, and gradually subverting the host's central nervous system.
Interesting, interesting... by fuzzyfuzzyfungus · 2012-10-24 01:26 · Score: 2

I wonder if this is some relatively isolated 'Yeah, go RPi! freedom and stuff! Now, back to business...' thing, or if this represents an actual shift in thinking on BCM's part, to the effect that keeping relatively banal code proprietary does actually inconvenience potential buyers of their chips without necessarily providing a commensurate competitive advantage?
1. Re:Interesting, interesting... by ebenupton · 2012-10-24 02:27 · Score: 4, Informative
  
  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 by marcosdumay · 2012-10-24 01:27 · Score: 5, Insightful

Maybe he saw some money on it... They've sold about a million units just by virtue of supporting Free Softwre, how many more can they sell if they really support it? Anyway, it doesn't cost too much to find out.
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.

--
Rethinking email
Looks like the heavy lifting is done elsewhere by brian.swetland · 2012-10-24 01:35 · Score: 5, Informative

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.
1. Re:Looks like the heavy lifting is done elsewhere by ebenupton · 2012-10-24 02:05 · Score: 4, Informative
  
  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.
2. Re:Looks like the heavy lifting is done elsewhere by brian.swetland · 2012-10-24 02:17 · Score: 4, Interesting
  
  Yup. It's a common solution for video codec blocks, camera pipelines, etc, on ARM SoCs (open driver/library, closed firmware for the peripheral) -- less common for GPUs. I'm personally not at all offended by the "open drivers/libraries on host, closed firmware on peripheral" model -- it's a reasonable tradeoff and, as you point out, lets the vendors keep control over their secret sauce while still allowing for completely open software stacks on the host/AP side of the world. Apart from purists who want to have source for every programmable block on the SoC, everybody wins.
  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 -- but from the viewpoint of someone who doesn't want to have to muck with closed binaries on the host side that are hard to debug, keep supported, adapt to changing APIs/ABIs, none of that matters -- the important bit is you get all the host side source.
  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...
3. Re:Looks like the heavy lifting is done elsewhere by ebenupton · 2012-10-24 02:56 · Score: 4, Informative
  
  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.
4. Re:Looks like the heavy lifting is done elsewhere by makomk · 2012-10-24 03:10 · Score: 2, Insightful
  
  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.
  Most likely because no-one's going to convert (for instance) their entire OpenGL ES driver implementation to Verilog and shove it down into hardware in order to claim to be open source, whilst adding a proprietary RISC core to the GPU and moving the driver on to that is a lot more practical but still destroys most of the reasons why people would want open source drivers in the first place. For instance, if the shader compiler chokes on your code and you want to figure out why, you're stuffed. If the shader compiler can't compile your code efficiently you're stuffed. If what you're doing maps well onto the underlying graphics hardware but poorly onto the more limited OpenGL ES API - which is I believe one of the reasons getting accelerated X rendering is so hard on the Pi - you're stuffed. (Also, if you force it down into Verilog you're in essentially the same boat as your users if it doesn't work.)
  By the way, what you're doing is a fairly transparent abuse of Stallman's public statements in my opinion. His viewpoint is AIUI that if it's code even the manufacturer didn't feel the need to be able to modify in the field, he probably wouldn't need to either. You're basically taking that and saying that, even though you'd like to be able to modify the code in question, you're going to offer a model where you lock it down so that you can claim to be open source without letting anyone else look at and modify the source either. That is really not something that Stallman would agree to.
Re:Count me stunned by Alwin+Henseler · 2012-10-24 01:42 · Score: 3, Insightful

Perhaps the success of the RPi, coupled with people complaining about it being not-entirely-open, put enough pressure on Broadcom. Pressure in the sense of potential sales lost (possibly including other devices / markets that might use the same SoC). To the point where "It might be a commercial advantage if [fully open] checkbox can be marked" won out over "can't release sources due to to patents, 3rd parties, bla bla".
Of course I'm speculating here. But some markets are fiercely competitive, times are tough for tech companies, and every sale counts (and the allmighty $ speaks louder than RMS ;-).
Looks like the heavy hiding is done elsewhere by Anonymous Coward · 2012-10-24 01:44 · Score: 2, Interesting

Which is another way of saying the proprietary is simply "hidden" in a different manner. Also this could be a simple trial balloon for Broadcom. And last someone needs to fix the USB drivers.
1. Re:Looks like the heavy hiding is done elsewhere by brian.swetland · 2012-10-24 01:50 · Score: 2
  
  To be fair, "open drivers / libraries plus proprietary firmware binary to download to hw block" is a better model than "closed userspace libraries/drivers" -- at least you have control/ownership over all the software running on the host side in this model.
2. Re:Looks like the heavy hiding is done elsewhere by ebenupton · 2012-10-24 02:08 · Score: 4, Informative
  
  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:Count me stunned by makomk · 2012-10-24 01:56 · Score: 2, Insightful

Apparently - and I haven't confirmed this personally myself yet - the ARM code for the GPU is basically a thin RPC layer that forwards OpenGL API calls to the actual GPU driver, running on the GPU, which does all the interesting stuff. It's kind of a practical demonstration of why Richard Stallman is so opposed to binary blobs even if they don't run on the main CPU - if you find a bug in the drivers, you still can't fix it because it's almost certain to be in the bit for which you don't even have a disassembler or instruction set documentation, let alone source code. The real question is, what did Broadcom think was so important about their shim layer that they needed to keep it closed source in the first place?
Re:I'm confused by ebenupton · 2012-10-24 02:22 · Score: 2, Informative

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:Hardware codec licenses by ebenupton · 2012-10-24 02:26 · Score: 2

That is correct. Like many other pieces of hardware with open-source drivers, when you get down to it there's a chunk of microcode in ROM or RAM (ours lives on the SD card) which makes the hardware spring into life and talk to the open source stuff. The codec licensing stuff lives in there.
Re:Count me stunned by Archangel+Michael · 2012-10-24 03:14 · Score: 2

This assumes isolation of course. If it is more "expensive" but you end up selling a shit ton more than you would have otherwise, it is possible that it is indeed less expensive (more profitable) to open it up, even if it doesn't appear to be at the start. However, all of that is predicated upon knowing both outcomes beforehand. However, it should be possible to know how much more you'd have to sell before you reach the break even point is.

--
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Re:Count me stunned by drinkypoo · 2012-10-24 03:18 · Score: 4, Informative

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.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Meh by mfwitten · 2012-10-24 04:22 · Score: 2

As Luc Verhaegen points out in the blog comments, the code they just released is doesn't do any real, interesting work; for instance, the real work of glClear is done by making a "remote procedure call" to the presumably proprietary glClear_impl:
GL_API void GL_APIENTRY glClear (GLbitfield mask) { CLIENT_THREAD_STATE_T *thread = CLIENT_GET_THREAD_STATE(); if (IS_OPENGLES_11_OR_20(thread)) { GLXX_CLIENT_STATE_T *state = GLXX_GET_CLIENT_STATE(thread);
if (state->render_callback) state->render_callback();
RPC_CALL1(glClear_impl, thread, GLCLEAR_ID, RPC_BITFIELD(mask)); } }
Nevertheless, I suppose that what they did release will be helpful to most higher-level projects.
Re:Count me stunned by lkcl · 2012-10-24 06:19 · Score: 3, Informative

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.
Broadcom began supporting open-source in 2010 by Xtifr · 2012-10-24 06:39 · Score: 3, Funny

Broadcom broke down and released open-source drivers for Linux back in Sept. of 2010. See LWN. They then joined the Linux Foundation in early 2011 (reference).
Their reputation for being open-source-hostile is well-deserved, but not entirely up-to-date. I can understand why people continue to avoid them, but it may not be strictly necessary any more. I haven't researched how well their open-source drivers work, because I haven't needed to in the brief period of time that it's been an option, so that may or may not be a factor as well.