Broadcom Releases Source For Graphics Stack; Raspberry Pi Sets Bounty For Port

One of the few but lingering complaints about the Raspberry Pi is that it relies on a proprietary GPU blob for communication between the graphics drivers and the hardware. Today, Broadcom released the full source for the OpenGL ES 1.1 and 2.0 driver stack for the Broadcom VideoCore IV 3D graphics subsystem running on one of its popular cellphone systems-on-a-chip. It's available under a BSD license, and Broadcom provided documentation for the graphics core as well. The SoC in question is similar to the one used on the Raspberry Pi, and Eben Upton says making a port should be 'relatively straightforward.' The Raspberry Pi Foundation has offered a $10,000 bounty for the first person who can demonstrate a functional port. (The test for functionality is, of course, being able to run Quake III Arena.) Upton says, 'This isn't the end of the road for us: there are still significant parts of the multimedia hardware on BCM2835 which are only accessible via the blob. But we're incredibly proud that VideoCore IV is the first publicly documented mobile graphics core, and hope this is the first step towards a blob-free future for Raspberry Pi.' Side note: the RPi is now two years old, and has sold 2.5 million units.

Comments

is the USB 'bug' fixed, at this point?

[TheGratefulNet]

I have given up on the rpi and moved to the BBB since I could not stand the issues related to the broken-by-design usb system.

since ethernet goes thru usb and usb was flawed, this really put a damper in my networking use of this box.

its been at least a year since I checked in; have they fully and completely gotton around the usb 'elephant' bug yet?

Re:is the USB 'bug' fixed, at this point?

[NoImNotNineVolt]

I have a Raspberry Pi and I use both Ethernet and USB extensively with no issues. What bug are you talking about?

Re:is the USB 'bug' fixed, at this point?

[ledow]

I'm not the OP, but:

The one that still had a ticket open.

If you slag the USB / Ethernet buses simultaneously, things nowadays slow to a crawl. Why? Because if they don't make them slow to a crawl, you drop USB packets silently, which makes the driver stack crash.

The bug was reported within weeks of release by a guy doing lots of USB / SD / Ethernet work simultaneously and I'm linked into it. Still unresolved, but they tweaked the "firmware" (really software) of the RPi to lessen the impact by degrading some performance.

It's a timing issue on the shared bus that's part of the hardware design and can't be "resolved" without a redesign. They just worked around it so that the blindingly-obvious bug when it was first released isn't so prevalant, but there's a cost.

My pre-order RPi ended up in my loft for 6 months after I waited a year for them to fix it (and also - on the request of some of the RPi designers / distributors - I had sent off SD cards to some guy at Broadcom who worked on the RPI "in his spare time" who then later discovered that it was because of things like this that SD cards weren't reading, not that they were old / strange cards). It's a nice gadget, but it is basically a bodge-job and for my use was useless for over 18 months without sight of permanent resolution.

Re:is the USB 'bug' fixed, at this point?

[Anonymous Coward]

The OTG host is now relatively bomb-proof as far as USB2.0 high-speed devices (i.e. onboard network) are concerned. Of course, performance and total throughput is never going to be on a par with EHCI hosts because, well, BCM2835 has an ARM11 performing the job that the EHCI controller otherwise does.

In the last few weeks a major rewrite has been pushed that, following some beta testing, should squash the remaining issues with the Achilles heel (USB1.1 devices on a USB2.0 host - via split transactions) and at least draw a line in the sand saying "these are the things that work flawlessly, and these are the things that will never work". The aim is to make the second set of devices an extremely small one.

Disclaimer: I am the guy that's spent the last 6 months slaving over a dual-port USB2.0/OTG analyzer figuring out *ALL* the damn bugs.

Re:is the USB 'bug' fixed, at this point?

[TheGratefulNet]

thanks for the info. so, the fundamental issue cannot be fixed and only by degrading the usb performance can they give higher reliability.

that just hammed the final nail into the rpi coffin, for me, anyway.

back to the beaglebone black, it seems. its fully open source (today), it runs both android and linux and has onboard flash enough so that you don't need sdcards (but can still use them).

a friend of mine also ported ubuntu 64 to the BBB. he claims it was not simple or easy task but he actually did get ubuntu64 up on the BBB.

Re:is the USB 'bug' fixed, at this point?

[YesIAmAScript]

I gave up on BBB and went to rpi because BBB couldn't come up with a distro that worked.

Got tired of dd'ing my SD storage space back to stock and starting over when the unit ceased to boot after installing another stock apt.

And that's assuming it even worked when clean which it didn't, at least not at first (I got one of the first batch).

Re:is the USB 'bug' fixed, at this point?

[wonkey_monkey]

That's nothing. Here's Ubuntu running on an 8-bit machine.

Re:is the USB 'bug' fixed, at this point?

[adri]

Hi,

Can you please email me? (adrian@freebsd.org) - we have a vested interest in getting the r-pi USB bugs ironed out on FreeBSD and would likely really benefit from the work you've done.

Thanks!

-adrian

Re:is the USB 'bug' fixed, at this point?

[ledow]

I live in the UK, but not Scotland.

The loft is a dry, dusty, windy place. Water does not get in. In fact, it's so dry that even in a thunderstorm you will cough from all the dust etc.

As such, mould, damp, mildew etc. aren't a problem in the loft (and, yes, we do have minor problems elsewhere in the house - like the porch - where condensation or water builds up. Not enough that you can see the water itself, but enough to promote some slow mould growth).

My house is a 1930's, double-brick walls all the way up, peaked timber roof (with plastic sheeting under tiles and definite air-gaps all the way around, i.e. you can poke your hand out of the loft into the open air).

It's just Scotland. Everything is permanently wet in Scotland. It's more the humidity than the actual rain as such. The rain rolls off the tiles here just the same. But my loft is horribly dusty and dry.

Communication?

[Anonymous Coward]

"One of the few but lingering complaints about the Raspberry Pi is that it relies on a proprietary GPU blob for communication between the graphics drivers and the hardware."

It wouldn't be so bad if this was the case. Unfortunately, closed GPU core is the main one in the device and the CPU is in fact a small, "slave core" in relation to the GPU. Without closed blobs running on the GPU, you cannot even boot CPU at all. Open OpenGL stack won't change that.

Re:Communication?

[Anonymous Coward]

Some people are never happy. Fortunately, with 2.5M sold, a lot of people are happy, and don't really care about propriety blobs.

This news reduces the size of the closed source code, but more importantly now means Android can be ported.

Re:Communication?

[ssam]

Looks like there are some parts (MPEG decoding) that will never be open. But there's a plan to make a open source firmware that is sufficient to boot.
http://www.raspberrypi.org/arc...

Re:Communication?

[maevius]

At this point, I have concluded that many slashdotters are "hipster geeks"

Anything that gains traction and is widely known outside of the normal geek circles becomes "uncool" and is slammed down. As you can see for raspberry, although the things to bitch about are getting fewer and fewer, there are always things that slashdotters bitch about. I'm pretty sure that even if they resolve everything, slashdotters will bitch about its color.

Now think what would happen if only a couple of thousand raspis were sold and only part of the geek community knew about it. It would be all the rage!

Re:Communication?

[maevius]

Sure it is. I don't see you bitching about your phone, pc, car, tv, microwave oven though. You do realise that after this announcement, videocore is the most open core on an ARM chip ever, right?

btw, http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf here you go...hack away

Let me get this straight...

[skids]

If I spend days writing a GPU core port, I MIGHT get $10,000, unless someone beat me to it.

I appreciate the injection of funds into the open source community, but that's no way to run an economy. Hire someone. If you want more than one implementation or you want to have it fast, hire multiple people and offer a bonus for completion. But if you do the latter, don't expect to actually use the first one you receive, as it will likely be the shoddiest, meeting the bare minimum of your specs.

Re:Let me get this straight...

[Anonymous Coward]

Who said it was to run an economy? It's a competition! Why should the foundation hire someone and blow a load of money? They don't need an OS driver, they have the existing one (which does everything they need for the primary purpose of the Foundation). It's the OSS 'community' that wants an OSS driver. Now they have the documentation they need and an added incentive to write one.

Re:Let me get this straight...

[johnsie]

I used to run competitively. I didn't always win, I just enjoyed doing it.

First Open Mobile Graphics Core???

[CajunArson]

Upton sez: "But we're incredibly proud that VideoCore IV is the first publicly documented mobile graphics core,"

Uh.. considering that the graphics cores in Baytrail tablet chips have had open source drivers in the mainline Linux kernel since at least early last year (the earliest commits may go all the way back to 2012), and considering that Intel's Gen7 graphics system is very well documented, I'd have to disagree there.

Re:Why don't they simply change CPU?

[Going_Digital]

Simple, RPi is a project created by Broadcom Employees.

Not actually sou

[david.given]

The Videocore IV on the Raspberry Pi (which totally kicks arse, BTW, it's a beautiful, beautiful processor. Did you know it's dual core?) currently doesn't have an open source compiler that's any good[*] which I'm aware of. I have tried porting gcc, and got a reasonable way into it, but ground to a halt because gcc. I know another guy who's similarly about half-way through an LLVM port. And Volker Barthelmann's excellent vbcc compiler has a VC4 prototype which makes superb code, but that's not open source at all.

Without a compiler, obviously the source isn't much good, although the VC4-specific code is really interesting to look through.

In addition, having done a really brief scan of the docs they've released, this isn't what the article's implying: what we've got here looks like the architecture manual for the QPU and the 3D engine. The QPU is the shader engine. Don't get me wrong, this is awesome, and will allow people to do stuff like compile their own shaders and do an OpenCL port, but I haven't seen any documentation relating to the VideoCore IV processor. The binary blob everyone complains about runs on that.

It does looks like the source dump contains a huge pile of stuff for the VC4, so maybe they're going to release more later. But even incomplete, this is a great step forward, and much kudos to Broadcom for doing this.

[*] I have done a really crap port of the Amsterdam Compiler Kit compiler for the VC4. It generates terrible, terrible code, but I have got stuff running on the Raspberry Pi bare metal. It's all rather ground to a halt because there's still a lot of stuff to figure out in the boot process, but interested parties may wish to visit http://cowlark.com/piface.

It works well enough, depending on your applicatio

[drosboro]

Depending on what you're trying to do, you may or may not ACTUALLY have any performance trouble with this bug. I've been using an rpi as a router / firewall / proxy / etc. in my home for about 1.5 years now. I'm using the Ethernet port, plus a USB -> Ethernet adapter to get a second port. Performance may not be spectacular, but it's still good enough to saturate my home (15-20mbps) connection, with about 8-10 devices on the other side. Not bad, for a device that cost (including case, power supply, SD card, and ethernet dongle) about $60. Granted, there's lots of applications for which the rpi is not well-suited - but basic home-networking stuff doesn't necessarily have to be written off.

Re:It works well enough, depending on your applica

[drosboro]

Well, I started off trying it out just to make sure I could get the software running the way I wanted to. My plan was to trial it with the rpi, and then move to "proper" hardware with dual ethernet ports eventually. But, as I mentioned, I'm saturating my connection with the rpi and a USB->Ethernet adapter, so I haven't seen any reason to move "up". Works great, draws very little power, and gives me all the speed I need. So, why wouldn't I?

That's nothing

[rsilvergun]

This guy's got it running on a dead badger.