Recent Features
| |||||||||||||
Raspberry Pi VideoCore driver code releasedRaspberry Pi VideoCore driver code releasedPosted Oct 24, 2012 22:14 UTC (Wed) by pboddie (subscriber, #50784)In reply to: Raspberry Pi VideoCore driver code released by dlang Parent article: Raspberry Pi VideoCore driver code released
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.
(Log in to post comments)
Raspberry Pi VideoCore driver code released Posted Oct 24, 2012 22:55 UTC (Wed) by dlang (✭ supporter ✭, #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 (✭ supporter ✭, #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 (✭ supporter ✭, #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 (subscriber, #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 (✭ supporter ✭, #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 (subscriber, #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.
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 (✭ supporter ✭, #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 (✭ supporter ✭, #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.
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 (✭ supporter ✭, #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!
|
|||||||||||||