Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Open Source

Video ARM Code for Raspberry Pi Goes Open Source (Video) 91

Video no longer available.
"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.

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.

This discussion has been archived. No new comments can be posted.

ARM Code for Raspberry Pi Goes Open Source (Video)

Comments Filter:
  • Hallelujah (Score:5, Interesting)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday October 24, 2012 @09:00AM (#41750917) Homepage Journal

    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.

  • Not the first. (Score:3, Interesting)

    by Anonymous Coward on Wednesday October 24, 2012 @09:15AM (#41751025)

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

  • by Anonymous Coward on Wednesday October 24, 2012 @09:44AM (#41751297)

    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.

  • by brian.swetland ( 1739666 ) on Wednesday October 24, 2012 @10:17AM (#41751705)

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

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Working...