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

Raspberry Pi VideoCore driver code released

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 17:57 UTC (Wed) by glisse (guest, #44837)
In reply to: Raspberry Pi VideoCore driver code released by dw
Parent article: Raspberry Pi VideoCore driver code released

You want to know where the line is ? It's right there in front of your eyes :

Can you improve/fix/increase performance of GLES/GL with what have been released : no

Could you do such things if the firmware was opensource : yes

Then go compare other GPU, for instance firmware of AMD or NVidia GPU are mostly glorified register writter engine that are there so one does not need to constantly use the CPU to change GPU state. You can improve the opensource GPU driver for AMD or NVidia without knowing anything about the firmware. For this broadcom GPU you can't.

Which is why me and many other open source GPU driver developer just see this announcement as a complete lie.


(Log in to post comments)

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 18:51 UTC (Wed) by robclark (subscriber, #74945) [Link]

I guess the closest analogy I can think of.. this would be like any of the other GPU vendors opening up their EGL implementation. It is better than any of the other ARM GPU players have done so far (which is not to say much), but it certainly is not an open GPU driver.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 19:55 UTC (Wed) by Lumag (guest, #22579) [Link]

Hmmm. Please expand my register-based nVidia Riva TNT2 to OpenGL 3.1

Of course I see your point. And I (mostly) agree with all the comments telling that Broadcom did less than the say in PR. I would certainly welcome disassembling/reverse engineering of broadcom firmware (it is doable, nouveau people did it for firmware-based cards). What I'm telling is that the border line is not that straight and clear.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 20:16 UTC (Wed) by GhePeU (subscriber, #56133) [Link]

I was going to say the same. I love the work TI is doing with the Pandaboard (they opensourced all they could, they're collaborating with the community, using a modern stack, expanding the closed source components to support Wayland, etc.) but the moment they stop development it's over, the pvr binary works with specific X and kernel releases and we'll be stuck with those forever.

In this case, the driver exposes some level of OpenGL/GLES, and all the rest can be built on that; if there are bugs or if some new extension is required there's nothing to do, but it seems to me that this is a lot more than what's possible with other SoCs. At least that's what I understood, please correct me if I'm wrong.

PS. robclark, if you're TI's robclark, I'm a fan! fan of glisse too, I've been using a r300 card for years.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 20:58 UTC (Wed) by robclark (subscriber, #74945) [Link]

Yeah, what BCOM has done should be enough to enable the community to add support for different window systems, and that sort of thing. So it is certainly better than nothing, and certainly better than what what the other embedded GPU vendors have done so far. But not as much as their PR would lead you to believe.

I think the progress on open drivers for mali and adreno, and what is starting to happen on tegra, is a lot more interesting and more beneficial for the community in the long run :-P

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 21:27 UTC (Wed) by dlang (subscriber, #313) [Link]

> I think the progress on open drivers for mali and adreno, and what is starting to happen on tegra, is a lot more interesting and more beneficial for the community in the long run :-P

Hard to say.

On the one hand, a reverse engineered driver with access to low-level functions gives you a huge amount of capabilities with that system

On the other hand, having the Vendor directly open up the driver, even if there are only high-level functions available to the GPU is likely to mean that future GPUs from this Vendor will ship with similarly open drivers and not need reverse engineering to function.

Which is better?? hard to say. In many ways, having the Vendor loosen their grip on a part of the stack is much better than having reverse engineered drivers, even if those drivers give you more capabilities.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 7:51 UTC (Thu) by nhippi (subscriber, #34640) [Link]

> Yeah, what BCOM has done should be enough to enable the community to add support for different window systems

What BCOM has now done, allows community to keep maintaining code regardless of how the kernel/X abi's change over time. Compare it with OMAP and PowerVR, once TI stops supporting beagleboard/beaglebone/pandaboard, community is stuck with the X and kernel's that remain compatible with last binary release of PowerVR drivers.

Community still can't fix any bugs in the BCOM firmware side or add new gl extensions - which can become a problem if new versions of X/wayland/whatever need a new extension.

But it is a step in the right direction.

> I think the progress on open drivers for mali and adreno, and what is starting to happen on tegra, is a lot more interesting and more beneficial for the community in the long run :-P

What worries me is the long run might take too long. Once mali400 and adreno support starts to work, SoC vendors may already have migrated to newer GPU designs.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 13:05 UTC (Thu) by robclark (subscriber, #74945) [Link]

yup, what BCOM has done is an improvement over what any of the other ARM GPU vendors have done so far. I'm certainly not criticising that. But it amounts to an open source EGL plus a GL shim, not a GL driver.

Perhaps the line is blurry about when a firmware is just "some microcode" and when it is a driver. In this case, the "some microcode" on r-pi runs threadx, it includes the shader compiler, and basically all the GL APIs map 1:1. This is most certainly not just "some microcode". Since, afaiu, the display hw is also controlled by the videocore cpu/coproc, you could probably port some gles apps and run them directly on the coproc, if you had the src to that "some microcode". So the line may be blurry, but the r-pi is so far past that line that it doesn't really matter.

So I'm not criticising what was released.. I'm only criticising that it was called an open source driver, when it clearly was not.

-----

As far as the open source drivers keeping up w/ new generations of hw.. well, it is true to some degree. But there has already been a huge amount of progress in the last year or less. Of course if it is always based on r/e products that are already released then we'll always be a bit behind. I would hope that eventually we can get to the point where some GPU vendors start working with the open source community, releasing specs, etc, like AMD and intel do in the desktop world.

At least on the plus side, we don't have the huge reclocking complications like there is on desktop GPUs. For the ARM embedded GPUs all the clock control is in the open src kernel drivers. (Well, maybe not the case for r-pi, but at least for all the mainstream embedded GPUs.)

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 20:24 UTC (Wed) by dlang (subscriber, #313) [Link]

This is like complaining that your modem cannot be upgraded because you can only talk to it via the AT command set, while other types of modems (i.e. winmodems) require that you do far more processing in ram, and therefor require lots of special drivers.

I'm actually very happy with everything that runs on the ARM now being open. This means that as these pieces get accepted the the upstream kernel I can now compile and run my own kernel on the pi, while getting full graphics support and without having to wait for any vendor to update their drivers.

In many ways this is far better than the situation for just about everyone on x86 systems. Yes, you can run the open drivers for AMD and the reverse engineered drivers for NVIDIA, but neither of those options will give you the performance of the closed drivers.

The fact that this is a high-level interface to the GPU does limit some things, but it also makes it possible for the GPU to optimize things that it couldn't do if the lower level interfaces were exposed.

Would I like the source for the GPU firmware? Sure. Especially with the DSI and CSI (display and camera interfaces) requiring that they be accessed through the GPU there are things that the hardware could do that we can't do with it since we don't have this access.

But this is a very good step in the right direction as it now means that everything that runs on the main CPU is open.

note that they are speculating on the option of releasing a different version of the pi hardware that would have this firmware burned into ROM instead of being loaded through the bootloader. This would satisfy the FSF and make the device both more expensive and less flexible. I hope that they do create such an option someday, simply so that we can get proof that all those people who whine about closed firmware won't actually pay more for something complient with their demands.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 22:14 UTC (Wed) by pboddie (guest, #50784) [Link]

I hope that they do create such an option someday, simply so that we can get proof that all those people who whine about closed firmware won't actually pay more for something complient with their demands.

While I'm sure that some people would like to point the finger at anyone objecting to closed firmware and put one label on them all, there is by no means widespread acceptance of closed, immutable firmware within the FSF-supporting Free Software community, let alone the open hardware movement. Of course, I wouldn't put it past the Raspberry Pi people to do what you suggest, as it would be quite the marketing stunt and yet another opportunity to be condescending to people with reasonable concerns.

From what I've seen, quite a few people are baffled by the argument that closed, immutable firmware should be approved by the FSF and feel that it would be far better if the FSF extended its principles as far into hardware as possible. Here, the FSF is actually being kind of pragmatic: if the functioning of an otherwise fully interoperable device depended on a proprietary software stack to make it functional through the loading of firmware, then mandating that the firmware reside in some kind of non-volatile storage and not require "updates" to unlock functionality somewhat levels the playing field for systems that need to work with that device.

However, I feel that the FSF would be better off withholding approval, even if that meant never or rarely giving approval at all, than granting it on the basis of apparently counterintuitive or contradictory reasoning. After all, the FSF is meant to adopt moral positions that are not necessarily convenient but which express a direction in which things should be moving. Telling people that they have arrived at this moral destination, when one would really like them to go beyond it, is arguably counterproductive.

Raspberry Pi VideoCore driver code released

Posted Oct 24, 2012 22:55 UTC (Wed) by dlang (subscriber, #313) [Link]

Most people will agree that the firmware on different layers is different levels of importance.

The idea that what matters is if it's in ROM or if it can be updated is the most bizarre boundary that I can imagine.

By far the most important thing is having the source to anything running on the main CPU

Next would be anything that can write to the memory without restraint (setting up an IOMMU that restricts where a card can write largely closes this one) because things can write to memory can interact with your main OS

For anything that isn't able to directly interact with memory is a peripheral of some sort.

The levels of openness on a peripheral are:

1. I can't use it.

2. I can use it only with some proprietary software that I don't know what it's doing.

3. I can use it with reverse engineered software, but I still don't know why the software is doing what it's doing.

4. the interface for accessing the device are documented so now I know what the software is doing and why

5. I can replace the firmware on the peripheral with reverse engineered firmware

6. I can replace the firmware on the peripheral with firmware that is using documented APIs of the peripheral internals.

I consider a peripheral that has the firmware in rom to be crippled as it forever prevents #5 or #6.

Almost all ARM devices are stuck at #2 (if they aren't at #1)

With this announcement, Raspberry Pi went from #2 to #4

Now, some people are complaining that the API to the GPU is a higher level than they would like. As far as I am concerned, as long as every OS that talks to this chip uses that high-level API, that's the appropriate API to put in drivers.

As a device designer, you may say that it's a bad API and choose to use a different device instead, but to declare that such an API should not be allowed into the kernel because it's too high level (like I've seen from some people) is wrong. High level or not, it is the API to the device.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 0:21 UTC (Thu) by airlied (subscriber, #9104) [Link]

the API to the hw device isn't known, but I can guarantee this isn't it. HW has in the past had an API quite close to GL (even nvidia does it kinda like that now). but the thing is GLES requires a compiler, no one sane puts a compiler in hardware, GLSL isn't at the opcode level, its at the C level. Not opcodes at an assembly language.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 0:46 UTC (Thu) by dlang (subscriber, #313) [Link]

The API to a modem is the AT command set

does anyone seriously think that this is what the bare hardware understands? NO. But this is still the API to the peripheral.

Unless there is some other way to interact with this GPU, this is the API for the GPU. You may not like it, or may want to have a lower-level API, but that's not relavent to what the API is.

let's look at storage.

you can have a very, very low-level API (MFM/RLL era)

step this many cylinders in this direction from where you are, wait this long from the 'start of track' marker and start reading/writing data

you can have a low-level API (IDE/ATA/SCSI era)

write this chunk of data to this disk block, potentially with reordering of actions

you can have a medium-level API (filesystems)

you say you want to create a new file and write to it, the filesystem creates directory entries, decides where the file will actually live, etc

If a device plugs into your network and implements the NFS protocol, it doesn't make your OS any less 'open' to use this device, even if you don't have access to the software running on this device, or if said software in in ROM

and you can have a high-level API

object based storage, think web based storage (although people keep talking about having this at the drive level as well), you tell the storage what blob you are dealing with and you read/write the entire blob

note that the way the storage is attached doesn't have that much to do with the API level.

you have experimental drives that you talk object based APIs via a SCSI buss, and you have SCSI level APIs that you talk to over an ethernet bus.

It doesn't matter that most GPU vendors are shipping devices where the API is at the same level as the old MFM/RLL hard drives. Having this GPU operate at a higher level (ATA/SCSI equivalent) may be a dead end, or it may be the wave of the future, people will disagree and only time will tell.

There can be very real advantages to having higher level APIs to devices

But in any case, API for this device really is the high-level interface. you can prove this by talking to it.

> no one sane puts a compiler in hardware

what about ACPI? I thought that handling those calls required a compiler in the BIOS

you may argue that CPI isn't sane, but sanity (expecially by the terms prior to a new thing being released) is a poor indicator for how successful something is going to be.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 0:54 UTC (Thu) by airlied (subscriber, #9104) [Link]

there is an ACPI interpreter in the BIOS, its not a compiler, it doesn't take highlevel C like language and compile it down to basic assembler opcodes, ACPI langugage is like assembly, GLSL is exactly like C.

But anyways I'm not sure why you think I care about your opinion, you've made up your mind that you want to live with what you are given by vendors, I'm more interested in what vendors can do to help Linux than themselves.

Like if I put the whole of Linux below the syscall interface onto a second CPU and didn't give you the source, but all apps called into it via an RPC interface, you'd probably think it was the greatest open-sourcing ever.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 1:18 UTC (Thu) by dlang (subscriber, #313) [Link]

> Like if I put the whole of Linux below the syscall interface onto a second CPU and didn't give you the source, but all apps called into it via an RPC interface, you'd probably think it was the greatest open-sourcing ever.

not the greatest open-sourcing ever no :-)

but if you were talking about open-sourcing the application and software running on the first CPU, I would say that yes, the system on the first CPU was open-source, even though it called an independent system that lives on the second CPU.

I don't see this as being significantly different from an Open Source tool that makes calls to Google Maps.

If it's running on a separate CPU, and it's not doing things like sharing memory, then it doesn't count as far as the Openness of the first software.

As others have noted, if you keep drilling down, you get to things like the microcode on the x86 CPU as something that's not open, and that you are accessing through a much higher level API from what the native chip supports. The x86 CPUs can even include compilers to convert the x86 instruction set to lower level code.

Does it make Linux any less free if it's running on a Transmeta CPU than on a 80386 CPU?

Does it make Linux any less free if it's running on vmware emulating a x86 CPU instead of on native hardware?

what about running Linux on an ARM emulator running on Windows instead of on a real ARM chip?

at what point does the manipulation of the commands before they hit the actual circuit mean that the API for those commands is not 'legitimate'?

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 13:23 UTC (Thu) by pboddie (guest, #50784) [Link]

but if you were talking about open-sourcing the application and software running on the first CPU, I would say that yes, the system on the first CPU was open-source, even though it called an independent system that lives on the second CPU.

I think the objections people have to this announcement are mostly centred on the assertion that Broadcom have opened up access to the underlying technology when in practical terms all they have really done is acknowledged the nature of the API for specific functionality provided by the SoC. And all of this publicity downplays the fact that they've moved software behind the curtain and onto the proprietary CPU core.

So although this release helps people to write software against that narrow API, it's very much business as usual.

Does it make Linux any less free if it's running on a Transmeta CPU than on a 80386 CPU?

Although you can have CPUs with loadable microcode, I don't think these arguments really help the discussion along because they inevitably lead to remarks like "You can't fabricate your own CPUs, and I suppose you extremists won't be happy until the proletariat have seized control over the means of production!"

Far more illustrative is to consider things like printers supporting standard interfaces like PostScript. It's a positive thing that you can (or could) get a printer that any system could talk to using a well-defined (and hopefully standard) communications mechanism, but it's a different matter from being able to enhance the printer's own operation, if this is desirable.

And it's always necessary to question the redefinition of system boundaries because you can easily end up with a dumb terminal talking to a proprietary mainframe that does all your graphics and printing for you. Or you have all your applications running in a proprietary cloud. And so on.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 20:26 UTC (Thu) by dlang (subscriber, #313) [Link]

did they move functionality, or has their chip always worked this way?

pushing functionality away from the main CPU and providing higher level abstractions and APIs is an ongoing process that has been going on as long as computers have been around.

The assertion is that everything running on the ARM processor is now open.

They have said for a while that the source for this userspace code was not going to be particularly interesting to people, but there was still a loud demand for this code to be opened. They did so and now people are complaining that it's not interesting.

no matter what you believe the boundary of openess should be, there is no doubt that this is a move in the right direction.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 22:07 UTC (Thu) by pboddie (guest, #50784) [Link]

It's actually not correct to bundle things like abstraction together with where functionality has migrated to over the years, mostly because functionality has migrated in different directions, whereas the level of abstraction in the components of the average system has mostly increased.

For example, video control was indeed done by the CPU in various microcomputers and then migrated to dedicated circuits of different forms and with increased sophistication, but other activities - notoriously, modems and printers - have seen the CPU bear the bulk of the workload in various periods. Much of this depends on whether it is considered worthwhile to have dedicated hardware for a particular task that could be done in software running on general purpose hardware.

I agree that for practical purposes being able to build these "drivers" from source increases the general level of support for the SoC in Free Software projects and is thus an improvement on the previous situation, but given the limitations on actually modifying the system's behaviour (the objections brought up by various driver developers), it's clearly not the milestone that we've been sold by the announcement.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 23:23 UTC (Thu) by ncm (subscriber, #165) [Link]

It depends on whether the second CPU has access to the RAM and devices of the first, no?

Raspberry Pi VideoCore driver code released

Posted Oct 26, 2012 9:37 UTC (Fri) by renox (subscriber, #23785) [Link]

>It depends on whether the second CPU has access to the RAM and devices of the first, no?

As if there wasn't other devices with drivers in the Linux kernel which has closed source firmware and which can corrupt your RAM with DMA.
If memory serves, the IO-MMU which can protect you from buggy devices is(was?) often deactivated because it didn't work correctly..

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 1:23 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

> what about ACPI? I thought that handling those calls required a compiler in the BIOS

No, ACPI code is never executed by the BIOS.

Sane companies and compilers in hardware

Posted Oct 26, 2012 0:11 UTC (Fri) by ncm (subscriber, #165) [Link]

"no one sane puts a compiler in hardware"

Funny that you should say this... Every 686+ chip produced by Intel and AMD today has a compiler in hardware. It takes for its input x86 instructions, compiles them to RISC operations, and peephole-optimizes the hell out of that. It is very unlikely that the shader compiler in this gadget is within one order of magnitude as complex as what is in every i5. Maybe not even two.

I don't know if those x86->RISC compilers are in rewritable microcode, but that's the way I would bet. That compiler's output has total access to all memory and devices. It might even run when you install new microcode, and doctor that, Ken Thompson-style, to have the same back door as the old.

There are probably good reasons for China to have their own, independent CPU designs, even at a cost of reduced performance. And for the rest of us, too, maybe.

Shader compiler on the GPU

Posted Oct 26, 2012 14:43 UTC (Fri) by alex (subscriber, #1355) [Link]

I don't think that was done for this particular release. As far as I can tell it's a design feature of this family of GPUs. So all platforms using the chip will use the same RPC like API to the GPU.

Raspberry Pi VideoCore driver code released

Posted Oct 26, 2012 18:30 UTC (Fri) by dlang (subscriber, #313) [Link]

> the API to the hw device isn't known, but I can guarantee this isn't it.

If that's the case, please point to the code that talks the "real" API

It's not in the kernel, it's not in userspace, so where is it?

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 6:52 UTC (Thu) by paulj (subscriber, #341) [Link]

The idea that what matters is if it's in ROM or if it can be updated is the most bizarre boundary that I can imagine.

It's a perfectly sensible boundary. Indeed, it's perhaps the only reasonable boundary you can draw if you wish to make a distinction between software and hardware. Otherwise they blur into each other. If your goal is to afford users/owners the same level of control over modifications as the designer (as it was for the FSF), then this is a logical boundary to draw.

If you have other goals could you draw other boundaries (e.g. "I want to change all code running on the main CPU", "I want to be able to verify all code able to access main RAM")? Sure, as you have done. However, to argue this invalidates the boundary others have chosen only demonstrates you've ignored why they chose that boundary.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 7:17 UTC (Thu) by dlang (subscriber, #313) [Link]

the designer doesn't have the ability to force you to run an updated program, or to plug in a offline update process. so the designer doesn't have as much control as you make them out to have

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 7:40 UTC (Thu) by smurf (subscriber, #17840) [Link]

Frankly I don't care why the FSF has chosen that boundary.
The point is that this policy prevents opening up existing devices – either by the original manufacturer or by somebody else.
So to me this makes no sense whatsoever.

If a philosophical argument, well-intentioned or not, results in less freedom, it is wrong. Plain and simple.

Raspberry Pi VideoCore driver code released

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

How exactly?

Raspberry Pi VideoCore driver code released

Posted Oct 27, 2012 10:56 UTC (Sat) by smurf (subscriber, #17840) [Link]

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.

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