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