Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

ARM Code for Raspberry Pi Goes Open Source (Video)

Roblimo posted about 2 years ago | from the more-open-than-ever-before dept.

Open Source 91

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

Sorry! There are no comments related to the filter you selected.

I've been waiting for this (-1, Offtopic)

Anonymous Coward | about 2 years ago | (#41750897)

Finally!
This made my commute to work later a whole lot easier on my day.

Hallelujah (4, Interesting)

drinkypoo (153816) | about 2 years ago | (#41750917)

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.

Re:Hallelujah (3, Insightful)

DeTech (2589785) | about 2 years ago | (#41757301)

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.

Re:Hallelujah (1)

drinkypoo (153816) | about 2 years ago | (#41762571)

While you are entirely correct about that, I don't feel robbed; ISTR always being told that there would be binary blobs. We're talking about Broadcom, so that was always what to assume. On the other hand, I always had the impression that the kernel and the user space video driver would both be open source. Now they are. The only thing remaining is that we continue to get firmware updates, and that the interface be documented. This is what is needed to actually use the blob, which is enough for me for this piece of hardware on which I spent very little money. If I am grumpy about one thing, it is that they almost certainly knew the device would be moving to 512MB before they announced it. I understand why one would make that decision, but it doesn't make me happy, especially since I've got a 256MB version. I was extremely unhappy with the purchase process, slipped ship date, false reporting of stock on hand et cetera, and won't buy another one until they're available from some more competent and honest supplier.*

I feel that so far, we are well on the road to all the promises actually made being honored, with steady if perhaps sometimes frustrating progress. Would it be nice to have more? Of course. Maybe one day we'll get there with some piece of hardware. In the mean time what I would like is more openness of the process, which I realize requires signoff from Broadcom on each announcement.

* Newark, never again. And I'm not doing it for these unreasonable shipping costs again. That's why I gave the VIA APC a miss; they contacted me as I had given them my email address, wanting $30 shipping on a $50 board. Uh no. But the Pi is almost as bad, with $15 on a $35 board.

Count me stunned (1)

MrNemesis (587188) | about 2 years ago | (#41750927)

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!

Re:Count me stunned (5, Informative)

Unknown Lamer (78415) | about 2 years ago | (#41750961)

Hiding under the video is a "Hide/Show Transcript" link that displays a full transcript if you can't watch the video (or just prefer reading).

Re:Count me stunned (1)

MrNemesis (587188) | about 2 years ago | (#41751079)

Many thanks, I'd skipped straight to the RPi page and missed the now glaringly obvious transcript button.

Re:Count me stunned (5, Funny)

fuzzyfuzzyfungus (1223518) | about 2 years ago | (#41751055)

I'm told that authorities are awaiting the results of an MRI for confirmation; but there are strong suspicions that Richard Stallman succeeded in burrowing in to Scott A. McGregor, concealing himself inside the host body, and gradually subverting the host's central nervous system.

Re:Count me stunned (5, Insightful)

marcosdumay (620877) | about 2 years ago | (#41751129)

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 (4, Informative)

drinkypoo (153816) | about 2 years ago | (#41752643)

A lot of people have been complaining very loudly about this, because they announced that they had ICS running two months ago and there's been nothing released since, and the community has been unable to assist because not only has there not been any source release, but they haven't even released the videocore binary. Well, here's the sources needed to make it happen.

For the last month or so, I have been advocating the alternatives to the R-Pi specifically because the graphics driver has not only been closed, but has had an inadequate release schedule. This release should address that issue nicely.

Re:Count me stunned (3, Informative)

lkcl (517947) | about 2 years ago | (#41754929)

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.

yes, that's the whole point. you play one company off against the other. the first one that *actually* goes and releases full GPL-compliant source code of their 3D GPU for example, i will INSTANTLY be recommending it to our clients. our clients are PRC State-Sponsored companies: one of them has a production capacity of 20 million units a *week*.

regarding the A10: *sigh* yeah i know. they can't actually release the source code of MALI, because that's locked down by ARM playing silly-buggers, including deleting public requests on ARM's forums for them to release the source code, *and* despite loads of ARM employees repeatedly advising ARM that releasing the source code is in ARM's best interests.

so we have to rely on the limadriver project, basically, which is making good progress.

we know that Allwinner made a promise to look at releasing the source code of the CedarX audio/video engine, but again, there, i think there will be more mileage out of reverse-engineering it. a "wrapper" has been written which traps system calls, giving a clear idea of what's going on.

the last part, the DDR3 "setup" phase, has already been reverse-engineered. it was a few hundred lines of assembler, that's all. so, the boot process is at least entirely free software.

Re:Count me stunned (1)

marcosdumay (620877) | about 2 years ago | (#41757419)

the first one that *actually* goes and releases full GPL-compliant source code of their 3D GPU for example, i will INSTANTLY be recommending it to our clients.

If it was that easy... It seems that the Allwinner doesn't sell the A10 outside of China, and the boards I can find with it just don't have a good GPIO. As far as I know, there is no Raspberry Pi equivalent using the A10.

It probably won't be a problem for your client that is sponsored by the PRC, but it will limit the spread of the chip. Still, it seems to be enough to scare Broadcom, so we win.

Cubieboard? Re:Count me stunned (1)

dfries (466073) | about 2 years ago | (#41760485)

As far as I know, there is no Raspberry Pi equivalent using the A10.

This is the system I'm watching, [cubieboard.org] http://cubieboard.org/ [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.

Re:Cubieboard? Re:Count me stunned (1)

Anonymous Coward | about 2 years ago | (#41762625)

"kickstarter" like project for the cubieboard up too ...
http://www.indiegogo.com/cubieboard?c=home

Re:Cubieboard? Re:Count me stunned (1)

marcosdumay (620877) | about 2 years ago | (#41763579)

Thanks. It was about time somebody made a good board from that chip. Now I'll look closer for their promissed open source GPU driver :)

(But yeah, I've already brought a Pi. Maybe I'll want another in the future, and it could be this board, maybe not.)

Re:Count me stunned (3, Insightful)

Alwin Henseler (640539) | about 2 years ago | (#41751273)

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 (2, Insightful)

makomk (752139) | about 2 years ago | (#41751421)

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:Count me stunned (1)

Narishma (822073) | about 2 years ago | (#41751605)

It's more expensive to open it than to keep it closed, even if there's nothing valuable in it.

Re:Count me stunned (2)

Archangel Michael (180766) | about 2 years ago | (#41752593)

This assumes isolation of course. If it is more "expensive" but you end up selling a shit ton more than you would have otherwise, it is possible that it is indeed less expensive (more profitable) to open it up, even if it doesn't appear to be at the start. However, all of that is predicated upon knowing both outcomes beforehand. However, it should be possible to know how much more you'd have to sell before you reach the break even point is.

Re:Count me stunned (1)

MightyMartian (840721) | about 2 years ago | (#41751619)

Perhaps Broadcom believed that the driver specs were the only thing standing between us and the zombie apocalypse.

Re:Count me stunned (1)

Anonymous Coward | about 2 years ago | (#41753295)

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?

The intention is not necessary to keep it hidden but rather to enforce that the end user accesses the hardware in the correct way. By not opening up the extra layer they can use that layer to create compatible workarounds if they later on find hardware bugs. Now that they have opened it up they no longer have complete control over the usage so someone could be accessing the hardware directly. If they now need to meddle with the OpenGL data there might be users that gets their stuff broken because they accessed the hardware in the "wrong way". For the open source community this is not a big deal for broadcom since they can just say that the end user have to change their code but if broadcom is more used to deal with companies they are probably used to be in a position where the customer demands that they pay for any extra development work that has to be done because of hardware problems. The binary blob software layer gives them the ability to fix the problem on their own terms.
It's neither a matter of malice nor a matter of incompetence, they are just being overly cautious.

Re:Count me stunned (1)

K. S. Kyosuke (729550) | about 2 years ago | (#41755151)

Now that they have opened it up they no longer have complete control over the usage so someone could be accessing the hardware directly.

That's a load of crap. Just because the Linux kernel and device drivers are GPL'd doesn't mean that there are dozens of office suites displaying document pages by writing into graphics card registers. In fact, I don't know anyone doing any such thing. People are still going through the drivers.

Re:Count me stunned (1)

rephlex (96882) | about 2 years ago | (#41761419)

This was modded as a troll? I don't think so.

Re:Count me stunned (1)

marcansoft (727665) | about 2 years ago | (#41763313)

I've checked the code, and this is in fact the case. All it does is marshal the function arguments into a buffer and send them off into the GPU core, for every OpenGL function.

For the people who want open drivers because of e.g. linking problems, the ability to rebuild them, ABI issues, etc, this is good. For the people who want open drivers to improve them, fix bugs, see how they work, add new APIs, etc., this is useless. It certainly isn't an "open source driver"; it's just "open source ARM libraries". Broadcom is just as closed as always, they're just getting better at making that closedness play nicer with open source folks.

Personally, I would be happier with a platform that implements graphics like this than with a platform where the userspace blob is where the fun is and will never get open sourced (like most other embedded Linux platforms), but I still won't be buying a Pi. There's something about booting via the GPU blob that still disgusts me - I shouldn't have to use their proprietary firmware to just boot Linux. If only they hadn't made the boneheaded decision to design an SoC that boots from the GPU core, and instead booted using the ARM CPU like everyone else, then we could just throw their GPU "firmware" in /lib/firmware like everything other device driver does and I'd be perfectly happy.

Re:Count me stunned (1)

Andy Dodd (701) | about 2 years ago | (#41752101)

Yeah... I have been avoiding the RPi due to Broadcom's long history of treating the open source community like shit... This is something I NEVER expected to see coming from them.

I'll be ordering a Pi tonight.

Broadcom began supporting open-source in 2010 (3, Funny)

Xtifr (1323) | about 2 years ago | (#41755171)

Broadcom broke down and released open-source drivers for Linux back in Sept. of 2010. See LWN [lwn.net] . They then joined the Linux Foundation in early 2011 (reference [zdnet.com] ).

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.

Extremely Good News (2)

folderol (1965326) | about 2 years ago | (#41750977)

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.

Re:Extremely Good News (0)

Anonymous Coward | about 2 years ago | (#41751005)

I'm not even a big Linux geek, but I think I need to change my shorts. This is huge.

Re:Extremely Good News (0)

Anonymous Coward | about 2 years ago | (#41751131)

To quote the great Joe "your drunk uncle" Biden, "This is a big fucking deal."

I'm a moderate Linux geek, not a RaspberryPi or even an ARM nerd, and I'm now convinced I need a dozen or so of these around the house.

Damn, how's that RaspberryPi taste? Tastes like freedom.

Re:Extremely Good News (-1)

Anonymous Coward | about 2 years ago | (#41752351)

Umm, only if freedom tastes like my dog's asshole.

Re:Extremely Good News (1, Insightful)

iplayfast (166447) | about 2 years ago | (#41752847)

Which begs the question, how do you know what your dog's asshole tastes like?

Re:Extremely Good News (0)

Anonymous Coward | about 2 years ago | (#41754595)

You know that not-so-fresh feeling you get in your mouth when installing Windows...

Same thing.

Re:Extremely Good News (2)

chill (34294) | about 2 years ago | (#41751315)

This *partially* changes the ball game. ARM isn't a chip, it is a CPU component on the processor. The "chip" is comprised of many different parts, like Legos. That is why it is called a System on a Chip (SoC).

Other components, for example the GPU, are still very proprietary and closed.

Re:Extremely Good News (1)

robmv (855035) | about 2 years ago | (#41751547)

Raspberry Pi is the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers, and that Broadcom is the first vendor to open their mobile GPU drivers up in this way

By ARM code they mean code compiled for the ARM CPU, the GPU drivers are compiled for the ARM CPU. GPU firmware is another thing

Re:Extremely Good News (2)

amiga3D (567632) | about 2 years ago | (#41751853)

It's a step. Another step towards freedom. We may not get there all at once but if we keep taking steps we'll make it eventually. This is a big step.

Re:Extremely Good News (1)

ebenupton (2424660) | about 2 years ago | (#41751955)

Absolutely agree with the sentiment here. Hopefully one day someone will produce a decent GPU that's free down to the Verilog level, but until then we'll have to keep taking one step at a time.

Re:Extremely Good News (1)

rufty_tufty (888596) | about 2 years ago | (#41752425)

Hopefully one day someone will produce a decent GPU that's free down to the Verilog level

You raise an interesting point, but how would you make money from it? AFAICT current open source software companies make their money from consultancy rather than the actual product. Also things like opencores never really got much momentum behind them thanks to the twitchy legal departments.

I think the bigger problem though is you'd need the tool chain to go with it, so perhaps the first step would be an open source verilog simulator and debugger. There's no hardware equivalent of gcc.
I don't know this would happen any time soon because you need engineers who are equally good at hardware and software. Massively parallel software being notoriously difficult to write!

Re:Extremely Good News (1)

Type44Q (1233630) | about 2 years ago | (#41752863)

You raise an interesting point, but how would you make money from it?

I'm sure the Chinese will be more than happy to demonstrate the answer to that question...

Re:Extremely Good News (1)

drinkypoo (153816) | about 2 years ago | (#41754139)

Hopefully one day someone will produce a decent GPU that's free down to the Verilog level

You raise an interesting point, but how would you make money from it?

Be first to market. Have the product on the market for six months or more before releasing the sources. Be a major vendor with partnerships with OEMs that will get the device into products, and further, with partners who will buy the chips from you even if another source crops up, at least for long enough for you to recoup your costs, probably protected by contract. Having the VHDL for a really complex GPU is only the first step to actually having a product on the market.

Re:Extremely Good News (1)

hattig (47930) | about 2 years ago | (#41751973)

Other components, for example the GPU, are still very proprietary and closed.

From raspberry pi blog:

As of right now, all of the VideoCore driver code which runs on the ARM is available under a FOSS license (3-Clause BSD to be precise). The source is available from our new userland repository on GitHub. If you’re not familiar with the status of open source drivers on ARM SoCs this announcement may not seem like such a big deal, but it does actually mean that the BCM2835 used in the Raspberry Pi is the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers, and that Broadcom is the first vendor to open their mobile GPU drivers up in this way.

Yup, that's the GPU.
Now the question is how much of the work is done by the firmware on the GPU rather than the driver running on the CPU?

Re:Extremely Good News (3, Informative)

ebenupton (2424660) | about 2 years ago | (#41752699)

Now the question is how much of the work is done by the firmware on the GPU rather than the driver running on the CPU?

Easy answer - the majority of the intricate register-level work is done by the firmware, rather than by the driver. This is how we've been able to reconcile the legitimate interests of Broadcom in keeping the fine detail of the implementation private, while also providing a workable FOSS driver suitable for use in (for example) porting other operating systems to the Pi.

Re:Extremely Good News (1)

hattig (47930) | about 2 years ago | (#41753939)

Would you say this is the way forward for other GPU vendors to offer open source drivers - by embedding the actual implementation within the chip itself? Does this also have a benefit in offloading the high-level processing from the system CPU by running that within the GPU as well?

Does the VideoCore IV also incorporate it's own CPU-function that the embedded firmware runs on (I believe the VideoCore lines are fully fledged CPUs in their own right, with large vector/dsp/etc engines? Therefore it's the engines that are totally hidden, with the GPU presenting an API that maps very closely to operations within OpenGL?).

Not the first. (3, Interesting)

Anonymous Coward | about 2 years ago | (#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.

Re:Not the first. (0, Offtopic)

Anonymous Coward | about 2 years ago | (#41751249)

Whoever modded this down: I wrote the entire build scripts for these, including with the bootloaders, and there are no non-open components required to bring the chips up and use any ARM-related components.

If you're going to implicitly accuse the poster of being a liar by downmodding, please post some counter-evidence rather than just being a jackass.

Re:Not the first. (2)

ebenupton (2424660) | about 2 years ago | (#41751665)

Sorry - slightly loose use of language in the post on the blog. I wouldn't consider the DaVinci to be a "multimedia SoC" because it doesn't have a 3d accelerator. YMMV however, and there are certainly several examples of video-only ARM SoCs with FOSS driver stacks.

Re:Not the first. (0)

Anonymous Coward | about 2 years ago | (#41758065)

All DaVinci lines have models with PowerVR 3D accelerators.

Re:Not the first. (2)

Andy Dodd (701) | about 2 years ago | (#41752143)

That's not really a multimedia SoC - it has no GPU.

It doesn't have a PVR subcomponent, so it manages to be fully open-source by not having a GPU... Which is the component that is usually closed-source.

This announcement is the first example of a GPU with open source support.

This is a bigger deal than u know. (0)

Anonymous Coward | about 2 years ago | (#41751065)

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.

Interesting, interesting... (2)

fuzzyfuzzyfungus (1223518) | about 2 years ago | (#41751111)

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?

Re:Interesting, interesting... (4, Informative)

ebenupton (2424660) | about 2 years ago | (#41751859)

Actually, if you look at Broadcom's recent behaviour around Bluetooth drivers, I think there's good (public) evidence of a sea change in the attitude towards open source.

Re:Interesting, interesting... (1)

drinkypoo (153816) | about 2 years ago | (#41752829)

I for one would definitely welcome more broadcom participation in open source. For example, there's some routers which aren't supported by alternative firmwares because they use one bcm chip or another. It's hard to see how that would help them sell more parts, though :)

Looks like the heavy lifting is done elsewhere (5, Informative)

brian.swetland (1739666) | about 2 years ago | (#41751211)

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.

Looks like the heavy hiding is done elsewhere (2, Interesting)

Anonymous Coward | about 2 years ago | (#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.

Re:Looks like the heavy hiding is done elsewhere (2)

brian.swetland (1739666) | about 2 years ago | (#41751367)

To be fair, "open drivers / libraries plus proprietary firmware binary to download to hw block" is a better model than "closed userspace libraries/drivers" -- at least you have control/ownership over all the software running on the host side in this model.

Re:Looks like the heavy hiding is done elsewhere (4, Informative)

ebenupton (2424660) | about 2 years ago | (#41751581)

That was our feeling. This model is an order of magnitude easier to sell to the chip vendor, and provides all the benefits normally associated with open source drivers (provided the interface is adequately documented, which it will be in the near future).

Re:Looks like the heavy lifting is done elsewhere (4, Informative)

ebenupton (2424660) | about 2 years ago | (#41751537)

That's a fair observation. We're lucky that, with firmware installed, the VideoCore GPU exposes a much higher-level interface to the ARM side than some other architectures. This has allowed us to provide a viable, useful open source stack while also addressing Broadcom's (completely legitimate) interest in protecting the fine detail of the underlying IP from competitors and patent trolls.

To help people get the most out of this, we hope to sponsor some efforts to formally document the interface exposed by the GPU over the next few months.

Re:Looks like the heavy lifting is done elsewhere (4, Interesting)

brian.swetland (1739666) | about 2 years ago | (#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...

Re:Looks like the heavy lifting is done elsewhere (4, Informative)

ebenupton (2424660) | about 2 years ago | (#41752327)

Apart from purists who want to have source for every programmable block on the SoC, everybody wins.

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. Stallman is one of the few people who has a self-consistent model of what he wants to be able to see, arguing that code which is "equivalent to a circuit" (i.e. in ROM) need not be made visible. Now we don't meet this criterion as our microcode lives on the SD card, but that's largely a cost and flexibility issue and we may yet go there to get the FSF endorsement.

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

I should have kept some of my notes from those meetings :)

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

While I can't commit to this, I'm certainly a very vigorous advocate for this position, from a commercial and a community relations standpoint. Fingers crossed.

Re:Looks like the heavy lifting is done elsewhere (1)

brian.swetland (1739666) | about 2 years ago | (#41752503)

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. Stallman is one of the few people who has a self-consistent model of what he wants to be able to see, arguing that code which is "equivalent to a circuit" (i.e. in ROM) need not be made visible. Now we don't meet this criterion as our microcode lives on the SD card, but that's largely a cost and flexibility issue and we may yet go there to get the FSF endorsement.

I consider "ability to redistribute the firmware for use on the hardware it belongs to" totally reasonable, but I definitely fall into the more pragmatic camp.

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

I should have kept some of my notes from those meetings :)

I'm sure they were highly entertaining. Once upon a time I was involved in arguing with a SoC vendor's lawyers over the ability to open source *GPIO* driver support... progress in these areas can be amazingly hard to achieve...

Re:Looks like the heavy lifting is done elsewhere (2, Insightful)

makomk (752139) | about 2 years ago | (#41752517)

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:Looks like the heavy lifting is done elsewhere (1)

makomk (752139) | about 2 years ago | (#41752271)

The "much higher-level interface" is basically just the OpenGL ES API, though. For instance, this file [github.com] contains Broadcom's ARM-side code for the vast majority of the OpenGL ES API calls, and it literally just forwards them over RPC to the closed firmware running on the VideoCore GPU. Even shader compilation runs entirely on the closed VideoCore. As far as I can tell, the only thing that doesn't is context setup and buffer management, which appears to involve mucking with some undocumented and decidedly low-level datastructures shared with the VideoCore.

In terms of helping people to understand how it works - or more importantly why it isn't working for them - this provides about as much information as a proprietary blob. Either way you're blindly calling into someone else's closed implementation of OpenGL ES.

Re:Looks like the heavy lifting is done elsewhere (1)

brian.swetland (1739666) | about 2 years ago | (#41752553)

The biggest advantage here is that if the "top side" interfaces change, or something needs to change with how the library is compiled (say against glibc for a stock linux platform vs bionic for android), that's pretty trivial to resolve compared with getting a handful or .so or .ko binaries. And yeah, it doesn't help you fix the firmware if the firmware is busted, but it's still an improvement over where things were before, so hey, progress.

Re:Looks like the heavy lifting is done elsewhere (0)

Anonymous Coward | about 2 years ago | (#41752623)

from what ive seen so far, some files like interface/vmcs_host/vcilcs.c seem to handle both sides of the RPC
they use a #define to set it as being gpu or cpu side code
by using the same file for both sides of the rpc, it will always be compatible with itself, less maintenance

Re:Looks like the heavy lifting is done elsewhere (1)

makomk (752139) | about 2 years ago | (#41753035)

That doesn't surprise me. I suspect that some of the delay may have been due to Broadcom developing both sides of the driver as a single code base; the buffer management also looks like it might rely on them having similar code on both sides.

neat (1)

Anonymous Coward | about 2 years ago | (#41751369)

I guess this means there's no holding back for openbsd on the pi.

Hardware codec licenses (0)

Anonymous Coward | about 2 years ago | (#41751403)

If everything is open soure how are the licenses for the codecs handled?

Re:Hardware codec licenses (1)

slim (1652) | about 2 years ago | (#41751523)

The firmware is still a binary blob. My guess is that the codec support is controlled at that level.

Re:Hardware codec licenses (2)

ebenupton (2424660) | about 2 years ago | (#41751835)

That is correct. Like many other pieces of hardware with open-source drivers, when you get down to it there's a chunk of microcode in ROM or RAM (ours lives on the SD card) which makes the hardware spring into life and talk to the open source stuff. The codec licensing stuff lives in there.

I'm confused (1)

Anonymous Coward | about 2 years ago | (#41751461)

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.

Re:I'm confused (2, Informative)

ebenupton (2424660) | about 2 years ago | (#41751777)

You're correct. The VideoCore GPU exposes a fairly high-level interface to the ARM side, so passing messages *is* the interface. We're lucky that VideoCore provides for a good tradeoff between the Broadcom's legitimate desire to maintain a degree of secrecy around the register-level operation of the hardware (read concern about competitors and patent trolls) and FOSS users' need for source code access and control.

Re:I'm confused (0)

Anonymous Coward | about 2 years ago | (#41751965)

Thanks. So where's the kernel-mode code that sends the messages to the SoC (the code that the userland VCHIQ talks to?) Don't tell me the SoC implements ioctl too? :)

Re:I'm confused (1)

psergiu (67614) | about 2 years ago | (#41752085)

That is already included in the Linux kernel sources (GPL + BSD licence) available on the RPi kernel github: https://github.com/raspberrypi/linux [github.com]

Re:I'm confused (1)

Narishma (822073) | about 2 years ago | (#41752109)

That part was already open source. It's probably somewhere in here [github.com] .

Re:I'm confused (0)

Anonymous Coward | about 2 years ago | (#41752135)

https://github.com/raspberrypi/linux/tree/rpi-3.2.27/drivers/misc/vc04_services/interface

i had patched the kernel code in the past to dump all messages, so i could sniff the traffic
but with the userspace libs open, i dont need to anymore

Re:I'm confused (0)

Anonymous Coward | about 2 years ago | (#41752187)

the exact entrypoint for the ioctl is https://github.com/raspberrypi/linux/blob/rpi-3.2.27/drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c#L329

Re:I'm confused (0)

Anonymous Coward | about 2 years ago | (#41752347)

I can't ask for more than that! Thanks!

(And thanks to the other responders)

Re:I'm confused (1)

hattig (47930) | about 2 years ago | (#41752071)

Is there an OpenCL interface on the VideoCore IV? Can one be added by upgrading the firmware, or by implementing it in userland and RPC to a lower level interface on the VideoCore IV?

Hmmm, seems like a marketing ploy to me.. (0)

Anonymous Coward | about 2 years ago | (#41751541)

If you want more sales, get the open source crowd on board. Plain and simple marketing strategy.

Re:Hmmm, seems like a marketing ploy to me.. (1)

ebenupton (2424660) | about 2 years ago | (#41751799)

Bwahahaha? Making thing people want to buy considered devious plan to make people buy thing.

Re:Hmmm, seems like a marketing ploy to me.. (1)

psergiu (67614) | about 2 years ago | (#41751937)

And it works.
I'm going to order another Raspberry Pi because of this announcement.

way to see slashdot video with open source? (1, Offtopic)

lindi (634828) | about 2 years ago | (#41751811)

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?

Re:way to see slashdot video with open source? (0)

Anonymous Coward | about 2 years ago | (#41752063)

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?

Gnash?

Re:way to see slashdot video with open source? (0)

Anonymous Coward | about 2 years ago | (#41755373)

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?

Using an iPod user agent gets you html5 video.

Lies! (-1)

ultranerdz (1718606) | about 2 years ago | (#41752705)

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

This is obviously a lie. BCM2835 is not the first. This is just marketing buzz.

TI' OMAP and some other vendors SoC are 'open' for long time ago.

Also, I need to point out that in fact, they are just releasing the ARM code. There are several other parts on the SoC (like for example the video decoder) that they didn't include in this release and may not do so in the future.

You can go to Texas Instruments' OMAP website for example and download all the documentation, and completely open source SDKs, including all the ARM compatibility layer and everything you would need for software development on this SoC.

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?

I hope this will be just the start so they

Re:Lies! (1)

ultranerdz (1718606) | about 2 years ago | (#41752729)

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

Re:Lies! (1)

drinkypoo (153816) | about 2 years ago | (#41752917)

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.

Brave of them... (1)

Goth Biker Babe (311502) | about 2 years ago | (#41752759)

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!

Meh (2)

mfwitten (1906728) | about 2 years ago | (#41753455)

As Luc Verhaegen points out in the blog comments [raspberrypi.org] , 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" [github.com] 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.

Re:Meh (1)

mfwitten (1906728) | about 2 years ago | (#41753555)

Eben Upton has a pretty good response to this [raspberrypi.org] :

We happen to have a GPU which exposes a comparatively high level (GL-like) interface, such that many of our userland functions are message passing shims. You are dealing with a GPU which exposes a lower-level interface, so LIMA driver functions often boil down to writing registers directly. These are design decisions on the part of the respective GPU teams, which have wide-ranging implications for the software and hardware structure of the devices which use the resulting cores. The VideoCore driver isn’t structured this way to pull the wool over your eyes[;] it’s structured this way because of a genuine judgment that this is the best structure given the resources we have on the chip, which includes a vector DSP to which we can offload much of the low-level register access.

GPU is not open in any sense (1)

Anonymous Coward | about 2 years ago | (#41757003)

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.

I Wish The Raspi Power Connector Was Open Source (0)

Anonymous Coward | about 2 years ago | (#41767191)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?