Raspberry Pi

[tufty]

If you wanna get anal about it, are you 100% sure the firmware on your hard drive is stable? Bug free? Devoid of artificial lifetime-reducing features? Non-malicious, given that it may be connected to a bus that allows total access to the host?

What if you come up with a fancy pants way of storing more data, or faster, or more securely? Got the documentation to do that?

Yeah, the rpi driver code is somewhat disappointingly light. But it most certainly is open, and the arguments against it are like my arguments against your hard drive above.

If you're gonna get paranoid about firmware, best not connect a network card, mouse, keyboard, any form of storage that isn't directly controlled by the cpu, a screen, /anything/ to your cpu.

[gravy]

Nah, you're completely missing the point.

It's like a HDD that can only do FAT. Not NTFX, EXT2/3, ZFS etc because it's been hobbled to be locked into FAT only.

The OGL implementation won't get any faster because of this. No one will be able to try and get OGL ES 3.0 running and if you want a different graphical API you're limited to whatever can be layered on top.

[Baggypants]

The benefit isn't the code. It's that a small charitable foundation have got Broadcom to opensource something. Just before Microsoft attempts it's ARMspace land grab.

[gumboot]

Nah, you're completely missing the point.

No, you're missing the point. The point is that it's important to know what kind of whitespace they use, because if you wirte your own code to use the same kind of indentation then everything will line up properly and so it'll be faster.

[tufty]

Nah, you're completely missing the point.

It's like a HDD that can only do FAT. Not NTFX, EXT2/3, ZFS etc because it's been hobbled to be locked into FAT only.

The OGL implementation won't get any faster because of this. No one will be able to try and get OGL ES 3.0 running and if you want a different graphical API you're limited to whatever can be layered on top.

No, I'm not missing the point at all.

The auditability argument is the only one that holds any water, and even that only from a very blinkered viewpoint.

No, opengl may not get faster (although the firmware has gone through a number of significant revisions since the launch, the videocore block is still current tech, etc etc). But it most probably wouldn't have got faster without broadcom help even if the code was open, for exactly the same reason that the dwc/otg usb driver has festered along for so long (since waaay before the pi, and on an awful lot more hardware) - there's a lot of people who moan, less who are willing to help, even less who are willing to dig into code, and a minutely small proprtion who are not only capable of fixing it, but have the time to do so. And that's for c code, not a mixture of c and assembler on an 'oddball' vector/scalar processor.

The situation is significantly less bad than an android device that isn't upgradeable to the latest version because the manufacturer want to sell you a new device.

And we're talking about a machine that costs less than a round of beers.

[venusian]

It's no different from using a hard drive for which you don't have the firmware source and toolchain.

Go on, then. What is this "it" factor which is invariant between using a hard drive and using a GPU driver? Are you asserting that everybody should be concerned with only that factor and none other?

People can be concerned with whatever they like however there is an "it" here.

Both are devices for which there's a defined interface to which your software is programmed. For the hard drive it's IDE or SCSI whilst for this GPU it's something alot like OGL. In both cases the interface is well defined and well understood and you can do whatever you like with it. Also in both cases behind the APIs is a pile of custom hardware which is most probably buggy, badly documented and quite shitty in places. The firmware will contain inexplicable bug workarounds, be will buggy itself and an embarrassment to it's creator.

In both cases, if you want to use the device you have to program to the interface because that's what the device provides and that's all you have. Where's the difference?

One could argue that the firmware's OGL implementation in the GPU is fundamentally different class of software to the firmware of a hard drive. I find it hard to see how this could be the case. The "depth" of abstraction from read/write block down to motor control is , IMO, arguably greater than from OGL to a pixel buffer.

[gravy]

Nah, you're completely missing the point.

It's like a HDD that can only do FAT. Not NTFX, EXT2/3, ZFS etc because it's been hobbled to be locked into FAT only.

The OGL implementation won't get any faster because of this. No one will be able to try and get OGL ES 3.0 running and if you want a different graphical API you're limited to whatever can be layered on top.

No, I'm not missing the point at all.

The auditability argument is the only one that holds any water, and even that only from a very blinkered viewpoint.

No, opengl may not get faster (although the firmware has gone through a number of significant revisions since the launch, the videocore block is still current tech, etc etc). But it most probably wouldn't have got faster without broadcom help even if the code was open, for exactly the same reason that the dwc/otg usb driver has festered along for so long (since waaay before the pi, and on an awful lot more hardware) - there's a lot of people who moan, less who are willing to help, even less who are willing to dig into code, and a minutely small proprtion who are not only capable of fixing it, but have the time to do so. And that's for c code, not a mixture of c and assembler on an 'oddball' vector/scalar processor.

The situation is significantly less bad than an android device that isn't upgradeable to the latest version because the manufacturer want to sell you a new device.

And we're talking about a machine that costs less than a round of beers.

Sorry I know a few people who think this sucks and have the time, skills and inclination to work on an open GPU.

It's kind of irrelevant though, the upset here are Rpi tooting their horns about the massive step of a SOC having a fully open source userland to driver implementation which relies on near ludicrous redefinition of what constitutes firmware and driver code. I mean yeah, this is nice but it's not what they're pimping it as. Getting indignant with your users for pointing that out is rubbish even if they are being a bit rude about it.

And we're talking about a machine that costs less than a round of beers.

That's cobblers. It's not the money you pay for a hobbyist computer that is expensive, it's the time you spend on it. I think some of the disappointment stems from the RPi being positioned as something akin to the open systems of old (like the BBC) when in quite a few ways it isn't and likely never will be.

It's kind of interesting that an intel based cheap platform like this would have been far more open.

But after looking at the code do you agree that this diagram is a load of tosh?

[gumboot]

It's no different from using a hard drive for which you don't have the firmware source and toolchain.

Go on, then. What is this "it" factor which is invariant between using a hard drive and using a GPU driver? Are you asserting that everybody should be concerned with only that factor and none other?

People can be concerned with whatever they like however there is an "it" here.

Well, not really. You only get your "it" if it's relevant to what those people are concerned with. Otherwise your claim that it's no different is false, because they may have an interest where there _is_ a difference.

Obviously they have to be different at some level, because one holds porn while the other draws triangles. There will be a degree of abstraction where they do become identical, but all I'm saying about any of this is that we don't actually have stated areas of interest from the people being criticised for their positions.

It's no good giving someone a red car when they asked for a blue one and criticising them when they say it's not what they asked for, or even that it's not what they were promised.

If I had to speculate on the focal point of a lot of the critics in this case, I would say that it's a linguistic matter. Shims calling into another CPU which implements a conventional graphics driver is almost certainly not how people would read "fully open-source drivers".

[edit]yeah... like gravy said.

In both cases, if you want to use the device you have to program to the interface because that's what the device provides and that's all you have. Where's the difference?

I'm not going to spend a lot of time on every single point, because it's tangental, but right here you fall into a circular argument. The device provides that interface and that's all you have simply because the software implementing that interface is closed. If it were open then this would no longer be the case. And it's just as true of a closed-source driver within the kernel, too. That provides an interface (as determined by Linux) and that's the interface you have to program because it's what the driver provides and that's all you have.

[gumboot]

The auditability argument is the only one that holds any water, and even that only from a very blinkered viewpoint.

The only one out of all of the arguments in the whole world which you already know everything about? Then I can challenge you on any possible argument I pull out of my arse and be assured that you will already have evaluated it and determined that it is not watertight?

And just how blinkered is that one, anyway? There's a _huge_ difference in the focus of reliability validation in hard drive firmware and graphics drivers. And you haven't even specified what the auditing is for. Is it for deliberately malicious code, or is it for security vulnerabilities? The leap of faith in trusting that a peripheral is not malicious is easy (if only by necessity), but security and reliability are problems that never go away.

Hard drives can reasonably be modelled as a conventional address+data system, where the address is controlled by the kernel (if you don't trust that then give up now) and the data is controlled by userland. It's very hard for malicious software to do anything bad via a hard drive short of just using up the free space, and it's the kernel's job to keep that shit under control.

With graphics, on the other hand, there... well fuck it, why would I need to go into it? Look at the history of graphics driver bugs contrasted with hard drive firmware bugs. Yes, hard drives have bugs too, but they usually wipe the system out before anybody figures out how to make a security vulnerability out of something like WebGL.

there's a lot of people who moan, less who are willing to help, even less who are willing to dig into code, and a minutely small proprtion who are not only capable of fixing it, but have the time to do so.

The raspberry pi community is probably not the best place to look for good engineers, but the reality is that you need only find the one to get something fixed.

In these companies there's always a whole lot more work than staff, and incoming bugs (both external and internal origin) need to be prioritised, even though a lot of them are really quite basic and could be handled by anyone. They can be low priority because the use cases of paying customers (proper paying customers, not beer-money customers) don't touch on those issues, even though they're a horrible pain in the arse for others.

This is a place where summer students get put to work, and the FOSS crowd can surely find amongst themselves a handful of people on par with a summer student.

Even with full-time employment I've still taken the time to fix the occasional bug in drivers in whatever kernel I was using at the time just because I was using it and I wanted it to work properly.

And that's for c code, not a mixture of c and assembler on an 'oddball' vector/scalar processor.

There are variants of the hardware which have no DSP at all, and those do have to run the graphics drivers on ARM.

[tufty]

Sorry I know a few people who think this sucks and have the time, skills and inclination to work on an open GPU.

And which open GPU are they working on?

But after looking at the code do you agree that this diagram is a load of tosh?

Nope. 100% of the code that runs on the ARM is open sourced. Yes, the implementations of the ARM-side stuff are, to put it mildly, "thin", but they are 100% open source. It may not be what you expect or want, but it's 100% literally true.

The auditability argument is the only one that holds any water, and even that only from a very blinkered viewpoint.

The only one out of all of the arguments in the whole world which you already know everything about? Then I can challenge you on any possible argument I pull out of my arse and be assured that you will already have evaluated it and determined that it is not watertight?

You can if you like. That all depends on the size of your arse, really. However, the bigger your arse is, the less likely it is to be watertight.

And just how blinkered is that one, anyway? There's a _huge_ difference in the focus of reliability validation in hard drive firmware and graphics drivers. And you haven't even specified what the auditing is for. Is it for deliberately malicious code, or is it for security vulnerabilities? The leap of faith in trusting that a peripheral is not malicious is easy (if only by necessity), but security and reliability are problems that never go away.

Indeed, and a hard drive is just as huge a security hole as a GPU (especially if you consider that it might be connected via a bus like firewire that gives read and write ability to anything that wants to become a bus master). From a security viewpoint, yes, unauditable code is a huge issue, and I can understand why the OpenBSD guys don't like it. Unfortunately, on *any* system there is a massive potential for unauditable firmware on various bus-connected devices, and that's a pretty hard hurdle to get over. Frankly, the FSF's position on "software" as opposed to "firmware" makes no sense at all. Which is why I said "blinkered". Firmware that is loaded at boot from an SD card is no less vulnerable or potentially harmful than firmware which is loaded from an on-device flash chip - to say that one is OK because it's pre-flashed and the other is somehow dangerous because it's not is a classic case of stuffing your head in the sand.

there's a lot of people who moan, less who are willing to help, even less who are willing to dig into code, and a minutely small proprtion who are not only capable of fixing it, but have the time to do so.

The raspberry pi community is probably not the best place to look for good engineers, but the reality is that you need only find the one to get something fixed.

But the one really huge bug with the Pi is the USB controller IP, which has been used all over the place (not only on ARM hardware, even), and which is generally considered to be a pile of festering undocumented shite. And yet the open source community, which has had both the opportunity and the need to fix it, hasn't done so. Why? Because it's hard, and because it needs skilled engineers with the time to devote to it. That's why my Powerbook G3 only gets 16 bit graphics unless it boots into Linux or BSD via MacOS, as well. For the open source community to fix something, it needs to be easily fixable, or to be something that's really stopping somebody (and in the latter case, it's usually when it's stopping a major corporation that it gets fixed, because paid manpower gets allocated to the task).

[gravy]

Sorry I know a few people who think this sucks and have the time, skills and inclination to work on an open GPU.

And which open GPU are they working on?

Lol, the X360 one mostly. If you're a dev it's fully documented. There's a fair bit of work also done by others on the fully documented intel integrated GFX chips.

But after looking at the code do you agree that this diagram is a load of tosh?

Nope. 100% of the code that runs on the ARM is open sourced. Yes, the implementations of the ARM-side stuff are, to put it mildly, "thin", but they are 100% open source. It may not be what you expect or want, but it's 100% literally true.

Fair enough for picking on the legal status of each item as it's the only part that bears even the slightest relation to reality.

That block diagram has the OGL driver layered on top of EGL in turn talks to the HW. A 2 second look at the code and it's obvious a load of bollocks that is. According to that diagram the vidcore wouldn't even know what an opengl is. In reality the GLSL compiler sits on it. In the GPU "firmware", tokenising, parsing, generated ASTs etc.

To be clear my definition of what and what isn't an open platform is neither here not there. Yours either to be honest but initial responses from some of the key guys on OpendBSD don't see this as an opening of the system either. It's textbook tivoisation. And do you know what? That's fine.

I just don't see why they're getting shirty for being hauled up for a pretty disingenuous press release.

[gumboot]

Nope. 100% of the code that runs on the ARM is open sourced. Yes, the implementations of the ARM-side stuff are, to put it mildly, "thin", but they are 100% open source. It may not be what you expect or want, but it's 100% literally true.

The claim they made was:

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

What was published was not the GPU driver. If it were then there would not be another one (a far more substantial piece of software) picking up those messages and moving stuff around, compiling shaders, setting up pointers, twiddling bits, and all of that classical "driver" business running on another CPU.

Indeed, and a hard drive is just as huge a security hole as a GPU (especially if you consider that it might be connected via a bus like firewire that gives read and write ability to anything that wants to become a bus master).

Indeed. And Thunderbolt goes so far as to take this vulnerability outside of your computer and expose it to anything you care to plug in.

But tell me, just how many hard drive firmware bugs have you seen turned around into security exploits? How many of these are remote exploits executable through your web browser through a simple click on a rickroll-like link?

As I said, choosing where to draw the line is very difficult, but it's pretty obvious that these two examples live very far apart on the spectrum.

Frankly, the FSF's position on "software" as opposed to "firmware" makes no sense at all. Which is why I said "blinkered".

I agree with this bit, but...

Firmware that is loaded at boot from an SD card is no less vulnerable or potentially harmful than firmware which is loaded from an on-device flash chip - to say that one is OK because it's pre-flashed and the other is somehow dangerous because it's not is a classic case of stuffing your head in the sand.

I would argue, without any great conviction, that having the balls to etch your code into masked ROM says a lot about the rigor applied to its development.

But the one really huge bug with the Pi is the USB controller IP, which has been used all over the place (not only on ARM hardware, even), and which is generally considered to be a pile of festering undocumented shite. And yet the open source community, which has had both the opportunity and the need to fix it, hasn't done so. Why? Because it's hard, and because it needs skilled engineers with the time to devote to it.

And your argument is that the closed-source drivers are a shining beacon of correctness, thereby demonstrating that it's a problem with the developers and not the hardware?

Sometimes hardware is just shit, and it doesn't matter who's set to work on it because it's always going to be shit. There are plenty of perfectly reliable drivers for hardware, and maybe it would have made some sense to build a product that used one of those IP blocks if it was meant to operated reliably with a Linux kernel.

Yes, there are a huge pile of underdeveloped drivers, but that's what the difference is between open-source code and documentation. On top of the problem that documentation is usually bullshit anyway (look at how NFS turned out), open-sourcing is exposing yourself to third-party bug fixes and enhancements, whereas documenting is just asking someone to repeat all your efforts from scratch.

[gumboot]

There are a couple of interesting Raspberry Pi -like boards coming out in the next month or so; both are based on the Allwinner A10/A13 which features a 1GHz ARM Cortex A8 CPU and 400MHz ARM Mali GPU.

Completely distracted from why I popped up here in the first place.

Cubieboard is trying to pull together 1k orders right now.
http://www.indiegogo.com/cubieboard

Entirely unrelated from that, VIA have hopped on the bandwagon too.
http://apc.io/

I've seen and forgotten quite a few similarly-priced things (including a lot of hackable boxed stuff bundled with Android), and the next cheapest one I can remember is Odroid-X at $129. That's more like the low end of the huge mob of $100-$300 SBCs based on Exynos, OMAP, Tegra, NovaThor, Snapdragon, i.MX, etc.. I think once you hit $100 it's worth trying to choose something that's not shitty, so stay way from the USB-based periphery (sadly, it looks like A10's ethernet is USB-attached, but at least it has proper SATA).

[tufty]

But the one really huge bug with the Pi is the USB controller IP, which has been used all over the place (not only on ARM hardware, even), and which is generally considered to be a pile of festering undocumented shite. And yet the open source community, which has had both the opportunity and the need to fix it, hasn't done so. Why? Because it's hard, and because it needs skilled engineers with the time to devote to it.

And your argument is that the closed-source drivers are a shining beacon of correctness, thereby demonstrating that it's a problem with the developers and not the hardware?

No, my argument is that hard problems are hard, and even in the open source world, it's usually corporations that take on the fixes for those hard problems. I believe one of the biggest committers to the linux kernel is IBM, for example.

The drivers for the dwc_otg controller are open source, and anyone can get at them. They're also crap, and it's taken the launch of the Pi to make people realise how crap they (and the underlying ip block) are - but the one person actually working on fixing them is Gordon, who is, I believe, being paid to do so by Broadcom. That's *core* functionality on many ARM, PPC and MIPS SoCs, been released as open source for over 3 years, C code that targets a well known API. And *nobody* has fixed it.

"It's not open source enough" is all angels on the head of a pin stuff. The Videocore code is firmware. It's firmware that happens to implement, amongst other things, OpenGL and that pretty much talks raw OpenGL to the CPU. But it's firmware, and the fact it happens to be on the SD card you're using to boot with rather than being burned into mask ROM is irrelevant - that's a system hardware implementation triviality; the SoC itself is perfectly capable of being booted from ROM, onboard flash, pretty much any storage medium you care to mention.

[gumboot]

No, my argument is that hard problems are hard, and even in the open source world, it's usually corporations that take on the fixes for those hard problems. I believe one of the biggest committers to the linux kernel is IBM, for example.

Well, I wouldn't say that hard problems are easy. What open source offers is summer students and reviewers. They can be put to work on some problems -- just maybe not the big ones -- and even if they're not going to put any effort in there's always plenty of them willing to pass judgement.

The drivers for the dwc_otg controller are open source, and anyone can get at them. They're also crap, and it's taken the launch of the Pi to make people realise how crap they (and the underlying ip block) are - but the one person actually working on fixing them is Gordon, who is, I believe, being paid to do so by Broadcom. That's *core* functionality on many ARM, PPC and MIPS SoCs, been released as open source for over 3 years, C code that targets a well known API. And *nobody* has fixed it.

I have no non-career-limiting response to that.

"It's not open source enough" is all angels on the head of a pin stuff. The Videocore code is firmware. It's firmware that happens to implement, amongst other things, OpenGL and that pretty much talks raw OpenGL to the CPU.

Who's actually saying that it's not open source enough? If you read through the comments, most people on that side of the fence are merely pointing out that the announcement is disingenuous because what they consider to be a "driver" hasn't been open sourced as was stated in the body of the announcement. The headline is literally true, but wording of the article is in dispute. Where people point this out a lot of them are simply having the headline, in isolation, reiterated at them.

In the same way as you say "firmware" over and over like it's supposed to set a clear boundary (and others try to euphemise even harder with preposterous use of the word "microcode"), the other camp is saying "driver" in the same way.

If you look at the comments on the announcement; rather than engagement with what they're saying, they get stupidly patronising responses followed by scorn and ridicule. Even some of the people who go to great lengths to say that they're really not being critical but that they merely see where the other side is coming from are falling foul of a "you're either with us or you're against us" attitude.