| |||||||||||||
Wow?Wow?Posted Sep 27, 2008 10:03 UTC (Sat) by tialaramex (subscriber, #21167)In reply to: Wow! by pabs Parent article: Atheros releases ath5k HAL code
All these wireless devices require firmware. If you can't see it then it's still a non-free binary blob, but one you can't even get to modify if you did have source. It's not clear how that qualifies as an improvement. Your video card, and many other hardware components (including modern CPUs) also have firmware, and no, their manufacturers don't publish it under a Free Software license either.
This article isn't about firmware, it's about driver code. The driver code runs on the host CPU, the firmware runs on the device. Intel have been releasing free driver code for years. Atheros are starting to catch up. Yay for Atheros, but don't imagine that tomorrow Atheros are going to publish the source code for their firmware.
(Log in to post comments)
Wow? Posted Sep 27, 2008 10:07 UTC (Sat) by johill (subscriber, #25196) [Link]
> All these wireless devices require firmware.
No, Atheros devices do not use any firmware.
Wow? Posted Sep 27, 2008 12:57 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
Yes, they do.
You're making the same mistake as the people who insist that you need to drink several large glasses of water every day to stay healthy - they can't see the water in the vegetables they had at dinner, or the orange juice they had with breakfast, or the sandwiches they ate for lunch, but it was still there, and not seeing it doesn't change that.
Atheros are even proud enough of their firmware to trumpet the consistency of the firmware code base between newer and older members of the same chipset family, which gives them an advantage in maintaining good quality drivers across the whole range. And right there on their block diagrams you will see the ROM with the firmware in it.
What Atheros don't do, which Intel and many other vendors do, is include the firmware in the driver package and upload it to the chip during startup. That makes a huge difference if you have a tight storage budget (say you're building a $50 set top gadget) but for the vast majority of Linux users it just means one more package to install.
Wow? Posted Sep 27, 2008 13:34 UTC (Sat) by ledow (guest, #11753) [Link]
Yes, but you're discussing the difference between a closed-source bit of code that has to be distributed with the hardware and one that has to be distributed with the software (i.e. subject to the GPL etc. restrictions).
I don't care that much about on-board firmware that works. Network cards have it, video cards have it, usb devices have it, BIOS's ARE it. It doesn't mean that having the source code available for that is necessary for operation of that device, which it is in some cases and is for the HAL layer of Atheros cards.
The last time I updated a BIOS was about six or seven years ago, and I would only EVER do it from manufacturer-supplied sources. It's the same thing - although it would be lovely to get the source to my current laptop's BIOS, I wouldn't try to use it, compile it or update it and use of it would almost certainly void all warranties. User-land code very rarely voids a warranty (the only case I can think of are the IBM laptops that could have their EEPROM corrupted by loading an I2C driver - and I don't know if IBM assisted in replacing such machines). The original firmware works, under all operating systems, and is supported and that's good enough for me. Future operating systems won't work on this laptop so there's no point "upgrading" to an OS BIOS to add features that it can't make use of. This BIOS will last the lifetime of the laptop.
This is how the internal stored firmware of any device is treated too - so long as it works for everything, it's fine. When it doesn't work, few people are going to want to make a permanent and therefore dangerous change to it even if they have the source. Whereas, devices that can safely update firmware on every boot by a simple upload from the driver - they should have source available because it's part of the necessary operating of the device from the factory and also because people might well tinker.
I have madwifi-supported cards and the freedom of the HAL layer for them is the only thing that has or will ever interest me. It means my kernel won't taint. That's all I care about. I'd love to have the source for the BIOS, firmware, every stored byte on the machine, but that's a very purist view. Atheros cards are basically "non-firmware" because the drivers do not require knowledge of the firmware.
One set of "true" firmware-less cards are those based on RT2500 and similar chipsets, which have entirely GPL, non-firmware drivers. But I don't know (or care) if there's a small EEPROM on there that holds the MAC, or a tiny embedded chip which DMA's data across busses... so I'm don't care if the "firmware" for that EEPROM/chip is available - I'll never need to know it and if the device fails, I'm stuffed anyway, whether I have the source or not.
Wow? Posted Sep 29, 2008 9:55 UTC (Mon) by jamesh (guest, #1159) [Link]
Considering the GPL issue, the firmware that is uploaded to the card looks like data to the main CPU (and hence Linux kernel).
If the Linux kernel and downloadable firmware are not considered to be separate works but instead one program (the point at which the GPL becomes an issue), why wouldn't the same apply if the firmware was uploaded into the card from a ROM?
The only real problem with downloadable firmware is how to get it onto the system. If the firmware is freely redistributable, then it can be included by the distribution. If it isn't, then the user needs to get it some other way, which is the problem.
Given that on the hardware manufacturer's side, the decision to go with downloadable firmware is economic (no need to include an extra ROM/flash on the board) rather than depending on whether they think users will want to modify it. So saying that downloadable firmware should be open source but firmware stored in ROM or flash shouldn't be seems quite arbitrary. Either it is okay or it isn't.
Wow? Posted Sep 29, 2008 13:10 UTC (Mon) by ledow (guest, #11753) [Link]
What about ROM's in the real sense of the word (i.e. one's that CAN'T be changed)? If the software CAN'T be changed, what use is the source? And the companies are not under ANY obligation to release ANYTHING if the binary blob is indeed proprietry. But if someone wants to write a GPL driver, then it (may be) impossible to distribute the binary blob alongside the driver.
The difference is in what's required for operation. A firmware source is not required for operation if it's stored permanently on the card with which it ships. Every card has a version of it, it comes from the factory like that and it may not even be able to be changed. If the company goes bankrupt, you're in no worse a position than before. All hardware has that code loaded and ready to go.
There may be "bugfix" versions of the firmware but the device is essentially another "computer" which your PC is talking to via an established communications standard (i.e. the card's protocol). Knowledge of that firmware's exact innards achieves little at great cost and because it doesn't need to be distributed AT ALL as "software" (except by the manufacturer in the original device), then it doesn't come under legal problems.
However, to RUN a card which does *not* have permanent firmware storage, then you have to have the firmware blob and the firmware blob is a required part of the driver code, no matter what the OS is. Because the blob is part of the code, that brings it into the murky realm of "merging binary blob with GPL driver code" (nobody's quite sure if it's allowed or not, but there haven't been any complaints yet). That's the problem, the solutions to which are:
1) There can be no legal GPL driver.
The legal definitions would be mind-boggling. Is my USB stick a "computer" because it contains a chip capable of performing operations on a private memory area? Is a PIC chip? Is hard-coded logic? Does this communication with a computer device consitute or require distribution of software code? Is that use legal under trade laws (i.e. can you sell hardware that is dependent on YOUR firmware code to operate and then forbid use of YOUR code to person X for reason Y? Are you required to let other people produce their own firmware code etc.)?
It's an absolute minefield, which is why the more that is GPL'd or licensed under even "more free" licenses, the better. However, there has to be a realistic limit or you're into "I want source code for your son and daughter too" territory and all co-operation halts.
Firmware would be great to have open-sourced but if I don't have the facility to use it at all (it's burned into a ROM) or I don't need to ever change it, I *personally* don't care about the source code for it. It's much easier than the hardware equivalent of soft-modems - where having to have a firmware blob (or other proprietry, non-distributed software) downloaded to the device every time I use it, the possibility of uploading the wrong firmware, the possibility of trashing the hardware with a faulty upload, the possibility of that being the only firmware EVER that operates the device because the company goes bust etc.
A GPL-only *driver* that can run on all OS is the ultimate goal for most people. That means not having to distribute other people's code (e.g. blobs, layers and protocols) but being able to control every visible part of the device. Anything past that is a bonus.
Wow? Posted Sep 29, 2008 21:20 UTC (Mon) by iabervon (subscriber, #722) [Link] But if someone wants to write a GPL driver, then it (may be) impossible to distribute the binary blob alongside the driver.According to the GPL (Section 3, last paragraph): "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." You may not be able to stick the firmware in the driver as a hex constant, and the firmware license may prohibit redistribution, but distributing it alongside the driver is explicitly permitted by a plain reading of the GPL.
Wow? Posted Sep 30, 2008 2:33 UTC (Tue) by jamesh (guest, #1159) [Link]
A Linux driver that supports firmware upload doesn't need to contain the firmware itself. For most modern drivers, the kernel asks user space to provide the firmware image and the driver then uploads it to the device.
During the upload process, the firmware looks like data: it just sends whatever data was passed by userspace to the card. When the device is operational though, you have two cooperating programs: the driver on the main CPU and the firmware on the device CPU.
My contention is that there is no distinction between the cases where the firmware is uploaded or comes on ROM/flash: if the two cooperating programs are considered a single work then the GPL would cover the firmware. If they are separate, then the GPL does not extend to the firmware. So the ability to create a GPL'd driver for the hardware shouldn't depend on the method used to load the firmware.
You bring up the problem of how to get the firmware if the company producing the hardware goes bankrupt. The firmware is still distributed with the device: just on a CD rather than a ROM. In such a case, it is just a matter of extracting the firmware from the CD (perhaps extracting it from a Windows driver). This is what people already have to do in cases where the manufacturer hasn't provided permission to redistribute the firmware. If they have provided permission to redistribute the firmware, then your distro probably already includes it.
Wow? Posted Sep 29, 2008 13:08 UTC (Mon) by cortana (subscriber, #24596) [Link]
Uploading firmware to a bit of hardware does not set the taint flag, at least in my experience (p54, iwl3945 drivers).
Wow? Posted Sep 29, 2008 13:38 UTC (Mon) by ledow (guest, #11753) [Link]
No, but using a driver that combines intimately with a non-GPL piece of software does. E.g. ath_hal, which is what this article discusses. ath_hal taints my kernel. As would the nvidia and ATI drivers that do the same trick (GPL wrapper around a blob).
Now that a free alternative to ath_hal exists, I can get non-tainting of my kernel. Which means I don't have to unload ath_hal in order to report bugs.
Wow? Posted Sep 27, 2008 13:44 UTC (Sat) by mb (subscriber, #50428) [Link]
What kind of weed are you smoking?
So if they release the sources for the code in their ROM, next you complain that they don't release the schematics of the chip?
Wow? Posted Sep 27, 2008 14:23 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
Not sure who you're addressing - I won't complain about anything, that's my point. I don't care about firmware, it doesn't run on my CPU and I don't understand people who think that their hardware is "less free" because the non-free firmware was included on a CD rather than burned into ROM at the factory.
Wow? Posted Sep 27, 2008 17:13 UTC (Sat) by drag (subscriber, #31333) [Link]
Well, there is 'firmware' and then there is 'firmware'. It's just generic term for 'code that runs embedded in a device'.
It can be anything from some thin logic so people don't have to make a custom chip to play it to a entire embedded operating system.
The firmware for my Intel Iwl3945 is 184KB. That's a bigger binary then most of the programs in my /bin directory. It's bigger then the BSD-CSH. So it's obviously doing some very fancy things and is far removed from the traditional 'low level logic' that most people think of when they think of firmware.
It's not something that I particularly care deeply about and it's not worth getting into a war about, or anything. But all firmware is not made equal and if your in the market for a card then this is the sort of thing that I would like to know about. The drivers for Intel's cards are all pretty good, but the firmware has been a source of instabilities and trouble in the past for me.
Just last week, the reason I know about the Thinkpad error stuff, is that I was working on my Mother's Laptop I got for her off of Ebay. The stupid thing wouldn't hold a network connection for more then 7 seconds (XP's ping utility said 'hardware failure', then it would reconnect quickly), and when it did disconnect it would kill whatever downloads were occurring. This made it nearly impossible to install XP's service packs over the network.
So I booted it up in my USB flash drive I carry around for these sort of occasions and was able to download most of the software I needed using Linux and the Intel wireless. Now the same exact errors were happening in Linux, but Linux handled it much more gracefully. Instead of losing the connection the download would just get paused for the second it took to reconnect.
I tried reseting the router and all that happy stuff. We contacted the seller of the laptop and he sent a new Wifi card. Same freaking behavior. Eventually just gave up on the Intel 802.11b and bought a 802.11g cardbus card and it worked perfectly.
I am fairly certain that this behavior was due to Intel firmware bugs. I've had similar issues with my Iwl3945 device, and this is a OEM installed item with OEM Linux support. (Dell 1420n). Nothing earth shattering and the Linux drivers were more then capable of dealing with this stuff nowadays. But it took tracking the iwlwifi website for a while and a few firmware upgrades to get everything stable in Debian.
Like I said before, I use Intel wireless and am happy about the drivers and their Linux support, so I wouldn't put off buying a laptop with Intel stuff on it, but it's not ideal.
------------------------------------
Here; I'll give a (counter) example of why it's you should not get all religious about firmware code:
(now don't take this as gospel, I am sure that I'll get several facts wrong)
The AMD/ATI 'Atom Bios' for their video cards. The Atom Bios is firmware provided to Linux/X Windows driver developers that take care of a lot of the low-level functionality that is necessary to do 2D drivers for their newer video cards.
Well the Atom Bios is a binary blob. So you ended up with 2 different sets of 2D drivers being developed in parallel, one that used the binary blob, and the other which said 'no binary blob' and they proceeded to learn how to bang bits about on the surface of the card.
Well the deal is that there _is_no_source_code_. The Atom Bios is mostly shipped as it's developed.. the code in the blob is the code that they more-or-less hand programmed.
Using the Atom Bios is not perfect, it's not ideal.. but the thing is is that with the next-generation of cards all the work on 2D drivers and related items are going to be totally worthless. They won't be programmable using 2D acceleration any more. That part in the video cards will be totally gone and replaced with all 3D-related logic. The newest cards now don't have a 2D acceleration core.. they use hardware emulation and the atom bios to allow code-level compatibility with older 2D drivers.
So instead of putting all the effort into 3D driver development, which is the only thing that is going to be sustainable long-term, we have 2 or 3 different competing 2D drivers; one of the major reasons we have this issue is because of the black-n-white 'no binary blob' outlook. I mean it's nobody's fault how this all worked out.. it seemed correct at the time to shun the Atom Bios, so don't think I am putting the driver developers down or anything. (I think what they are doing is great.)
Wow? Posted Sep 28, 2008 8:10 UTC (Sun) by PO8 (guest, #41661) [Link]
AMD decided to release the source code to AtomBIOS about a year ago. As far as I can recall, they've already done so.
Wow? Posted Sep 28, 2008 10:27 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Well, yes, but no. AMD did release this source code, but as the article tries to explain, it isn't source code that compiles into the AtomBIOS, any more than Intel's ACPI source is the source code for your laptop's ACPI tables. In both cases what we have is source code for an interpreter, because the "mysterious binary blob" isn't code for a PIC or DSP or something, but instead hardware-specific instructions for our driver running on the host.
There probably is some sort of source code for the AtomBIOS data itself, since the BIOS has to be customised for each product and there's no reason not to make that as painless as possible for the engineer assigned to do it. But since re-flashing people's Radeon cards isn't a practical solution to any conceivable Linux-specific problem there's no reason for anyone in the community to care.
Intel Wireless Probs? Posted Sep 29, 2008 13:00 UTC (Mon) by k3ninho (subscriber, #50375) [Link] You aren't facing the same issues that Evgeniy Polyakov has with an IPW2100? (See http://tservice.net.ru/~s0mbre/blog//devel/networking/ipw2100.)K3n.
Intel Wireless Probs? Posted Sep 29, 2008 14:32 UTC (Mon) by drag (subscriber, #31333) [Link]
Maybe. It wasn't my laptop so I didn't have time to really sit down and hack at it. The dmesg output mentioned 'firmware' however.
Keep in mind that it is happening on both Linux and Windows.
Wow? Posted Sep 27, 2008 17:26 UTC (Sat) by sbergman27 (guest, #10767) [Link]
What I really worry about is that even after I know that my OS and application software are Free, and find a NIC, and other peripheral cards with Free firmware... how do I know that the machines that made all my hardware were running Free software, and that any firmware their components might require was Free. If I call and ask the manufacturer, they could just lie about it.
Wow? Posted Sep 28, 2008 7:59 UTC (Sun) by johill (subscriber, #25196) [Link]
You're going to have to back up that claim a bit more than with handwaving, and I think you're talking about the 6k fullmac device rather than the 5k (and now 9k) halfmac device, because I'm fairly certain they neither include a ROM nor a generic MAC processor but rather contain the MAC in the HDL.
Wow? Posted Sep 28, 2008 11:02 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Atheros themselves don't seem to use the 5k / 6k / 9k nomenclature, but assuming that this isn't one of those situations (like with the Radeon GPUs we've also touched on in this thread) where a 6k can be a device numbered beginning with a 5, while a 9k is one beginning with a 3, then I think the Atheros pages speak for themselves, here's the statement used in the glossy for each of the 5xxx series designs I could be bothered to look at.
"A single driver and firmware code base supports all Atheros chipsets"
Let me reiterate, there is no reason in general why we should care about firmware or indeed care whether a binary blob we find on a device is in fact firmware (as opposed to a manufacturer's serial number, built-in presets, a look-up table to simplify some mathematics, or a vanity logo). There's no reason why the host driver should care how the host interface is implemented - what we need, to secure Free Software, is just the host interface itself, and Atheros, like Intel have done enough to provide us with that (though doubtless Theo doesn't agree with me). For all I know, the AHCI implementation in my laptop is just a painstaking gate-level design from scratch, while the implementation in the chipset for my server actually uses a tiny embedded microprocessor and forty thousand lines of C++. I doubt it in both cases, but more importantly I don't see any reason we should care - they both speak AHCI just fine.
Wow? Posted Sep 28, 2008 16:24 UTC (Sun) by johill (subscriber, #25196) [Link]
Yeah, I don't know what numbering Atheros uses, it's very confusing.
Anyhow, I agree with you, it doesn't matter much to me; although we have almost successfully reverse engineered Broadcom's firmware, which isn't possible if it's burned into a ROM. It just seems weird to me to burn it into ROM if you could save that cost which is why I always believed it was simply in the HDL. But yeah, it doesn't matter much since you can always treat firmware+cpu as one thing and combine it into new HDL too.
Wow? Posted Sep 29, 2008 20:15 UTC (Mon) by proski (subscriber, #104) [Link] We should not care about firmware that doesn't need to be distributed (unless we are trying to improve it or hack the hardware). But we should care about the firmware that needs to be loaded by the host system. That firmware needs to be distributed with the operating system. Operating systems have different policies, which may be incompatible with the license for the firmware. Even if the firmware is allowed to be copied freely, it may still be incompatible with a distro that aims to provide sources for every binary, whether it runs on the host CPU or not.Atheros cards would satisfy every distribution because no blobs need to be distributed at all. Sure, there are tables for register initialization in the driver, but I don't think anyone would treat them as binary blobs.
|
|||||||||||||