User: Password:
|
|
Subscribe / Log in / New account

Raspberry Pi VideoCore driver code released

Raspberry Pi VideoCore driver code released

Posted Oct 27, 2012 10:56 UTC (Sat) by smurf (subscriber, #17840)
In reply to: Raspberry Pi VideoCore driver code released by paulj
Parent article: Raspberry Pi VideoCore driver code released

That should be obvious.

Today I need to buy a device with closed-source firmware. It's available with the binary either as a BLOB, or on ROM. As the FSF says that only the latter is OK, so I decide to buy that.

Tomorrow the manufacturer finds a bug and releases updated firmware. Oops, mine is on ROM so I'm screwed and can't get the bugfix.

Next month somebody reverse-engineers the firmware and creates a free replacement. Oops, my device has the firmware on ROM so I can't switch.

Next year the manufacturer realizes the game's over, and releases the source code. Oops, my device has the firmware on ROM so I can't use that source code.

Yet the FSF says that firmware-on-ROM is OK while firmware-as-BLOB is not.
Plese tell me (or anybody else for that matter) how that makes any kind of sense.


(Log in to post comments)

Raspberry Pi VideoCore driver code released

Posted Oct 27, 2012 22:13 UTC (Sat) by paulj (subscriber, #341) [Link]

That's an interesting dichotomy. However, it will never exist. If a hardware vendor produces a board without a ROM, with drivers that have to download a blob to bootstrap that hardware, then why would they ever release a hardware WITH that blob on ROM? That hardware would be more expensive.

We could go into the economics of downloaded v fixed firmware. The former will be quicker to market, the latter will need higher quality engineering to avoid the expense of returns and so perhaps less buggy compared to the former. etc. The burned-in firmware will have had to have had to be developed in a more rigorous manner, with more QA. Potentially, it will have had to have been designed with more attention paid to the architecture (simpler/cleaner), with more complex functionality left to the host software. So there are side-effects besides freedom - the competing products will *not* be equal on quality / price.

In the field of networking, there are the more simple, functional network adapters and there are the more complex ones that require significant amounts of firmware. In ethernet, the complex firmware ones are things like the TCP/IP offload cards. In wireless, its the difference between cards that do lots of the 802.11 logical functionality onboard, and ones that are more like radio modems with logical 802.11 functionality left to the host. The more simple devices are ultimately more flexible, precisely because more of the software is implemented in the OS than by the hardware vendor.

Anyway.. A line had to be drawn somewhere (RMS can be quite pragmatic). The freedom to modify was a line. There may be other lines, and they have different trade-offs.

Personally, I'll hold my nose and supply firmware blobs to hardware that really needs it. However, the more that hardware is like a general purpose computing device and the more it's expected to be updated regularly, the less I like it, and the more I'll try avoid those products. The more a blob looks like something that needs ongoing software engineering, the more I want the software engineers concerned to be the Linux kernel developers. Unfortunately, that's perhaps too amorphous to draw a clear line between.

Raspberry Pi VideoCore driver code released

Posted Oct 28, 2012 3:41 UTC (Sun) by dlang (subscriber, #313) [Link]

> why would they ever release a hardware WITH that blob on ROM?

because the FSF will say that their device is Free if they do so, but won't if they don't.

for some segment of users, this is significant, and manufacturers aiming for such users (which most don't) would like to make their buyers happy.

The Raspberry Pi team mentioned the possibility of making a version that had the firmware in ROM, specifically to satisfy such users.

Raspberry Pi VideoCore driver code released

Posted Oct 28, 2012 16:23 UTC (Sun) by khim (subscriber, #9252) [Link]

To claim that this idiocy can never exist is just wrong. It was discussed quite recently.

And since noone of sane mind will ever think of designing something specifically for the FSF-lovers what you get is obsolete and crippled stuff with firmware which is not updateable not because it's so perfect that you never need to update it but because team which designed said hardware is disbanded and no longer creates new versions.

Is it really what you want to endorse?

As I've already said: FSF approach leads to the "solution" which is not only more expensive, but also less hackable! FSF's preferred "solution" is always, always, ALWAYS worse from the hackability POV!


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds