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.
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.'"
Obviously this is great news for open source, and especially awesome for the RPi project and all associated hobbyists... I'm just amazed that Broadcom, a company with a long-renowned disdain for revealing the specs on anything, had anything to do with this. Does anyone have more information on how this process came about? Reading the blurb I see that the videocore firmware is still closed, but operationally I don't think that's much of an issue.
Apologies if it's in the video, I cannae watch it at work cap'n! But I'll offer a tentative thank-you to Broadcom and props to the RPi team for what was probably an awful lot of arm-twisting!
Moderation Total: -1 Troll, +3 Goat
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.
"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.
From a security standpoint, the presence of closed source code allows for the inclusion of malware. Any government that can bully its people (or subjects in the case of the UK) into acting against their will can force them to include spyware or worse and make them keep quiet about it. But when the code is open source and we users can compile and install it, no such coercions are possible. All that remains is detectable vulnerabilities in the code.
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?
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.
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.
I guess this means there's no holding back for openbsd on the pi.
If everything is open soure how are the licenses for the codecs handled?
So the directory is called "/userland" and the code it contains for VCHIQ (the GPU driver) *appears* to be userland side - it does open, ioctl, etc. I'm not seeing any code that receives ioctls, nor any code that does virtual-to-physical mapping, or any register-writing. So if all the ARM code is opensource now, where is the VCHIQ kernel driver?
I infer from the comments on the Rasp Pi site that the GPU itself implements OpenGL, so passing messages to the GPU *is* the low-level interface. Correct? So all we're going to see is wrappers that send messages, not any "this register performs this task" kind of thing, or any explicit command-buffer type access? I guess the VCHIQ driver code would illuminate this question.
If you want more sales, get the open source crowd on board. Plain and simple marketing strategy.
Sadly it seems the only way to see the video is to use the adobe flash plugin which is not open source. Is there some alternative trick that can be used to see the video with open source software?
--continuing clipped message--
I hope this will be just the start of a new era in broadcom that they do release and open things up, so that some serious open development can take place.
Having worked with some of Broadcom's SoC code in (closed source) projects and having had to debug it. I'm surprised they're brave enough to put it in to the public domain. I suspect that's why there's been a delay.They've been sorting it out!
What Broadcom gives us? Well, I have the datasheet downloaded from somewhere else because I couldn't find a link on their Website and thats it. Where are all the docs?
On the other side of an NDA associated with an order of what was the quote? At least 10,000 units? Maybe it was 100k, but ISTR 10k.
I'm not all that upset about not getting the firmware code. This is the part that is necessary to be able to do things. Maybe not to fix things, but at least to do things. This is a very big deal.
The lack of documentation is distressing, but it's not a stopping point, only an inconvenience.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
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.
With this code release, the GPU is still 100% closed source. Only thing that's remarkable is that the GPU is so general-purpose that it can run even the shader compilers in itself. The ARM-part of the system doesn't do anything, it merely sends the requests via a dedicated RPC-method.
If this kind of "freedom" gets popular, I expect that graphics cards could easily integrate a small ARM-core with proprietary firmware to handle high-level OpenGL processing, and leave just a light shim to the main CPU.
Result? Same as binary-drivers, albeit the kernel doesn't complain about non-GPL modules. Kernel gets littered with one-shot RPC-implementations and display drivers (running on GPUs) still crash, hide security issues and are impossible to debug.
This is the system I'm watching, http://cubieboard.org/ 1GHz ARM cortex-A8, Mali400, 1GB RAM, Ethernet, USB, SATA, $49. I would need to learn more about both to compare GPIO. From their web page (and links), they've shipped one batch, getting ready to ship another, and larger batch in about a month.
If Cubieboard was available now I would have picked one up, but with the Raspberry Pi upgraded to 512MB and this source code release it's going to be a much more difficult choice with that SATA weighing very much on the Cubieboard side.
How do you get 5v onto this friggin' thing?!? Of all the possible choices for a power jack, they chose *that*? Then if you cut a USB cable and solder it to a PC ATX connector, there're the poly fuses that drop 5v down to something that doesn't work... argh! I'd love to love this thing, but so far I'm hating it.