Video ARM Code for Raspberry Pi Goes Open Source (Video) 91
Slashdot: Alex, we're talking today about open sourcing parts of the
code that run the Raspberry Pi, simply the BCM2835 chip. Can you talk a little bit about what that chip does?
Alex: Sure. So the 2835, that's the core system-on-chip, which is comprised
essentially, the whole of the Raspberry Pi in a sense, in that you've got on there the ARM, the GPU,
and that the various libraries that are used to access that GPU by OpenGL-ES or OpenPG.
Slashdot: And how much closed-source code is actually used to run
the Raspberry Pi right now? In other words, how much is not already open source? I think a lot of people are under the
misimpression that the Raspberry Pi is an entirely open source project because it is so Linux centric and there's been so much open source involvement.
Alex: Yeah. Certainly we had, I mean, a substantial amount of it is open source. 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.
Slashdot: And is there new functionality that will -- either immediately or that you anticipate will -- be opened up by having this, the ARM side of the software stack being open source?
Alex: I think that in the near future it's going to make it a lot easier to
get things like native Wayland implementations working because of the EGL implantations being opened up, which allows
programmers to implement the Wayland platform requirements using the toolkits which we already have available. I mean, in general, I think it's going to make it much easier to work with the existing open source Linux stack, because quite understandably most people working graphics on Linux, it's all very centric around MESA and Gallium, the existing open source projects. It's very difficult to work with libraries which are closed and which they're constantly adding features to. Well, we've solved that problem now, and hopefully we'll start to see more people porting that technology to use Raspberry Pi.
Slashdot: Now you mentioned the GPL and BSD licenses are used extensively. What license is the new code or anything that's being open sourced now, is it all going be under the GPL?
Alex: It's all 3-clause BSD.
Slashdot: Okay.
Alex: So the reason, so the stuff we use in the kernel module is BCHIQ,
which is basically the machinery required to create a layer between the user space graphics driver implementation and
the video core. So that's actually dual GPL and BSD, to be friendly to the BSD guys. Now that we've got all the user space stuff also BSD, which is a very, very permissive license, we anticipate it will be very useful to people who are wanting to port -- other people who are working on FreeBSD, NetBSD, Haiku, Plan 9, RISCOS, etc.
Slashdot: Has there been, to your knowledge, much sort of cross pollenization of the existing code that's under that license?
Alex: How do you mean by cross pollenization?
Slashdot: Have any of those projects you just named, have they been interacting with Raspberry Pi developers? You just named several big . . .
Alex: Oh yeah. We have had that to a certain extent, certainly reports on . . .
they've been working with us on further developing through the API for doing low-level graphics, they've tried to build, you know, bring up their platforms. We've actually started to see patches reaching the mainline Linux kernel to start to provide platform support for the Raspberry Pi. We have a ways to go there, but that's something we're keen on pushing. I think we'll start to see much more collaboration with those projects with this open-source code. And we've also seen people who've been [hacking] on all the various device drivers, USB in particular. There's a Plan 9 guy, he got pretty far in doing a crash-free implementation implementation of the USB driver, which
is going to be interesting to a lot of people because it's currently rather large and difficult to do.
Slashdot: Now, one thing, the term "open source" can mean a lot of
things. In what way will this code that you're talking about open sourcing now on the ARM side of the stack be accessible to either developers, other programmers? Is it going to be, say, in
a public facing Git repository? Or will it be distributed on request? How will the Raspberry Pi project get that open source goodness out to other people?
Alex: Yeah, totally, fully, 100% OSI, FSF compliant, open source Free Software. So it's available under a BSD license. We have a GitHub repository -- do your standard "Clone it, send your patches," or pull
requests or whatever. Exactly what we do regarding opening up the development process, that's always quite difficult for us because when you have people who are contributing in their spare time, working on things, they don't always want to make promises they can't keep. So that's quite difficult too. We have to
strike a balance there between talking about what we're actually working on and making sense of people's disappointment.
Slashdot: Now, Alex, Eben Upton basically described you as the
project's Linux guru. Is there a team of people involved, both inside and outside Raspberry Pi, in making this open-source release happen? Or how many people are involved?
Alex: There's a small handful who've been involved in this open-source
release particularly. I mean, the main issue as with most of these open-sourcing efforts, is, of course, working through all the necessary legals, persuading the people who matter that actually there's not going to be a really big downside for not releasing access. They're not good at giving away valuable IP which is
going to downturn market position. So I think most of the work's being done with people like Eben, talking with Broadcom executives. Beyond that, there is a small handful of protocol engineers who then very generously give their time, and they've done the necessary legwork on cleaning up the code and making sure that it's ready for public distribution.
Slashdot: From that, it doesn't sound like you've faced a whole lot
of resistance in opening this code. Is that true?
Alex: Well, my understanding is that it's something which has taken a long
time. So it's been a slow process, but I think that it's partially due to the way that the video core is structured,
whereby most of stuff which runs in user space is pretty much just a serialization of your GL request and then it sends it over to the video core. So there's still plenty of stuff on the video core side, which remains private. I think that structure makes it more palatable.
Slashdot: You describe this as a process, and it's obviously got
both the actual development work, with the programming, coming up with open-source alternatives to closed-source options in some cases, and the licensing. What is the timeline going forward? Is this announcement, is there going to be a big 'We've open sourced all the ARM stuff" that is going to hit users immediately? If someone has a Raspberry Pi already, will they in the month of December be downloading a patch? What goes on for users from this point? For developers as well, for that matter?
Alex: Okay. Well, the big announcement is going to be on Wednesday, and the
GitHub repository will go public and everybody can clone it to their heart's content and get hacking. I would say that there might not be an immediate difference to users. But what we'll see over the next few months is better integration with the open source with its graphics stack.
Slashdot: Okay. What's the most exciting aspect of this?
Alex: Well, for me, I think that this is a major announcement in that this is the first [open-source driven] SOC. Broadcom was the first vendor to fully open source their user space graphics drivers. So I think its a pretty major step for embedded Linux.
People have been campaigning for, or begging for, for Mali
drivers, the Adreno drivers and so on. So I hope that this is a step that other companies will look at it, they'll see the
benefits which we're hoping to accrue over the next few months, and hopefully we'll start to see others following in our
footsteps.
Re:Count me stunned (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.
Re:Count me stunned (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 ;-).
Re:Count me stunned (Score:3, 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:Looks like the heavy lifting is done elsewhere (Score:3, 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:Extremely Good News (Score:2, Insightful)
Which begs the question, how do you know what your dog's asshole tastes like?
Re:Hallelujah (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 [github.com]
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.