Slashdot Mirror
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.
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
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 ;-).
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?
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.
Which begs the question, how do you know what your dog's asshole tastes like?
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.