Freeing the firmware

Few of us have multiprocessor systems sitting on our desks - or so we might think. The truth of the matter is that a typical computer contains several processors, only one of which is normally considered to be "the" processor. The others make the various subsystems and peripherals work; they live on the motherboard, in the video card, in the network adaptor, etc. Each of those processors needs a program to run. Traditionally, this "firmware" has been burned into some sort of read-only memory in the hardware itself. Manufacturers have figured out, however, that some money can be saved by leaving out the ROM and forcing the host processor to download the firmware at load time. The firmware can be shipped on the installation CD, where it gets put into the system along with the driver.

Hardware installation CDs for free operating systems are still rather rare, however - and systems like Linux tend to avoid that approach in the first place. It is much nicer if the operating system simply works with the hardware presented to it without requiring a separate software installation step. The result is an easier experience for the user, and also for the hardware vendor, who typically does not want to try to support even a few of the numerous Linux and BSD variants in widespread use.

Shipping drivers with the operating system itself has generally been a successful approach. Linux systems work on a vast variety of hardware, including many devices which have long since ceased to be supported by their manufacturers. With few exceptions, users can upgrade to a new kernel and expect their hardware to still work. There is no need to go scrambling around the net looking for updated drivers.

If the driver needs to download firmware into the device, however, the situation changes. Somehow, the driver must get a copy of the firmware to feed to its hardware. The 2.6 kernel has a nice mechanism which allows a driver to ask user space for the firmware bits, but user space must have the firmware to answer those requests. The firmware can usually be found on the installation CD; sometimes it can be downloaded from the net as well. But users would rather not have to go looking for firmware just to make their computers work. And, if the device is not brand new, the installation CD may be lost; at that point, finding the firmware may be just about impossible.

So it would be nice if the firmware could be shipped with the operating system itself. The old practice of linking the firmware into the driver itself is frowned upon in recent times for licensing and other reasons. Loading the driver from user space is a fine solution, however; the firmware request mechanisms work nicely, and the distributors can deal with the problem of getting the user-space side of things working in a transparent way.

The only problem is that firmware typically comes with a restrictive license which does not have redistribution in mind. In many cases, firmware redistribution is prohibited entirely, or the situation is, at best, ambiguous. Thus, for example, the Prism54 firmware page reads as follows:

In today's legal climate, the "we figure it's only fair" license strikes some users as inadequate. Distributors, fearful of being sued, really need to have a license which makes their right to redistribute the firmware clear. Without that license, most of them will not ship the device firmware, and the distribution will not support the hardware in any sort of easy way. So attempts to get vendors to put their firmware under a reasonable license have been going on for years.

Recently, those efforts have been stepped up a bit, thanks, especially, to efforts in the OpenBSD camp. The OpenBSD developers, too, have been starting off with quiet, private requests to the vendors. If those requests do not get an acceptable response, however, a call is made for the community to make its feelings clear. The hope is that, if enough people send coherent, polite notes saying that their future hardware purchasing decisions depend on proper free operating system support, the vendors will wake up and allow that support to happen.

As the project has announced recently, this approach seems to be having some success. Atmel, for example, has just decided to make its firmware available under a BSD-style license. Theo de Raadt, who is behind the OpenBSD effort to make wireless chipset firmware available, told us that the situation is reaching the point where the vendors can be played off against each other. Enough vendors have made their firmware and/or programming information available that the rest can be credibly threatened with a loss of business if they do not follow suit.

Not all vendors are convinced of this fact yet, however, so the OpenBSD folks are asking for help in contacting vendors. If the Linux community joins in with the BSD crowd, our combined voices might just be enough to make a difference. OpenBSD is, in particular, looking to apply pressure against Intel and TI, both of which have not, as yet, made their firmware distributable. Target contacts for TI and for Intel have been published. Interested people are encouraged to contact these vendors and let them know that proper free operating system support is a deciding factor in how they choose hardware. Needless to say, these messages should be professional and polite; flaming vendors will not help, and could be counterproductive.

Some in the Linux community will, doubtless, be dismayed by the fact that this firmware is only available in binary form. The Debian project will argue for years on whether a BSD-licensed binary is distributable or not. The fact is that it would be fun to have the source and a toolchain so that interested people could reprogram their hardware. But that is unlikely to happen for most hardware, and, in any case, the situation is little different than with firmware which is distributed in the hardware itself. It's simply a cookie which must be fed to the hardware to convince it to do its job. If we can distribute the cookies with our operating systems, we can have hardware which works out of the box. That seems like a goal worth writing some mail for.

[As a postscript, it should be noted that talks with Conexant regarding the Prism54 firmware are proceeding. Prism54 driver hacker Luis Rodriguez tells us that the conversation is continuing and that he is confident that the issue will be resolved soon.]

---

(Log in to post comments)