Open Source ARM userland

Does this mean that we’ll get better/faster graphics processing, or is that something that is still in the future?

It’s not going to have an immediate impact on X acceleration, though as I say does make it possible to provide the necessary Wayland EGL support for hardware compositing. There’s still the problem of optimising client-side rendering of each window. Simon Hall has done some interesting work on XOrg that we’re working with him to package up.

I know someone would ask this :)

This won’t make much immediate difference to users.

I’m hoping in the long term that this will allow for better integration of Pi support in standard opensource libraries so Pi specific builds are no longer needed.

It does make a difference for the users, just not necessarily speed wise. The programmers/hackers that wanted to have their way with the code now finally can do what they want, and freedom of the architects means more freedom for the end users in the end, too =p
So who knows! Maybe someone will find a way to use the chip more efficiently, which will result in more speed; but regardless we’ll see more hacking/coding activity related to the chip/drivers.

Absolutely stunning! I’m so glad that Broadcom have released this code.

Agreed, this is really great news. Next step, open bootloader :)

sorry for spam, I’ve tried to post it in second browser (since first looked like it didn’t send it)

Agreed, next step is open bootloader :)

Not sure how likely that’s going to be? Doesn’t the bootloader enable the extra codec support? If the source was open, it would mean people could unlawfully enable all of the extra silicon on the chip without paying a license pretty trivially.

Well, a 2-stage bootloader would be nice – 1st propriatory stage initialize videocore and codec licenses, 2nd OSS stage boots actual kernel and enables cross-hardware Linux distros. Any healthy linux distro manages kernel version upgrade itself, and OSS bootloader is a must for that.

You can do this right now if you replace kernel.img with a suitable ARM bootloader. This sourcecode resease allows creating one that would display a graphical menu.

You said exactly what I was going to say!

Ok, “fully open-source drivers“! Don’t forget the very last word.

Anyway, it’s a very good project! Long live RPi!

Once again hitting the trolls under the belt, instead of feeding them. Shame on you!

You seem to be infatuated with trolls. Do you have a troll fetish or something?

A great day for open source community, good job Broadcom, hope others follow…

fantastic news! thank you pi team!

Fantastic news, thanks Broadcom and the Foundation.

Erm… Isn’t all the magic in the videocore blob? Isn’t the userland code you just made available the simple shim that passes messages and data back and forth to the huge blob running on the highly proprietary videocore dsp?

— the developer of the lima driver.

No.

There’s some microcode in the Videocore – not something you should confuse with an ARM-side blob, which could actually prevent you from understanding or modifying anything that your computer does. That microcode is effectively firmware.

Is the source code of the “firmware” available?

1) Do you know of any manufacturer releasing the firmware source code for any recent & powerfull 3D graphics silicon ?
2) Even if you have the source code (which i bet is mostly assembly for the multiple purposely-built CPUs and DSPs inside the VideoCore) what are you going to do with it ? There are no compilers :-)

Intel with their HD4000 series

Dear san – care to point me to the source code for the HD4000 firmware images (those burned on the on-board flash on the Intel video cards, because that’s what the VideoCore blob really is) ?

It’s not manufacturer-released, but there’s complete and fully working open source replacement firmware for most recent NVidia desktop GPUs. Yes, as in the actual firmware running on the GPU itself. From what I recall many of the major Linux distros actually use it by default if you install them on a machine with one of those GPUs. (And yes, in theory you should be able to cold-boot and use those GPU without using any closed source code, not even from Flash. The contents of the Flash ROM is mainly there for the benefit of the BIOS rather than the OS anyway.)

I’m not sure whether the Intel HD 4000 actually uses microcode. One thing’s for sure, though: the Intel GPU is fully programmable using the documentation and code that Intel has released, and even their H.264 decoder takes advantage of this. OTOH, VideoCore only lets you use the OpenGL implementation built into the firmware.

Links to source code please.
Thank you.

Does it REALLY have to take 5 attempts to post a simple comment? This comment system SUCKS!

For docs, search “intel linux graphics” and click “documentation”. It even has the shader instruction set, as well as how to program it.

For code search “mesa3d” and download that, then look at src/mesa/drivers/dri/i915.

I have an HD3000 and I assure you it beats the utter crap out of the nVIDIA GeForce FX5200 AGP from 2003, and I believe that Intel are definitely catching up fast.

what psergiu, you mean to say you dont write assembly or direct binary for the Science of Cambridge (SoC) or the newer Advanced RISC Machines CPU or the current ARM A8/A9/A15 with Advanced SIMD (NEON) assembly/direct binary code to get best performance and Fun education for best and brightest for the worlds ARM devices students to learn today ?

you can bet Luc Verhaegen is writing and dissembling some binary/assembly in his practical MALI ARM GPU reverse open source imitative so why aren’t you also teaching current arm assembly/direct binary code samples for the potential future OSS speed advantage that provides ?

all of them Sinclair,ARM,etc used and encouraged binary/assembly for young students to learn to make “Elite” the seminal space trading video game clones for fun back in the day for instance, why cant today’s students be helped to do the same to gain far better understanding in today’s current and future ARM cores and more to the point why where are all these old ARM tutors from back in the day and why are they not here helping the new students today ….

By “firmware” I guess you mean the software that us disgusting open source types are not allowed to look at or modify.

Not really, no. But keep trying to rustle up some outrage if it gives you a kick; I’d recommend finding something else to do soon, though. We don’t want you developing an ulcer.

http://libreplanet.org/wiki?title=Group:Hardware/Endorsement_criteria&oldid=23418

The GPU is an “auxiliary processors or low-level processor” under this categorization. We have been talking to the FSF all the way through this process, and we do not currently meet the FSF’s endorsement criterion:

“The exception applies to auxiliary processors or low-level processors, none of whose software is meant to be installed or changed by the user or by the seller.”

because we release new versions of the GPU binary from time to time.

We are investigating the possibility of producing a derived product, under a different brand (this would be necessary to satisfy the FSF), which will meet this criterion by storing a single GPU binary in an on-board serial ROM.

Am I allowed to be outraged by the fact that it’s not really open, since I see no mention of actual documentation for the hardware?

Or by this: http://www.raspberrypi.com/mpeg-2-license-key/ ? Can I get outraged by that?

Well you *could*, but you wouldn’t half look silly.

I, for one, would not buy that derived product. It’s much more convenient from me to do a firmware update/change by replacing a file on removable storage (like on the current RPi) than by reflasing a soldered SMD chip (non-replaceable) which has a limited number of write cycles and will brick the device if the flashing process fails.
As i see the issue, the SD card containing the GPU binary IS a serial (SPI) ROM (just move the R/O switch) so the RPi should be endorsed as-is by the FSF.

Its getting less friendly round here by the day :o(

Snigger @ “But keep trying to rustle up some outrage if it gives you a kick; I’d recommend finding something else to do soon, though. We don’t want you developing an ulcer.” Keep smiling, Liz!

I am sure you already are aware that even an FSF endorsed product would receive negativity. But just to drive home the point you can see an article that was linked in the article on H-Online.
http://lwn.net/Articles/460654/
That was another attempt to use the same “loophole”.

Does BCM2835 actually supports SPI NOR boot, and it is just disabled in on-chip OTP ROM of RaspberryPi? If it isn’t, could you just publish some bootable NOR images? IMHO NOR is more reliable and cheaper than SD card (don’t know eMMC cost). It could make sense to also put some opensource (better BSD licensed) ARM bootloader into the same SPI NOR, to allow USB- and netbooting by single shot. Or to have a placeholder for second SPI NOR chip on the PCB, to separate them.

Remark: NOR is _usually_ used as serial (because BCM2835 seems to have no 4-bit-wide NOR controller), besides being 4-bit-wide; but eMMC/SD is actually used in parallel mode (thank to dedicated eMMC controller), so they aren’t serial.

I can see that to you this seems like a perfectly legitimate ‘loophole’ to use and it seems like a compromise that you should get some credit for. But many dont see it that way, for good reason.

The only reason there is an exception for firmware is because, in the day that was written at least, firmware was effectively read only. You couldnt ship a buggy firmware and expect to just patch it over later without it being expensive and painful, you pretty much got one shot at it, and if there were problems you could paper over with a driver then at least having a free driver we can see the problem and how to work around it. There wasnt an expectation that the manufacturer could arbitrarily change the function of the device after sale through a firmware update. In those circumstances it makes sense to treat the firmware as unimportant.

When you effectively move your entire driver onto a coprocessor rig, running a completely opaque software stack with direct hardware access and start calling the shim a driver, that doesnt seem like a compromise to someone that actually cared about being able to audit their software stack, even if it’s technically compliant it’s still completely ‘useless’ as one commenter said.

The shim for which the source was just made available prevented nothing. If it was a worthwhile endeavour, it would be documented by a single person in a week or two.

Remember who you are talking to here, and i am currently talking to the developer of the freedreno driver, and the guy REing the tegra, and we are all shaking our heads in disgust over the brashness of this announcement.

Best example: glclear, line 471 of
https://github.com/raspberrypi/userland/blob/master/interface/khronos/glxx/glxx_client.c

RPC_CALL1(glClear_Impl, ….

A message passing shim, that’s what your userspace driver is.

>Remember who you are talking to here

Seriously?

Definitely. I have spent ages REing the mali GPU, i have worked with AMD on freeing ATI and getting (some) documentation out, i have removed BIOS dependencies all over the place. Google me.

>Remember who you are talking to here
Seriously?

Yes, Seriously.

>Yes, Seriously.

& both you and Luc should remember manners & politeness cost nothing

LV, spend ages? Google me? Developer of.., Remember-who-you-are-talking-to?

5 Years of working experience didn’t teach you manners.

Don’t mind the brazen kids Liz, keep up the good work!

http://tinyurl.com/yeah-seriously-liz

Luc, I have a feeling we may have to agree to disagree here. I legitimately believe this is a positive step forwards for FOSS and ARM GPUs. I totally accept that the architecture of the VideoCore makes it *much* easier for all of the ARM code to be opened up. However, it’s still a really useful milestone that you can now run the Raspberry Pi with full GL ES etc support without any non-FOSS running on the ARM. As Liz points out, if the VideoCore firmware were simply loaded from ROM we would actually be fully FSF/RMS compliant.

I have a sense of deja-vu here.

Just look for ‘b43’/’b43-legacy’ and how their developers have to maintain another tool ‘b43-fwcutter’ to ever get their f/w out of released-by-broadcom firmware blob.

Broadcom has a history of dumping this kind of stuff on the ‘surprised’ and ‘cheering’ FOSS communities.

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.

I can speak for the whole team when I say that we’ve been very impressed with the progress you’ve been making with Lima, but there’s really no need to come over here and cop an attitude.

I’m going to have to side with Luc on this one, sort of.

The reason people get excited when a graphics driver is open-sourced, besides the practical uses of the code, is that the company releasing the source is making a powerful statement by doing so. It takes a certain level of fortitude, confidence, and commitment to open-source philosophy to come out and say “We believe we can open-source our ‘secret sauce’ and still make money.” It’s a momentous occasion when it happens, because it encourages other companies to do the same.

Broadcom has not demonstrated this level of courage at all, because the “secret sauce” remains secret. The fact that it’s in firmware rather than in the kernel or in userspace is quite irrelevant. To date, only Intel (and to a lesser extent AMD) have been bad enough dudes to take that painful step of laying it all bare. Broadcom has not done this.

Now, I want to be quick to point out that I’m not saying “shame on you.” That would be hypocritical of me; I do own and use an Nvidia graphics card, after all. And this is absolutely a positive step; open-source code is still open-source code, after all. But it is absolutely a fact that the headline is writing checks reality can’t cash.

(And I don’t care much about what the FSF thinks either. The FSF thinks copylefted licenses promote freedom, which is like saying puddles promote dry shoes; total non-sequitur.)

@Max E: what you are saying is that you and others will not be happy until companies not just co-operate with open source, but adopt a completely different political philosophy to the time-tested business model that has underpinned their success.

That’s unrealistic.

The world is not going to go and abandon the fundamentals of economics as we have known them simply because a few IT people think it might just be a good idea. Broadcom is doing reasonably well under the capitalist model, as is the IT industry itself. It wasn’t the IT industry that caused the last/current recession, it was the cowboys of the financial industry (who arguably were also responsible for the .com bubble).

It is really very unfair to harass good people like the Raspi Foundation because you want it to serve your political goals that you’ve wrapped in layers of technical arguments. “This piece of code is free but tiny, irrelevant; that piece of code is still not free …” Etc etc until the paint starts to peel through sheer hot air.

Expecting the world to conform to your political beliefs is undemocratic and no amount of faceless DDoS attackers can change that.

If people want to make change within the current world economic and political boundaries, so be it. If Broadcom wants to keep it’s secret sauce just that, bad luck! They have every right to. What makes the zealots of the FOSS community think that the IT industry owes them a living which the industry should donate in the form of code drops?

Sorry, I cannot seem to reply directly to pd’s post (nested comments getting too deep?) So I’ll reply to this one.

@pd you did not read my post carefully enough.

One choice quote you may wish to revisit:
“Now, I want to be quick to point out that I’m not saying “shame on you.” That would be hypocritical of me; I do own and use an Nvidia graphics card, after all. And this is absolutely a positive step; open-source code is still open-source code, after all.”

I never indicated I was unhappy with the Raspberry Pi foundation just because they used the best hardware and software that was available to them to them within budget. Before this story broke, I was very excited about the great work being done by RasPi, and I still am, because *nothing has changed.*

And that’s exactly my point. The press release should have been titled “For Immediate Release: Nothing of Note Has Really Changed.”

I’d certainly like people to agree with me on open-source software, but if we can’t win by producing consistently better software and, yes, profits, we don’t *deserve* to win. Which is why it’s so great that Intel and AMD are releasing documentation of the internals of their low-level GPU architecture. It means at least some factions within those companies agree with me.

(And that stuff about DDoSing is totally off the deep end. I don’t know where you came up with that.)

How is this any different from the radeon driver using AtomBIOS ? I know you initiated radeonhd to cut this dependence, but the current radeon KMS driver is considered free, and it is using the AtomBIOS.

> Remember who you are talking to here
I just Goggled you. [edited by mod, keep it polite matt. there is no need for such comments]

LV – I Googled you, you seem quite a cool guy to be on Google, but the website was blocked by a filter. Why would they even ban a site about “dogging” when looking after dogs is such a great thing? I have complained my work.

Seriously? I attempted to google his name and “dogging” and nothing appeared, go back into the cave you came from

“some microcode” is a bit of an understatement. If your shader compiler runs in “microcode”, then is quite a lot more than “just some firmware”. There is no driver on the ARM from the code that I have looked at, just RPC shims. It isn’t a driver. And certainly nothing that would take any time to r/e and re-write.

Essentially what BCOM has done is opened up the EGL implementation. Which is definitely a nice step and should be helpful. I don’t want to critize that. But calling this an open source GL driver is a bit disingenuous.

BR,
-R

Driver : a piece of software designed to interface a CPU/OS to HW. Which is exactly what this code does, with the interface being a message passing pipe to he GPU hardware. The fact that there is a load of software on the GPU doesn’t negate the fact that this release is driver code, albeit running in userland, and using another low level driver to do the message passing.

I guarantee you that the shader compiler is not written in VHDL. The driver, the thing that controls the hw, is in the “firmware” blob. There is nothing “driver” about the RPC shim code that was released.

liz, you are aware you are being monitored what you say here as the Pi rep right, nut no matter….., its not likely that Luc as the the developer of the practical lima reversed MALI driver would confuse anything ARM GPU related is it so perhaps you should ask the techs and get him a real answer to his serious question,you may even convince him/others to help you in your real OSS gfx driver initiatives etc but anyway.

Q : is there a real Beginners All purpose Symbolic Instruction Code application that currently runs on the pi that people might use to “peek” and “poke” around this microcode/binary blob you refer to why in situ

I think that it is quite neat balance between the proprietary needs and the FOSS needs. Of course, the hard-core open-source fans would want everything including the Verilog to be open, but that is just not realistic. Unfortunately, there has to be proprietary boundary somewhere.

High-level hardware interface makes it possible to use the hardware on various platforms with various operating systems and to be easily updated for newer kernels. (As opposed to the need to wait for the vendor to support it explicitly or to reverse engineer it and reimplement it) So it solves the *practical* issues quite well despite still being proprietary. It is a win for everyone except the people wanting to learn the “secret sauce” for fun or profit.

Note that even x86 does not really execute the assembly “as is”. The hardware interface is quite high-level (CISC) and it is internally translated to whatever microcode the processor happens to be using. Yet, I have not seen anybody complain about the proprietary nature of this. It is good for the compilers, operating systems, debuggers, backward-compatibility, etc… Having the same thing for the GPUs would not be such a bad thing. [see “When I’m designing a processor for Linux.“ in http://meta.slashdot.org/story/12/10/11/0030249/linus-torvalds-answers-your-questions ]

Finally, I quite like the idea from the performance standpoint. It offloads a lot of work from the CPU to the GPU.

It’s the gift that keeps on giving. This is awesome news. The little computer that can will now be able to do everything from shifting some lights to supercomputing because this makes a port to OpenCL a possibility. It should also make it easier for the GPU to manipulate the GPIO pins.

Just to be clear – this release opens access to existing GPU functionality as determined by the microcode that runs on it. OpenCL would require new microcode which it is not possible for the community to create at the moment.

What it does do is open up the OpenGL, OpenVG and OpenMAX drivers on the ARM side.

Shame the state machine’s in the GPU. It should be noted by all, however, that you can still get useful GPGPU computation by doing “old-school” standard OpenGL programming hacks. It’s just that some compute kernels aren’t going to be as easily expressed as they would be in OpenCL.

I have a hunch that we might soon have some news regarding OpenCL. Have patience.

Congrats to the RasPi Foundation and Broadcom for vanquishing another Binary Blob. :-)

So, does this mean the DSI port will actually be useful at some point of time in the future?

I was just about to post the same comment. I am really hoping from this release people can start figuring out how to use the DSI interface better.

I too have been wondering this, and also if this will open the doors for cameras other than the “official” one. I’m not sure where the problem for developing these is.

Same as with the DSI driver, the CSI driver needed for the camera is within the GPU microcode so would need access putting in from the ARM userland. Obviously USB based cameras are already possible.

There’s a lot to do and not many of us doing it so please just bear with us on some of these requests. If you look at our recent announcements you can see how busy our small team is!

@rob sounds like not are feeling under the pump in terms of user expectations. hope you are not too stressed,I’m sure you are working as hard as you can.

Re the recent announcements you refer to, I’m wondering if I might have missed some though? could you please expand on which announcements you are referring to?

512MB, Camera, Open Userland, Overclocking to name a few… :-)

Thanks. 512MB required a lot of dev work? That’s a big boost to the Pi so thanks!

What is Open Userland?

Turbo mode seemed bugged by SD card corruption. I’ve not seen a blog post suggesting that is fixed yet (and I’m watching the Overclocking forum thread).

How close is the camera module to being released?

Were you also perhaps referring to the Gertboard as well? Is Gert part of the small team you refer to?

Was the schematics drop also a developer contribution?

@liz: think I see every post on this blog but some of Rob’s stuff doesn’t seem to have been covered. Everyone is v. busy, I don’t want to be a pressuring whinger. I guess it’s just alluring, exciting but also a bit annoying to think that maybe there’s things happening in Pi land that we don’t hear about during the gestation phase. Is this the biggest news of two weeks you mentioned?

What chance an rpi-dev blog with dom, rob, gert and whomever else posting? Or should I just spend more time fumbling though the forum jungle? :)

In response to your points;

We’re (I’m) working on ways to improve visibility on what the devs are doing. Ultimately it becomes a trade off on the best use of limited time. At least things like the @rpf_dev_updates Twitter feed should help improve this.

Gert (and the Gertboard) isn’t technically part of the Foundation so we haven’t had any involvement in the development or sales for that.

Open Userland is this announcement and along with the 512MB upgrade required dev support so work has been done there. These were the announcements that Liz referred to in previous comments.

From what I understand; Gordon is making progress on the USB driver, Dom is still looking into Turbo mode SD corruption and Alex is updating Raspi-config to work with 512MB settings – amongst other work.

The DSI driver is within the GPU microcode so this release won’t change the level of access to it.

While we would love to expose an ARM userland driver for the DSI – we don’t yet have one and we’re rather resource constrained towards getting it done… It’s on the wishlist! Or at least my personal wishlist anyway :-)

Great! Thank you Broadcom.

This is excellent news for porting alternative operating systems to the RPi; indeed I very much see the fixed hardware RPi as an excellent platform for many of the more esoteric operating systems that, on x86, require too much driver development effort to maintain in a reasonable state of currency. I am particularly looking forward to the full release of RISC OS on RPi; and seeing Plan 9 on RPi.

no disrespect meant by this but, does the world really need more operating systems?

Andrew S. Tanenbaum felt the same thing 20 years ago about a hobby OS written by L. Torvalds.

Just wanna say, kudos for that reply! :)

20 odd years and countless distributions later, it hasn’t gained a single percentage point of market share on the desktop. It literally can’t be given away (enough). Popular elsewhere of course.

BeOS, OS2 .. how many of this list failed miserably vs becoming outdated?

Last thing I want to do is start a flame war on this hotbed of topics though :) If you enjoy working on a, or using, a *relatively* obscure OS, excellent, I hope it continues to bring you happiness :)

Why would you care about percentage of market shares?
You use what works best for you, not what most others use. That’s sheepish.

“pd
on October 24, 2012 at 7:24 pm said:
20 odd years and countless distributions later, it hasn’t gained a single percentage point of market share on the desktop.”

sure, you may limit your comments to only the desktop since it inception, BUT its not the 80s any more, everywhere but the desktop you find Linux derivatives in real use everywhere else in the world especially in older PPC SOC devices and ARM SOC mobile/ industrial/ space/ medical/ etc to name just a few….

in fact ARM sell far more core licences to their HW vendors than Intel/AMD do combined

20 odd years and countless distributions later, it hasn’t gained a single percentage point of market share on the desktop. It literally can’t be given away (enough). Popular elsewhere of course.

BeOS, OS2 .. how many of this list failed miserably vs became outdated?

Last thing I want to do is start a flame war on this hotbed of topics though :) If you enjoy working on a, or using, a *relatively* obscure OS, excellent, I hope it continues to bring you happiness :)

First, learn how not to post multiple times, then come back and show us you even know what an OS is.

Second, why is desktop market share any indication of anything when desktop systems are numerically and percentage-wise in increasingly-rapid decline. The MS desktop you’re obviously referring to is being abandoned by even MS as its too-late-to-the-party Windoze Ate (more like Eaten, at this point) is going to be replaced by Windoze 7, just as people are still reverting to XP by the millions (what other OS manufacturer had to provide an “upgrade” package so that large customers could install XP over Vista and 7 because they caused so many incompatibility problems?).

Desktops are giving way to mobile device user interfaces which allow users to do what they need to do without navigating a 1980s style MS pile of senseless menus, submenus, modal and modeless dialogs, etc., etc., etc. Having to shut down a system by going to the Start menu just shows how pervasively poor MS’s understanding of users’ needs has been for decades.

There is no one-size-fits-all OS, as MS has demonstrated so vividly in its moribund failed bid to dominate the server market – take a peek at the HTTP headers you get back from almost anywhere on the WWW and you’ll be hard-pressed to find anything running on an MS OS outside of MS itself and its pathetic hardware cohorts who are so lacking in imagination they couldn’t port another OS to their hardware if their lives depended on it (and their business lives really do, today).

Then there’s the laughable series of mobile devices that have been used to try to foist evermore worthless stripped-down versions of the Windoze bloat-stack. I mean, really, WinCE? Yes, many people are still wincing at such horrible jokes. Now, MS is trying to convince everyone that Windoze Ate should be on everything in sight, but they were caught completely flat-footed by both Apple and Google, and bunch of gaudy tiles isn’t going to be anywhere near enough to compete – the official and user reviews are not the sort of thing anyone in a Roman arena wanted to see when their fate was decided by a coliseum full of turned-down thumbs.

There is more in OS Heaven and Earth than are dreamt of in your philosophy, Horatio.

OC you need more OS’s you don’t know what real innovations you missed from the past, for instance as a single exaple the amiga has.had the “recoverable ram drive aka RAD disk” device driver that is/was “re entrant” as in you can mount it, make it bootable and full of files, set a variable and soft reset your PC and hold down you 2 mice buttons to GUI boot directly to it in less than a second, that’s 25 years ago just after the ARM was also a popular home/school PC platform.

its a real shame the linux OS never was able to replicate that “re entrant” RAD drive capability, it could come in very handy today on pi and the other ARM SOC

We’ve got the Trabant and the Zil: does the world need any other make?

What “upgrade” package are you referring to that allows someone to install XP over a Windows 7 installation??? I don’t think that exists.

O yes it exists !
We had such an upgrade, and it really is an upgrade.
Now everything works, programs run twice as fast and the startup time is gone from something more than two minutes to twenty seconds.
I can recommend it !

This is awesome !!! Just unbelievable !!!

Huge thanks to Broadcom and the Raspberry Pi fundation :)

This is a milestone for open souce in general! I hope Raspberry PI to be avaliable many years, since now we all will be able to get the most of the Broadcom chip! Thanks a lot Broadcom!!!

can someone please expand on why this is ground breaking for the Foss world? a while back I tried to keep up with this video drivers for Linux issue by reading sites like phoronix daily but it got too much when AMD seemed to release the information everyone wanted, though under NDAs if ggig remember, and that didn’t seem to make any difference. thanks in advance.

You can now enjoy full hardware-accelerated OpenGL ES, OpenVG, OpenMAX etc support with everything running on the ARM fully FOSS. This has not been true of other ARM multimedia SoCs. The release is significant for that philosophical reason, and for the advantages it will give to those who want to port other OSes or e.g. extend the EGL implementation.

I think maybe the operative word is “ARM” whereas perhaps this is not completely new in the x86 world?

When you say “You can now” I assume you mean that there is now the possibility that all those things will happen as opposed to them being available right now?

On behalf of the Razdroid project; thanks. Seriously, thanks. This allows us to have a hardware accelerated build up very soon.

Again, thanks.
//Warg

That’s great news. Please keep us updated with your progress!

I’m very excited about Razdroid. When I saw this news it was the first thing I thought. This solves the AudioFlinger problem too?

Well done (and thank you) to the Pi team for pushing this with Broadcom, and to Broadcom for agreeing to it.

Yeeeeaaah!! Good work Broadcom!!

Will this affect the Android release?

It’ll help people who are trying to port it.

“””first ARM-based multimedia SoC with fully-functional, … fully open-source drivers”””

How can you claim this, while still requiring licenses to enable parts of the hardware? That does not equal “fully-functional” to me.

You’re the aggressive rude guy from Twitter, aren’t you? I’ve explained carefully there why we charge for codec licences. It’s very easy: THEY’RE NOT FREE. We have to buy them, and not everybody who has a Raspberry Pi wants them, so we sell them to those who *do* want them. This keeps the cost of the Raspberry Pi down for those users, especially in education, who don’t want the licences.

There is a significant distinction between free as in speech and free as in beer here. It sounds like you’re more interested in the latter.

Incidentally, after your performance on Twitter earlier today, I’ve removed your posting rights here and blocked you there. I don’t like being sworn at.

I do sympathise with you having to deal with these nutters. Thanks for all your efforts, today’s news is excellent.

good on you Liz! Some people are very puritanical about open source and will not be happy until every line of every file on the internet is freely available. those who whine about paying the price of a large coffee to enable months of entertainment are, in my view, unreasonable. the $5 charge for a hardware accelerated codec is roughly 75% cheaper than the price of one single night at the cinema but enables endless TV and movie viewing. Please people, get some perspective and get off the foundation’s back!

Amen to that, and not only is $5 a pittance to those of us with “money to burn for media codecs”, increasing the cost of the Pi by $5 would make a big deal to a limited school budget who needs to buy 50 of them. I can only see this as a win-win for everyone, I get my additional codec for really cheap, schools can get their Pi for really cheap and everyone is happy.

You are mixing the problems. Don’t know about the one you are replying, but freedom of the user and of the code is an envaluable goal. Me, for example, would have no problem to pay 10$ more for a Free solution, but would never give even 1Cent to “enable” restricted code. Sometime I can’t avoid that (like for the blob part of RB), but I always fight whenever possible and explain loud the point. Without users keeping asking for freedom and be willing to sacrifice some convenience for freedom, the entire FOSS movement and users freedom are goinng to end soon. I don’t want to become just a “consumer” controlled by other people through proprietary code.

Amen to that. The problem isn’t that we have to pay for a licence, it’s that the only available MPEG-2 codec itself is non-free. I’m not entirely up on the process of GPU coding beyond OpenCL and OpenGL, so I have to wonder – why can’t someone just implement an existing codec on the GPU? Is there fixed-function hardware in there that itself is non-free?

I’ve not a “reply” button on the Eric Swanson’s comment below, so I reply to mine.
“it’s that the only available MPEG-2 codec itself is non-free” is not true, we have Libavcodec that can encode/decode for a lot of formats, also proprietary like MPEG-2.
That is true Free(dom) GPL code, just the MPEG consortium, through software patents, forbids (tries to) it’s usage. They are real bandits, and should be stopped like all that madness of software patents in general (not “regulated” or “improved”, there must be NO software patent system on software, full stop!).
Sometime that code is put in “non-free” repositories, but because of legal concerns, not because the code is not free.
People, European in particular, wake up and fight!

<3

So you licensed some parts, and feel like that gives you the right to promise things you don’t deliver? Guess what, everyone else did as well. Yet, the rest are not making such claims.

An RPC-shim is not an OpenGL ES driver. You can try to redefine where the separation of a GPU and a CPU is all you want, but everyone with any insight will call the bluff. The real OpenGL ES driver runs on the VideoCore, and is not open source.

This is simply not “the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers”, as you try to claim.

Not only are you making false claims, you also seem to be actively attacking people who points this out. That’s not exactly what I’d expect from someone who seems to want to be taken seriously.

Erik, I do think the fact that it’s possible to get full GLES support while running with fully FOSS code on everything from the kernel up is a milestone worth celebrating. There are practical benefits to opening the code, and there’s not much that can be done about the fact the VideoCore team decided to implement their GPU in a different way to e.g. Mali. Sure, it benefits us that their design decisions makes the decision to open up the ARM side rather a lot easier.

I don’t get what you’re trying to say. Because they opened up some thin shim, they can claim to have a fully open source driver even though they do not?

This isn’t an open source OpenGL ES driver. You don’t run fully FOSS code if you run OpenGL ES on a Raspberry Pi. This is an open source RPC shim, nothing more.

Mali has nothing to do with this, other than also having a closed source OpenGL ES driver.

Erik – nowhere in the article i can see anything that even sugests that the source code for the GPU (which implements the full OpenGS ES stack in hardware) was released.
With this source code release, one is now able to write his own GNU or BSD-licenced OS that runs on the ARM and will be able to fully use all the features of the GPU, including the OpenGL ES interface.
There is no ARM source code for OpenGL Es because the CPU does not have to do anything. You pass OpenGL ES code directly to the GPU, and the GPU takes care of everything – like on a elegant workstation-class 3D card.

“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”

That’s “fully open-source drivers”. Not “partially open-source drivers”. Besides, if it was only “partically open-source drivers”, then there would be nothing “first ARM-based” about it. And they even go so far as to stress the multimedia-bit.

As for the CPU vs GPU, you are (intentionally?) blurring the line here. Bolting another apps processor on the side, and calling it a part of the GPU is just silly; a GPU does not manager buffer-handles, check framebuffer-completeness or compile shader-code. Not even those “elegant workstation-class 3D cards” you so keenly refer to.

Calling this an open-source GPU driver is completely missing the point of open-source, and trying to misuse it as a marketing tool. Open source is about allowing the end-users to add features, fix bugs in the implementation; the RPI release here does non of the sort.

There still is freedesktop.org’s Display-link option to drive a USB-video card I have a post somewhwere on the forum about that, This would enable peolpe to run 100% free software (including video) Leaving the closed blob for what it is until it opens one day (or never).

it’s still saying full open source DRIVER, not full open source everything. there is a difference between a driver and firmware, and nowhere it states that the firmware is OSS.

it’s just a fact that broadcom decided it was a good design choice to put a lot of the logic in the firmware, instead of letting a driver do that. i actually see sense in that, because you won’t need to write e.g. an opengl implementation for every OS you try to build for, but just hook in to the opengl implementation

Hi Liz!
What about the other codecs? Audio ones, other video ones?
Thanks

Quite simply because the codec licensing concerns the GPU firmware, not the driver. They’re two different things. The driver is now free software, but the firmware remains completely proprietary. It seems that it’s the firmware that checks the licence keys, not the video driver. The driver is fully functional in the sense that it can do everything that the proprietary release could.

This release means the raspberry pi is now about as free (libre) as a typical PC with an Intel GPU, which is excellent news.

AFAIK, intel GPUs have like 1600 pages docs, I doubt Broadcom can say as much.

As I say at http://www.h-online.com/open/news/item/Raspberry-Pi-opens-its-ARM-graphics-code-1735262.html Intel have really led the way on the desktop, no argument there.

1305 pages…

This is great news – really great – and it means that we can have a truly open source driver for ARM devices (at least on the ARM side) based on VideoCore. What is BAD news is:

1) The need to have a binary blob instead of firmware – unfortunately true of most video implementations.
2) The need to LICENCE MPEG2 playback(!!!) and pay for this – that is truly horrid and the usual profiteering on the part of ARM/VideoCore. It’s a real shame that the Pi was not based on a MALI core – otherwise we could have used the Lima drivers in the future.

Definitely a great step forward. What I would like to know is – if I run RasperianXBMC on the Pi and pay for the MPEG2 key (and Nuppelvideo is based on MPEG2) – would I be able to play back NuppelVideo (aka Freeview video streams in the UK)?

To respond:

1) Yes, you do still need some microcode firmware for the GPU but at least now the ARM side drivers for this are entirely open. As you point out – nobody else has been able to open their GPU firmware either.

2) I’m not sure how you count the license cost as profiteering. We have to pay the MPLA in order to use their codecs – this feature was not included as standard with the Pi so that we do not have to pass the license cost onto educational end-users. The extra fee we apply is purely to cover our own fees to the MPLA for users who want this feature. The ARM MALI core presumably just has this cost included in the sale price of the HW.

It’s been interesting for us to watch some of our more unimaginative users complain about codec costs. Usually, with most devices, the codec licence costs are bundled with the hardware you buy. That’s surely not *better*, is it?

Liz,

Your response less the “emotionally loaded” first sentence would have been sufficient to make your point. I can only imagine the frustration you might feel, but going out and calling those people who don’t seem to agree with your point of view “unimaginative” isn’t going to help the situation.

Cheers,

Meh. I’m perfectly happy with it.

Liz, simply ignore the trolls and remember that the vast majority of us appreciate everything you guys have done and are doing, and the reasoning behind it all. You haven’t put a foot wrong since the boards started shipping and you became able to focus on other things. Some accelerated audio codec add-ons to go with the MPEG2 (which I’m sure are on the way) and I’ve died and gone to heaven. Thank you.

The MPEG LA demands a licence fee for *every* device implementing a range of codecs. If you buy a modern Nvidia or Radeon card or a smartphone you are paying this fee as part of the cost of the device.

What the Foundation is doing, that the above are not, is offering the option of *not* paying for the codecs if you don’t need them. The alternative to licensing them separately is to just include them with the device, and add the fee on to the price, for everybody. It’s a silly situation and the Foundation has, in my opinion, implemented the best possible compromise under the circumstances.

Please direct all rage towards the MPEG LA and the software patent system instead.

Actually, if you’re in the EU, you should just disregard MPEG-LA.
Software patents are just illegal in here (at least for now, lobbies are still trying to bring it on over the EU Parliament, cf. http://www.unitary-patent.eu/ ). The problem is the EPO grants them anyway, in total violation of the legislation, so you’d have to challenge them in court if you get sued.
Still, paying them is just acknowledging the illegal practice of a whole industry.

BTW, I thought MPEG-LA was “kind enough” not to ask for fees on opensource projects… did they change their mind?

The MPEG decoder isn’t in the open source part.

The GPU blob is not open-source. That’s why…

“mmu_man
on October 25, 2012 at 10:20 am said:
BTW, I thought MPEG-LA was “kind enough” not to ask for fees on opensource projects… did they change their mind?”

as Martin already implied in less detail… the the ‘potential’ MPEG LA licensed essential patents fixed function decode hardware block hardware inside the SOC.

if this block is in fact linking to the MPEG-LA essential patents encumbered software AND its activated for USE then after 10,000 units are shipped then the fees are due….. even in the EU as its accessing a hardware block with software a perfectly valid EU patent HW+SW combination

however ….. in the case of SW decoding using nothing but the API as in MPEG LA API (Application programming interface) to independently written code such as x264 then there’s no case for fees to MPEG LA as your not using their patented code.

OC thinking outside the box… if you were a vendor of hardware and thinking of the long term future of FLOSS for your collectives continued long term use you could simply speak with the OSS x264 developers and licence their x264 code under the LGPL and commission some FPGA (Field-programmable gate array) vendor to port/translate that x264 FLOSS low level C/binary code to a cheap real hardware block and place these on you PCB or even find a real ARM foundry/integrator to place this resulting x264 hardware in a real ARM SOC or perhaps offer them to ARM inc for free to include them for everyone’s benefit in the 2k/4k/8k video future :)

just a few thoughts and possibilities to consider long term.

opps where “to independently written code such as x264” should read x264/ffmpeg/Avconv if you wanted best in class Encode AND Decode abilities in both sw and hw blocks

“BCMM
on October 24, 2012 at 6:56 pm said:
The MPEG LA demands a licence fee for *every* device implementing ” with volumes of over 10,000 commercial units that are using their essential patents…

there, fixed it for you ;) , you really should try reading up on the MPEG LA licencing and understand it to some degree before condemning them as guilty until proven innocent

For reference, there are just over 100 files with C code. There are 200 header files, a lot of them would be literally one-liners if it weren’t for the copyright notices, includes, etc. A lot of the C code is stubs.

The largest collection of actual code are the “khronos” ones, the largest file of all being glxx_client.c which seems to do nothing except pass off OpenGL calls to internal RPC calls but is 177kb of code (mostly debugging code to log each call, and then individual functions for every OpenGL function that just maybe does some minor tweaking and then calls an RPC call with almost identical parameters).

In total, there’s not a lot of actual code there – certainly nothing to learn from or to tweak much – and I have to say that documentation and commenting are severely lacking. It’s not even clear what half the files even DO or why they are named so, let alone the functions, variables, magic numbers, and various other things that “just work”. There are a couple of TINY utilities, that are already available in binary form, to do things to the RPi like change the TV-out modes, etc. but they are literally worthless in terms of code.

Apart from that, it’s all headers (undocumented) and makefiles. I’d call it closer to a code-dump of some userland interfaces that had to be at-least-GPL anyway and tiny utilities, if I’m honest, rather than an actual driver of any kind.

I think this announcement is more about principles and trying to have as open a platform as we possibly can for the cost. Eben has long said that the userland ARM drivers were much less interesting than people may have thought!

The people who will directly benefit from this are those porting OS’s to the Pi as they can now use the VCHIQ kernel driver directly. This should allow things like an open, HW accelerated Android build to be created by the community.

The important point here I think is that you can take this code, even though it’s mostly stub code, and recompile it as you need or bending it to a different API. This means for example that you can port this to a different OS you want to run on the RPi. There is nothing much to learn from and you still can’t reprogram the GPU at will, but that doesn’t mean this is not a very practical step forward in other aspects – having the ARM host part completely open gives you a great deal of flexibility.

Very goog News which i strongly believe will be a huge benefit for all, the users, Broadcom and the ARM Platform.

The RasPi team continue to exceed expectations! Really looking forward to RiscOS as I could never afford an Archimedes after my Beeb Model B …

I think you’ll enjoy RiscOS on the Pi – it’s still a really nice little OS. (And it boots in MOMENTS.)

I seconds, thirds and fourths that! :-)

Yep, I’m hoping for fast tightly written code to make a comeback with modern graphics and low-cost hardware. Debian on the Pi is an impressive technical achievement and surely required lots of hard work but for an old fogey like me GNU/Linux doesn’t anywhere near recapture the beeb magic.

Plus: a British OS on a somewhat mainstream British computer hasn’t been done since … Psion?

Wow!
This is first of all amazing – how did you convince such a big company as Broadcom to actually do something like this?
And seconds this could and hopefully will become a “beacon”, a “fire signal” or a spark to all the other chip vendors. It will hopefully convince them that
a) handing out such information does not hurt them but rather in contrast
b) helps them to broaden the wealth of supporting software for their chips!
It is perfectly clear that today’s unique selling point for hardware is not the hardware specs alone but also the supporting software and the ease of integrating with those, sometimes highly complicated, software stacks.
Graphics and multimedia are still among the most complicated ones to integrate. Such an open source release helps increadibly achieving the best integration possible.
The Raspberry-PI foundation once again showed a remarkable uniqueness in achieving this release – great! My deepest respect to the ones that did this and of course a very big Thank You!

Cheers
nils

> This is first of all amazing – how did you convince such a big company as Broadcom to actually do something like this?

We have *great* personalities.

Seriously, though: cheerful persistence! Broadcom have been enormously helpful, and although the process is necessarily slow (there are a million different work groups to get the OK from, lots of code to check through, and lots of boxes to tick), it’s been very easy to work with them on this, and they’ve been brilliant.

Broadcom pulls in about $2 Billion a quarter and usually ‘takes home’ about $250 Million of that in profit. I suspect this might have helped :)

@pd Wuh? What has Broadcom’s income to do with this? Their income from the Raspi is pretty minimal compared with all their other product lines.

I’m saying that they are doing pretty well in general so they can afford to be … hmmm, what would this be called, generous?

> how did you convince such a big company as Broadcom to actually do something like this?

I’m guess Mooncake, the benevolent overlord behind Raspberry Pi, had a paw in this … :-D

Lovely reply :P (http://en.wikipedia.org/wiki/Mooncake)
As a FOSS supporter (not a developer, programmer, hardware engineer or the sorts) I appreciate what the RaspberryPi _does_ for their owners: it gives them a cheap enough computer to play with in a lot of ways, a very cheap multimedia platform _and_ a lot of fun learning how to use it for anything they can conceive.
The debate on how open the _firmware_ of the GPU is… that’s just a lot of marketing hipe on one side and over-militant zealots of various movements on the other side.
I can understand (and happily live with) the reasons of the Raspberry Pi Foundation to conduct the business model that they adopted, without a lot of fuss, bells and whistles, because this shows once more that in the technology realm, _open_ and _proprietary_ can work together with benefits for both.
I can’t wait to get a RPi to play with… and maybe I’ll even pay the “infamous” MPEG-2 licence to see for myself if it really worths. The power to tinker with a RPi by changing SD-cards, “shields” and then watching a HD movie on my couch is priceless. Not to mention that I hope that my 7 years old son would be much more interested in RPi than in various (overpriced) Lego contraptions that he assembled and then stored in long time untouched boxes…

Great job broadcom!

Thank you Broadcom and thanks to the raspberry pi team !
I think this day will stay in the history of ARM SoCs.

Seems to me that some people will complain about anything.
For goodness sake, thisseems to be agift that did not need to be given, but nonetheless it was, so please, accept it in good grace and in this life, never, ever, look a gift horse in the mouth.
Good work by the foundation all along,
Thak you

Thank you, Foundation and Broadcom.

As for those who complain, go do something to make the world better and less actions that take away from those that are improving the situation.

| Hi Liz. I’m back. Serious early season Sierra/Tahoe snow is falling!

OMG!!! OMG!!! I can’t believe this happened. I’d already resigned myself to the proprietary drivers. Then all of a sudden this. Keep up the good work. I’d consider this completely open even with the firmware blob, after all proprietary firmware initializes everyone’s computer except for the like 3 dozen ancient mobo’s that work with Coreboot.

“after all proprietary firmware initializes everyone’s computer except for the like 3 dozen ancient mobo’s that work with Coreboot.”

… and the millions of embedded devices running Free U-Boot firmware…

wooooo!! \o/ as an angry bsd nutter, this pleases me greatly. way to go y’all!

Wow! It seems almost on a weekly basis there is fantastic news with regards to the Raspberry Pi! You guys are absolutely amazing! I REALLY appreciate all your work and admire your ceaseless efforts to improve this amazing computer. It’s no wonder it’s unquestionably my favorite electronic device!

Hi,
Do you plan to tackle the usb-core low level documentation next ?
RPi is a total useless toy without clean usb driver and this is even more the case as ethernet is behind the usb bus.
See Greg KH messages about this problem :
http://permalink.gmane.org/gmane.linux.kernel.rpi/80

Fast summary:
“Possibly, it’s just a really bad USB controller chip, combined with a
sad way to hook it up to the processor, combined with with a truly
horrible driver make for the fact that USB works at all on this board a
total miracle.

And you can quote me on that.”

I think you’ll agree the USB driver has improved since launch (in great part thanks to Gordon’s efforts). One of the Plan9 guys has made massive progress in writing a new USB driver from Scratch, and as well as that there’s the USB HID driver that came out of Alex Chadwick’s Baking Pi. http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/os/

Ok, good to know.
Was aware of some progress on the new plan9 driver, but the road is long before it could replace the default driver on Linux.
Open docs of the Synopsys USB core could really speed things up.
With the help of Broadcom, it should be possible, and could really promote the Rpi as a real “not a toy” killer board.
Thank you to your care.

First off, it’s a $35 computer that does more than anything else in it’s class. It has first-class support and is constantly improved. For free. E.x. Turbo mode.

Most any USB device seems to work just fine. E.x. No issues with my keyboard, wireless adapter, bluetooth, or hard drive (this one via a USB hub). It’s fast enough for large file transfers (10-15GB).

The phrase “useless toy” seems a little overkill, to put it lightly. It has plenty of good uses. If it doesn’t do what you want, that doesn’t mean it’s useless. It seems to do what almost everyone else wants, though. (which is probably why it’s constantly on back-order)

The sense of entitlement and negativity of some people baffles me.

I agree with you, but perhaps using turbo mode as your example isn’t such a good idea while it causes SD corruption, which I’ve experienced personally.

That is what he said! The software is constantly improved upon, as in “Dom is still looking into Turbo mode SD corruption”, just a few posts earlier.
So why exactly is turbo mode not a good example?
Turbo mode is another example of an unexpected freebee, and after it’s discovered its causing some other issues they are worked on. I think Andrego made some perfectly good points.

Not here. I am trying to use a bluetooth speaker. Once in install the required pulseaudio module and use blueman to pair the device, the new output device appears briefly in the pauvcontrol window, then ‘****’ happens. Where ‘****’ is anything from a crashed or stalled pi, to bluetooth disabling itself.

I have a 10w power supply and have tried with dist firmware, dist firmware upgraded and with 3.6.11+ firmware. Turbo mode is diabled. All version have the problem.

Think the usb driver still needs work.

Many thanks to all involved! I didn’t expect this to ever happen!

Indeed, great efforts by guys involved, I am sure this would be the break-through for raspberry Pi to become mainstream and more Java guys will adopt it.

I’m wondering if this means we can access the GPU so we can use it for things other then displaying video. I’m thinking of things like AI techniques which use matrix math.
It would be very cool to have a Raspberry Pi hooked up to a web cam that is set up to recognize a person’s face. Or have some really good speech recognition on it.

There’s already a project like the one you describe out there – this is well worth a read.

what, if anything, does this imply for a fully free wifi radio driver?

Congratulations! This is great news!

I also want to thank Broadcom for not choosing the GPL. I may be running on Linux, so it won’t make a difference to me personally, but I still think the GPL is an obnoxious license.

Oh dear, you must be a very dull person.

To Liz and the foundation: Thank you SO much for all you do! It will never cease to amaze me how people manage to complain about every little thing that you’re giving them for FREE!!! I mean seriously…first upping the RAM. Then opening up this source code. Yes it may not be every single line of every single piece of code, but it’s a huge leap in the right direction. And all these people can manage to do is complain about it. It truly astounds me…

Anyway, thanks again for all that you do! Try not to let them get to you…you’ll find people with sour grapes (reference to Aesop) every time something good happens. :/

Great news – thanx for pushing this through, and thanx Broadcom :-)

In C there is a function called “ungetch” to unread a character from standard input.
Liz, you need a “ungetpost” to avoid all this silly complainers to ruin your mood.
The truth is that RPi is getting better and better as time goes by, but for some people, the more you give, the more they demand.
The only think is lacking is capability to make coffee (but with a Gertboard…)

My mood is positively buoyant. :) And I look forward to seeing the first Raspberry Pi-powered coffee maker!

so if we chuck you in a river you’ll float?

witch, witch, she’s a witch i tell ya, burn the witch :)

You got me. *Zaps Scone with Magic Missile.*

darn no saving throw possible

http://www.dandwiki.com/wiki/Magic_Missile,_Improved_(3.5e_Spell)

aaaarrrrrrgggghhhhhh you got me

Great, now all I can think about is a mods AD&D session!

We HAVE to do that some time. :D

Thank you Broadcom and all those involved in making this happen. There are many out here that actually consider this a positive achievement. Also, to the entire RPi Foundation, team and you supporters, thank you for this wonderful little machine at it’s wonderful little price point. My friends and I are really enjoying the Raspberry Pi “ride”. To the naysayers, please save it for another day. A positive step, is a positive step. Today… we celebrate and dance, if only a little.

Not sure if this is the place, but I see there’s support for Android native buffers. Will these be possible to use native buffers (or even a simple gralloc library) in the non-Android firmware when it’s released? Because that would help a lot with what I’m doing.

Great, great, great, GREAT STUFF!

Will this make it easier to get the Kinect working with the RasPi? I think combining those two items will open a lot of opportunities in robotics. Some folks have gotten very basic features working but nothing at a good frame rate that I have seen so far.

Does this open up for openbsd in the pi? Anyone know what complaint Theo had and if they are now eliminated?

Peter Hessler from the OpenBSD project summed it up on the misc mailinglist;

“No, it was not open sourced. All they did was release some userland
wrappers around their api.

No, this does not make it closer to OpenBSD being ported to this device.

Nothing has changed.”

Peter Hessler doesn’t seem to have much understanding of how operating systems and device drivers work.

The only thing that’s left closed source is the firmware. No matter what he says: the source of the firmware is not needed to get any operating system run on the Pi. Since both the kernel driver as well as all libraries building on that are open source now, they can be ported to OpenBSD.

I’m not sure why you’re expecting the OpenBSD developers to react any differently, to be honest – they’ve long been opposed to drivers that are just thin wrappers around binary blobs, and even though this binary blob runs on the VideoCore rather than the ARM chip all their usual objections still apply.

I wonder where Peter Hessler gets his disk drives with open source firmware.

Nice question

This response was almost expected, people are people, and we think our agenda is the only one which is important. No matter how much your given, its never enough to be considered a gift….

Reminds me when I got my android phone and every owner expected ALL of the software should be free, all the games, all the apps, everything. Including those written by independent developers with no corporate sponsorship, as they were expected to live off of the GROUP love…..

RPI team, congrats and thanks!! I am not a systems developer or anything close, but I am a programmer ( NOT a developer ;)) and I appreciate the effort (and success), which is way more than most complainers on here have done (will do)!!!

and to all (not all but most) that claim this is nothing….what have you done lately??

Cool. This will make OS-less demos more feasible. (Pushing machines tends to take all the available RAM)… shame my RPi monitor blew up… need to fix it.

Excellent news! Congratulations and thanks to the RPF and Broadcom!

More free and useful stuff that you didn’t have to give us but worked hard to do so anyway? You disgust me. Stick it up your jacksie. Gahhhhh!!

This is fantastic news!

Will XBMC’s menu get HW acceleration with this?

No, XBMC relys direct on the framebuffer

No. XBMC purely renders the GUI through Open GLES, and therefore is HW accelerated.
Any slowness is down to the ARM generating the textures/fonts used by the GUI.

Good news for OS level developers. The RaspberryPi is a great, open, ARM core with a nice set of input and output devices around it.

When you read the datasheet and this newly published code you may notice two things.
1) The GPU is the boss of the SoC running an RTOS to keep track of a lot of things
2) The GPU firmware blob is also compiled from C code
And then you have two options:
1) I want to compile my own code for the mighty whatever-architecture (multi) core the GPU is. The SoC may be cheap because of some great optimizations that are a trade secret. But, hey, I didn’t buy just a product, I bought something open here.
2) I am perfectly happy with a 1GHz ARM core running only human readable C-code. The SoC it is in is cheap and small, I like it.

I think Broadcom is a nice company for letting all the group 2 people enjoy so much punch for little money.
I suppose others will not accept this, they should stop using their USBstick and dishwasher now because they probably run evil compiled firmware too. They don’t even offer you a fully open secondary core, these Sandisk and Miele bastards.

Also FSF is plain stupid when it’s about firmware. Field upgrading is very useful, going back to the PAL days is just not a solution for this problem. It also offers you, as a user, the opportunity to run no proprietary firmware, by not initializing the darn hardware part. If you want to go all reverse engineer on the firmware blob, nobody can stop you (except for some wicked signed bootloader scheme).

Lol, why do people with Aspergers love numbered lists so much?

Give this foundation another award! As soon as I can, I’ll order another pi just to support the foundation and make more things possible.

Can we hope for OpenCL support ?

IT WILL RUN DOOM!

YAAAAY!!!!

Better than that – it will run several copies of Doom, AT ONCE!

Doom Server?

Opening up the drivers is all well and good, but personally I’m more stoked that Liz blocked the troll. Fabulous performance!

Is troll hunting a legal bloodsport, ah! why does Liz have all the fun?

Troll hunting. It would be a fine movie too.

“Troll apocalypse” would be a pretty good movie too.

I came for the great news. I stayed for the slaying of trolls by Liz!

Quick recap for some of the angry people:

“We don’t claim to have all the answers. We don’t think that the Raspberry Pi is a fix to all of the world’s computing issues; we do believe that we can be a catalyst.”
http://www.raspberrypi.org/about

Just wanted to say thanks to Broadcom and to the Pi foundation for making this happen. As readers of this thread probably know, desktop Linux systems tend to run proprietary graphics drivers if graphics performance is important. Because of this, today’s announcement is actually a big step forward for the whole free software movement. Hopefully other companies that make video hardware will be encouraged to follow Broadcom’s example.

I think it’s a great shame that people reacted to this achievement by flaming. I suppose it would be nice to have the microcode source, but I know that it’s not realistic to expect to get everything I want. Today’s announcement gives me more of the things I want, and I’m going to be happy about that.

Thank you Eben Upton! Thanks you Broadcom!

Super props to the guys at Broadcom and especially to Eben who I am quite sure convinced the ‘smiling men’ that opening up the code would benefit them rather than cost them. Super excited and can see the Raspberry Pi being used in so many more cool and exciting projects.

Raspberry Pi People.. YOU ROCK!!

Wow! Thanks Broadcom.

It’s a lot of progress in 6 years. I remember in 2006 swearing off Broadcom for life because of their then current attitude to supporting Linux for the wifi chips — you would not believe the pain I went through trying to get wifi working on my then shiny laptop. It’s fantastic that things have changed. Well Done to everyone involved

WOOHOO :D This is an excellent step – anything which tends to more Free as in Free/Libre software is a very good thing indeed, IMHO

Well, as a Free(dom) Software beliver and supporter I see the problem of the remaining proprietary code that is still in Rb, but also I’m really happy about the steps forward in the right direction. Also very happy that RB foundation is taking care and value the openess of the device.Last, if Broadcom, one of the more “hostile” hw producer (let’s remember the damage is doing to our community with it’s wifi chips line that had not free drivers or require binary blobs), is going really more open (and not with tricks, half code -requiring still binary blobs-, unusable documentation or so on) is a great new too!

This is good news, but as I understand, there are a whole bunch of stuff (firmware blobs) which still isn’t open. This means that projects such as OpenBSD won’t be supporting this platform. At least not until those parts open?

I think the guys from OpenBSD.org said it best;

“Their “open source” is nothing but a layer of code which calls into a closed source back-end.” – Theo de Raadt

“No, it was not open sourced. All they did was release some userland wrappers around their api.” – Peter Hessler.

While I appreciate what has happened here (it’s a step at least), calling this OpenSource is dodgy at best.

How do you feel about “open source” that runs on closed source systems such as Windows or Mac OSX, don’t they need to call closed back-ends to make windows appear on the screen, open processes, etc.

Once again you come up with incredible news. And a big THANKS to Broadcom.

Awesome! Thanks Broadcom!

Wil you be open sourcing the bootloader as well?

time to say thanks to broadcom? (thx!)

Apparently some people in other forums are starting to debunk the open source-ness claim. Care to state in clear unambiguous terms what is really open and what’s not in the Pi? If half of those critics are right then the whole project is going to lose a lot of its credibility.

The graphic shows it. ARM side is open source (unless you’re running non-open source applications, but that’s your own problem), GPU side is a black box.

Now, the GPU side does a lot more than it does on most devices, but this means that any OS can talk to the GPU side, at least.

This is a positive step, surprising from Broadcom but good! And you have already emulated others people :

http://rhombus-tech.net/

R

hmmmm don’t think they have actually produced anything but words

hmm… your hmmmm is too long, it is a positive emulation no ? :)

There’s been a few people debunking this release but I’m not really sure when the Raspberry Pi became about open source’ness?

Wasn’t it about opening up computing to pupils in schools? Seems to me that this release will make more features of the Pi a lot more accessible to more students in the long run, surely that’s a good thing, or am I missing something?

I’m very excited and very proud of everyone ! I’m proud to say that I just cloned the source repo of my Raspberry Pi.

░░░░░░░░░░░░▄▄
░░░░░░░░░░░█░░█
░░░░░░░░░░░█░░█
░░░░░░░░░░█░░░█
░░░░░░░░░█░░░░█
███████▄▄█░░░░░██████▄
▓▓▓▓▓▓█░░░░░░░░░░░░░░█
▓▓▓▓▓▓█░░░░░░░░░░░░░░█
▓▓▓▓▓▓█░░░░░░░░░░░░░░█
▓▓▓▓▓▓█░░░░░░░░░░░░░░█
▓▓▓▓▓▓█░░░░░░░░░░░░░░█
▓▓▓▓▓▓█████░░░░░░░░░█
██████▀░░░░▀▀██████▀

٩(●̮̮̃•̃)۶ ٩(●̮̮̃•̃)۶

This is awesome!, not 100% free but a big step forward.

From those who work in large institutions, creating non-trivial culture shifts is a massive undertaking. Thanks for doing what you can, hopefully Broadcom will focus on the massive positive support (with stories, development, and money) and it will make your jobs easier to open source more of the stack.

Having watched the Pi development pretty closely and listening very carefully to every one of Eben’s posted presentations, this is not only a great accomplishment, it’s just one more step in a process of a large number of steps. I hope I don’t make anyone at the Foundation even more mad at me than I’ve already made them, but I feel that Eben has provided a sufficient number of hints that we can be confident that this is just one small step for a man, and one giant leap for Mankind (including all of our better halves).

This is so interesting that I’m going to be doing some rolling-my-own when I finally get some time during the holidays. It also opens up some new possibilities for my Pi-finity! STEM educational game system that I’ve been slaving over. Just when I thought I had all of the answers, they’ve changed all of the questions, but I’m not complaining – this kind of nice surprise I can welcome and embrace with “open ARMs”!

Keep up the great work, Foundation team, and we faithful can’t wait to see what you have up your sleeves next (and it’s killing me to not speculate, so “Mission Accomplished” for all of you wanna-be dungeon-masters! ;) ).

How dare you!

First you upgrade the (unreleased) model a to 256Mb, then you dare to allow multiple operating systems oer than your own distro, then you make bug fixes, hardware upgrades AND NOW you actually put work into more features your customers have asked for.

Seriously the only thing I see wrong right now is people complaining about you improving (without breaking) things.

Is anyone’s model b (including my first may 2012 version 1) not compatible with the current updates? Or viceversa is the current 512 with mount holes and more io backwards compatible? I think it all works.

May the foundation continue to tweak and otherwise improve their own products for sale? I hope so!

Sure people can go ahead and convince Broadcom to release their secret IP for some inch product without an NDA…… Or accept what everyone bought is what they ordered.

I am all for open source. I even think that if some developer really needed something extra from the pi and the current arm based data/driver/documentation was not enough a helping hand may be available from Broadcom or the foundation.

Kudos to Broadcom :)

Here’s again a post from one of the graphics professionals, and I want to explain *why* people like Luc and Erik, who actually *work* in the field, are pissed off.

Basically, what you just did is a great thing indeed: It allows developers to port any operating system to the BCM2835 and have working OpenGL ES acceleration there. This is more than any other ARM SoC can offer currently, and you (i.e. Broadcom and the RPi Foundation) certainly deserve credit for that.

The thing that’s not OK is *how* you announced this. This blog posting we now discuss is accurate and well-written, except for one (half) sentence, one you unfortunately chose to stress by writing it in bold face, making it sound like an important statement you’re entitled to be proud of:
“the first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers”
See what you did there? “Fully functional”, “fully open source”. You keep saying that. So us graphics guys are starting to become interested: “Hey, they have full driver source code, we can now finally see how that thing is working!” That’s our line of thinking, first because we’re simply interested in how your stuff works, second because this makes us able to learn how to use that hardware most effectively (if you know a GPU’s architecture, you can optimize your code for it), and third because we might eventually also be able to improve it.

But then it turns out that what you released is not a driver at all. Again, let me stress that the “fully open source ARM userland” part is true, only the “driver” one isn’t. I have to say that the basic model of having the VideoCore IV DSP run the OpenGL ES driver including the shader compiler and all the other complicated stuff is indeed elegant. But please, pretty please, stop advertising your API shims as drivers then, because we (that’s Luc, Erik, me, some hundred other people deeply involved with graphics, and I bet even Eben!) know that by far the largest part of the driver is contained inside the firmware blob which, I guess, will not be made open source anytime soon, if ever.

KeyJ, i think we understand your gripe and thank you for staying polite.

But i don’t think this matter should be fought out in the open (thats explaining OPEN-source in a wrong way) . It only puts you guys in bad daylight..

I must respectfully disagree. It is nothing close to being opensource. I read the announcement post, and quickly downloaded it code from github, after 5 minutes poking I realized this was all shims. Releasing shims is a very small step, and nothing like releasing the open source. I felt cheated, but only because I was foolish enough to believe the post. It is more than fair for those who have objected to object as the post was misleading and wrong.

That sums it up perfectly.
Good thing every byte the ARM core runs is open sourced now. But the announcement could have been just that, without the huge ‘first, fully, vendor, fully, first, vendor’ statement.
I do appreciate the honest replies Alex, Eben and Rob gave.
The Broadcom marketeers should just shut up next time when it is about boldness of pieces of text.

My understanding is that a driver is a piece of code that allows your software to talk to the hardware. In this case the your programs can use the released code to talk directly to the GPU. It just happens that the GPU implements OpenGL ES and all it’s shading magic in hardware.

It times of old, when computers were created by engineers not marketers, one was sending AT commands over a serial port to talk to a modem, sending a PostScript file to a printer and sending Open GL primitives to a Video Card.

Then the marketers came. The modem became a winmodem – all the work is done by the CPU. The graphic cards moved more & more work to the host CPU. The printers shed any inteligence and you need a huge & cpu-consuming application on your computer to render the images and just send commands to move the print heads/nozzles/lasers in the printers. My PostScript laser printer’s driver is a 34Kb PPD text file.

Remember that Richald Stallman started the GNU Project because it was denied access to the driver source code required to talk to a Xerox printer – he never requested the source code for the printer itself.

I think the biggest news is that the VideoCore is a REAL Open GL Video Card. No need to fuss with registers and bits that change between each release of silicon – you write portable Open GL ES code and send-it directly to the hardware. You can upgrade the silicon in the future for better performance and you can use same host software sending the same standard OpenGL ES primitives to the card.

Congratulations Broadcom. You’ve let your engineers do the right thing. That’s a company i would like to work for.

Your post could make perfect sense, if it wasn’t for a fatal flaw: You assume that the VideoCore IV is a magical piece of dedicated hardware that turns OpenGL ES commands directly into pixels on screen. However, it most certainly isn’t. No GPU is, and no GPU ever has been. The architecture used by Broadcom here (have a very high-level interface for the host CPU, do much of the heavy lifting in firmware on some oddball proprietary CPU) isn’t new either: early SGI graphics boards worked in a similar way, as did Nintendo’s N64 game console. The N64 is, in fact, a great example why access to the *real* driver in the firmware would be interesting: The default firmware (called “microcode” there) was quite slow and didn’t reach the full potential of the actual rendering hardware. In the end, many developers ended up writing their own microcode to get more performance and/or features. They could do that on the N64 because its hardware was fully documented or they had source access to the microcode (I’m not exactly sure which of these is true; could also be both). This does not apply to the BCM2835: We neither know what exact GPU Broadcom is using in the chip (there are vague rumours, but that’s it) nor do we have any documentation or source code for anything related to it. We only know the real driver’s interface now, which as I said is great for porting other OSes, but not for doing anything interesting with the graphics core itself.

Vague rumours?

http://www.lmgtfy.com/?q=BCM2835

If that is too vague for you, try this one:

http://www.lmgtfy.com/?q=videocore

Sorry, but how is this supposed to help answer the question? It’s obvious that there *is* an OpenGL ES 2.0-capable 3D graphics core buried somewhere within the VideoCore IV, it’s just not clear *which* one of the few that exist it is.

It’s an in house designed hardware 3D core, with in house implemented code to drive it. And the house is the Cambridge UK office of Broadcom. Is that clear enough for you?

Well, firmware blob is not a hardware, don’t you see? It is a layer between OS and hardware. What is the difference? You can rewrite firmware, but you can’t “rewrite” hardware, only redesign it. Well, for example, you experience bugs in Broadcom OpenGL ES implementation, but you can’t correct it (just can’t, because it is implemented in closed firmware). So, users are dependent on Broadcom. Consider opensource drivers for AMD GPUs. Yes, it also has firmware, but its so tiny that you hardly need to work with it when correcting bugs.

The “firmware blob” is not a “layer” – it contains the GPU microcode that on all the other video cards usually resides on a EEPROM chip soldered on the board and is updated maybe once or twice during the lifetime of the device.

Raspberry Pi has that microcode saved a file on the SD card and loaded at boot. And it’s updated by Broadcom very often. Have you found any VideoCore-related bug ? Report-it on the forums and the broadcom guys will fix it – they are being paid for this. You won’t get your bug report closed with “works for me” or “won’t fix” as on OpenSource projects with moody developers.

Yes, RPi users are depended of Broadcom the same way Radeon users are dependent on AMD. New LCD monitor with strange aspect ratio not detected at boot by the video card because of HDCP issues requiring a firmware update ? You need the manufacturer in both cases.

If you don’t want to depend on anyone, make your own video card by bit-banging VGA output on the GPIO pins or with DVI output with a fast FPGA.

Clearly the best comment of this post.
What Raspberry Pi and Broadcom did is great, but the way they hyped it in the post disappointed many people who looked into the details.

Can I express my thanks to Broadcom and the Pi Foundation for doing this. Even though i will not have the time to look at the code, knowing its available is a big bonus and will drive sales and future development of the Pi!

Thanks for the kind words. As Jim Manley mentions elsewhere, this is just one step along a long road for us. We remain committed to pressing for more openness in the platform as time goes on.

I guess that opens the way for some brave hearts to implement a full OpenGL library?

I think so. You’d need to stop at a fairly early OpenGL level (say 2.0), but certainly the glBegin()/glEnd() stuff should be implementable pretty trivially on top of what we’ve released.

Turns out this was a false promise:
http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDk
The entire driver is not open sourced, and the important parts are still closed source.

Not a false promise at all. All the userland code is now FOSS. This has meaningful practical benefits.

read the above article first before posting!

So how much is broadcom paying the raspberrypi team for doing marketing?

Absolutely nothing, because we’re not part of Broadcom.

[Edited to add: Additionally, I’d like you to step back for a moment and consider how the *many* people who work long hours unpaid on this project because we believe we’re doing a good thing here might feel to read that last comment of yours.]

Well, then you should as you are doing a fine job for them.

I thought Eben still worked for Broadcom, is that wrong ?

I’ve got absolutely zero association with Broadcom (not even stepped foot in a Broadcom office!). I think they have genuinely done a good thing here, which is worthy of praise.

The close relationship between RPF and Broadcom made all this possible, and of course, *all* benefit from it.

What’s more interesting it would be to find out hot many of the detractors posting here are paid by other companies or are plain trolls.

(i sysadmin the servers for a Apple-related site in my spare time and VERY interesting things are revealed if you do whois lookups on the IP addresses used by the most virulent forum trolls)

open is open period , half open is still closed.

I think this announcement is bit overdone, so is the hype for the raspberry.

The only thing really positive is the price

I think you are missing the point of the RPi. This system is a game changer! It’s the software and the community built around it that is the big news. And all of that is because we know the design at it’s hart will be around for a long time.

Don’t know what you did but it doesn’t seems to be as “Open Source” as it should:

http://airlied.livejournal.com/76383.html

“You cannot make any improvements to their GLES implementation, you cannot add any new extensions, you can’t fix any bugs, you can’t do anything with it. You can’t write a Mesa/Gallium driver for it. In other words you just can’t.”

http://i.imgur.com/NCfRG.png

And there is a lot of such comments over the internet.

I’ve dreamed for few seconds. :(

Please see Eben’s comment here: http://www.raspberrypi.org/archives/2221#comment-35063

Will it help making a Android version on the Pi?

Yes. Accessing the GPU from other OS’s is the main benefit of this announcement.

This is great news! Well done Broadcom and Pi team!
For those who are complaining “it’s not really open source blah blah” just imagine where Pi would be if there was zero FOSS at all. Answer: No Pi!

I think it’s just a case if people don’t appreciate what they HAVE got and will always want more no matter what they are given. (Don’t get me started on kids with iPhones, Sky TV, Xbox etc..!) ;)

Indeed. If these people are interested in helping make the Pi graphics stack more open source, there’s plenty of work that can be done with what we’ve released. We actually expose a pretty flexible context and buffer management service for EGL, GLES and VG and it would be straightforward to, for example, move most of the GL state machine onto the ARM side, leaving only the shader compiler and a little bit of drawElements() logic on the server side.

Sadly, there’s not much change they’ll do anything of the sort, so I’ll probably end up hiring a student over Christmas to do it. *Sigh* (but, speaking as a former Christmas holiday student, good for someone’s Lent term cashflow).

How would you “move most of the GL state machine onto the ARM side”? Is there a lower lever API than the OpenGL RPC calls?

Would this make the people who want to write Gallium3D driver or to improve/bugfix the OpenGL implementation happy?

PS: Personally, I think that, OpenGL ES 2.0 is quite sane interface for a graphics card. Unfortunately, it seems that the simplicity of the driver detracts from the fact that the overall architecture is quite open-source friendly.

Hi Eben,
I’m intrigued by your remark that you’d like to move most of the GL state machine stuff to the ARM. Doesn’t that defeat the whole purpose of having the DSP there to “offload” as much of the housekeeping work from the ARM CPU as possible? I imagine that the current architecture is a result of specific design decisions, so it strikes me as odd that you’d want to completely reverse course.

This is fantastic news :)

This announcement makes me happy. Considering buying BRCM stock now. People who have reservations: I’m in agreement but don’t think we should argue & fight in this thread. How about @ my blog? http://mwic.org/wp/?p=74

I don’t mean to be blunt, but wouldn’t that mean you’d be able to adapt that code for the GPU on any other ARM SoC?

I consider this a step forward, but only a rather small one. In fact, I find it sort of silly that Broadcom is now lauded for having done this awesome thing for FOSS, while I just wonder why this code hasn’t been open source all along. All it seems to do is provide translations like “if you want to tell the GPU to do X, this is how you tell it to do that”. There is no intellectual property of any kind involved. People are not suddenly able to improve the GPU performance, or fix bugs, or add new OpenGL functionality, or use GPU resources to accelerate other things. All of that is still off limits. The open source value of this code drop is only to make it easier for other OSes to be ported… and again I wonder why this wasn’t done all along.

But again, it is a small step in the right direction, unfortulately largely blown out of proportion. As long as big chip companies are involved, this has to be expected I guess. They ofter have their hands tied when it comes to IP integrated from other sources, so not much can be done about it. But Broadcom shouldn’t suddenly be viewed as a stallwart defender of open source.

For something truly open, I have more trust in something like the Adapteva Parallella (http://kck.st/UGQjG3). Not nearly as low cost as the Raspberry Pi, maybe similar in performance (25 Gflops), but unlike the Raspberry Pi GPU, all those Gflops are actually available to do whatever YOU like with them, and NOT limited to what Broadcom allows you to do with them.

This post make a similar point, its a step in the right direction, but a small one-
http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDk

I wish I had thank you money to shower on Broadcom. I’m afraid all I can do is join the crowd in offering you thanks and praise. Thank you!

If you want to shower money somewhere because someone is doing something awesome for open source, I suggest you check out the Parallella link to Kickstarter in my comment above. They need it!

I really really don’t see the problem. It’s a GPU, it speaks GL-ES type commands. Given the *awesome* performance of a low end ARM CPU at doing graphics setup this is common sense design. They make it sound like its some fantastic evil plot.

Not only that its exactly the same design as was used in some PC cards at various times including ones that had early Linux DRI support and is used on lots of ‘Unix Workstation’ hardware designs.

I can only assume Dave Airlie is also upset that he can’t step the disk head by himself on his hard disk.

If Dave insists on trying to block it going upstream once the code is tidier, take it up with Linus and other folk.

Alan

Made of win!

Well done Raspberry Pi Foundation. This is great news.

A lot of people are complaining, as usual, that this is not really open, that it is only a “shim” or “wrapper”. I think technically they are wrong. No part of the kernel, or driver, or user land is linked with and making calls into the GPU firmware. That firmware does not even run on the ARM processor. Ergo everything Linux side is Open Source. You can now take that code and adapt it for whatever OS you want to use or create.

Seems that if the firmware were blown into ROM on the GPU or indeed implemented as a sea of gates in the GPU, i.e. actual hardware the Free Software Foundation would give it’s blessing to all of this as Free Software. I would not like to argue the finer points of the definition of “Free Software” with them even though I find their stance a bit odd in this case.

I’ve worked with embedded systems for years and worked closely with many SoC providers, this is huge! This is like Microsoft releasing the source to WindowsXP or Vista.

And saying, do what you want, but we’re not taking any input – you want it, you deal with the problems, we’re washing our hands.

This is a bit confusing. Are you opensourcing the userland libraries,
or the driver itself? That is, the driver that drives the device as such, with the device’s full HW specification, as opposed to the way the device is used on raspberry (or elsewhere, for that matter).

Why isn’t this a Broadcom annoucement then (“here is the docs and here is the source for our GPU device”)? The actual driver for the device itself seems as closed before..

My comment got buried somewhere (kudos to the moderator for releasing it anyway).

Whether somebody decides to RE the blob provided for RPI, and get /any/ sort of help from Broadcom to have it even remotely acceptably running, I somehow doubt, given the history of B43.

For years, they, Broadcom, ignored the developers of linux drivers for their wireless adapters. Broadcom chose to not participate in development, ‘releasing’ only firmware blobs that they (the w folks) had to cut the wireless card firmware out from. B43 folks, in this situation had no other option but to cleanroom-RE the broadcom drivers; the result is, they worked, but many features, like hardware-tx-power-control, were for long time not entirely supported; still it worked better than the binary-only broadcom drivers.
(I’m not a developer of b43 myself, but I read-only the b43 developers mailing list since, what… 2006-7? Used my old 4318 wireless laptop since Ubuntu 8.04 or 9+… with b43 drivers, until other bits of its hardware almost died… haven’t seen Broadcom devels active on the b43 devel list before the N wireless hit the system)

Broadcom later decided they will create a driver, but only for their newest cards, the ones with N radio. But Broadcom decided they want to ignore the b43 developers efforts, still not participating in the process, not talking to b43 project (at least not in public) and even pushed for their driver be included instead.

This makes far more sense for a student board. At least now if a student wants to write an OS from scratch. and have some decent 3D features they can.

Its still a pain in but about the Videocore IV being off limits. Due to the arm chip limited speed in a raspberry pi every extra processor you can exploit helps. Fast jpeg decode/encode that videocore can do is useful. But there are many other formats commonly used. vorbis, png, svg…..

Its something I don’t get. Why broadcom and others think they have to be licensing road blocks for closed source formats? The result is not good for devices because the chip cannot to customised to suite need as well if you cannot alter the programming.

What about the firmware on the GPU that controls the boot process?

I`m excited, but I wonder does the documentation & code released allow for implementation on the videoCoreIV of hardware accelerated video compressor for opensource video compression like Theora, WebM (Google VP8) ?
If no, then it’s not so open.

I know this thread is a few days old now, but I’ve been reading through some of the rather abusive and obsessive comments and there seems to be some major misunderstanding going on. A driver is a piece of software that sits on the OS side of a hardware interface and talks to the thing on the other side. RPi Foundation has announced open source drivers, and provided them. The fact that in this case the interface is quite high-level (and that there is proprietary stuff on the other side of it), and that the two bits of hardware happen to be integrated onto the same piece of silicon, doesn’t make any part of the announcement a lie.

Maybe the naysayers are too young to remember using BIOS interrupts in anger, or talking to their printer using arbitrary command sequences over LPT: (those command sequences being what was documented, not how the printer worked internally)? Especially the latter was never seen as a problem. Offloading the hard work from a low-powered CPU to a dedicated black box makes technical sense, even if it’s not ideologically perfect. I personally am glad that a 1GHz ARM core doesn’t have to do 3D rendering as that sounds incredibly painful.

Like many others, I’d *love* to see inside the box to satisfy my curiosity, but knowing that Broadcom is a US company and knowing how broken the US patent system is (hell, the European system is bad enough) I can imagine all sorts of reasons why that’s not currently possible. This of course applies to the MPEG-LA nonsense too; Even if the Foundation wanted to make a stand against it, they have no legal avenue to do so as they’re caught between jurisdictions. Offering the “licence” as an add-on to keep the price down is a pragmatic compromise consistent with their stated goals. There are free software decoders available that you can run on the ARM rather than the GPU if you want to.

At the end of the day, you just bought a usable computer for twenty quid. Nobody made you buy it. You have to accept that at such a low price you just cannot expect the person/organisation you bought it from to fight all your political battles for you. You now have a fully open source ARM system that you can port any open source operating system to if you are so inclined (I personally look forward to throwing NetBSD at it at some point). You can drive a serial console from the GPIO pins if you like and then you don’t need a graphics driver at all. Nobody is stopping you from lobbying Broadcom to make the other core(s) on the chip open too, but it’s totally unreasonably to level accusations at RPi for proudly announcing something which absolutely *is* a step forward.

@Liz: It might be better not to engage with people whose tone is abusive or arrogant. When your project is a labour of love it’s easy to become emotionally compromised and lose sight of what you’re trying to achieve. That said, the “Google me” comment by a certain poster did make me laugh…

“Maybe the naysayers are too young to remember using BIOS interrupts in anger, or talking to their printer using arbitrary command sequences over LPT: (those command sequences being what was documented, not how the printer worked internally)? Especially the latter was never seen as a problem.”

Funny you should say that, one of Richard Stallman’s motivations for starting the GNU project was that he could not modify the firmware in a printer. So I can guarantee you that it was seen as a problem, all the way back to 1980.

I probably should have said “rarely” rather than “never”, but in fact this is a red herring as RMS’s story was about a closed source printer *driver* that he couldn’t modify to be a bit less braindead: http://www.gnu.org/events/rms-nyu-2001-transcript.txt

There’s a reason I referred to the cases where the printer control codes were documented by the manufacturer (i.e. you could write your own driver without reverse engineering or signing an NDA, as I have done myself in the past), as the current situation with the RPi is much closer to that. We don’t have access to the inside of the box (which is a shame), but we do have a documented interface to it.

Incidentally, the most relevant quote from that RMS transcript is: “You know, there’s a big difference between less than perfect, and evil. There are many gradations of good and bad. We have to resist the temptation to say, if you didn’t do the absolute best possible thing, then you’re no good.”

This is wonderful news, and opens up a lot of really exciting opportunities Congratulations to everyone involved.

Will developers be able to use the OpenMAX DL API? That would be awesome.

News

Latest posts

Dragonfly Spectral Line Mapper

Refurbished vending machine

DSO-500K oscilloscope | HackSpace #67

Antarctic Picam | The MagPi #130

Next Post

Thursday grab bag

Previous Post

Call for guest posts!

Share this post

301 comments

exartemarte

asb — post author

jp.hickson

Peter Green

Alex

David Hardingham

Pavel Holica

Pavel Holica

Pavel Holica

Steve

André

AlexSmith

Alf

Ryan

Cata

Cata

ladyada

João Reis

Luc Verhaegen

zoobab

san

makomk

delay

GreaseMonkey

binary

foo

hwizzlez

Nick

KenPem

khulat

kolk

kolk

Arker

Luc Verhaegen

Luc Verhaegen

ikbel

ukscone

John van Dijk

Lefty Goldblatt

asb — post author

el_es

eben

Max E.

pd

Max E.

Aissen

Matt Hawkins

Scrofulous Mawgrim

Likes Dogging

Rob

JamesH

Rob

binary

David Srbecky

Paul Hanlon

Rob Bishop

Frank Earl

Jason Ozolins

John Ericsson

Josh C

tobestool

Rob Bishop

pd

Rob Bishop

pd

Rob Bishop

Rob Bishop

Thomas