Stallman Calls For Action on Free BIOS

Dolda2000 writes "Seeking to achieve 100% software freedom, RMS is now calling for action for a free BIOS. From the article: "The most uncooperative company is Intel, which has started a sham 'open source' BIOS project. The software consists of all the unimportant parts of of a BIOS, minus the hard parts. It won't run, and doesn't bring us any closer to a BIOS that does. It is just a distraction. By contrast, AMD cooperates pretty well." For reference, there are currently two projects for a free BIOS that I know of: LinuxBIOS and OpenBIOS."

Comments

Eat your own dog food....

[Gopal.V]

What ever you say about RMS - he does eat his own dog food. I heard about the pains the FreeBIOS team had in converting RMS's personal laptop to FreeBIOS sometime back. But all that said, I am NOT going to flash this thing onto my boxes. This is what I'll do -

You can help our campaign by buying AMD CPU chips and not buying Intel, and by publishing statements about what you're doing. Likewise, buy motherboards that support free BIOS.

According to the FreeBIOS website, Acer , Via and SiS support it . And it will probably see a LOT of Bochs in testing too. So I might opt for an Acer laptopt finally (it's cheap too)

The problem is, "what do you mean by BIOS?"

[wowbagger]

The problem with a statement like "We need a Free BIOS" is exactly what you mean by "BIOS".

There are two extremes to the schools of thought on this.

The first is the minimalist: The BIOS is just enough code to put the machine into a state where it can load the real OS, and once the real OS is loaded the BIOS is no longer relevant. At a minimum this code would just set up the basics of the machine, and then load some section of the hard disk into memory and jump to it.

The second is the maximalist: The BIOS should provide abstract access to all hardware so that the OS does not have to have drivers. The BIOS would provide routines for the disk controller, video, human interface systems (mouse/keyboard/etc.), memory control, system control, you name it. The OS would never get its hands dirty accessing real hardware.

Both of these approaches have problems. The Minimalist approach means the OS has to support all hardware - which is the lament those of us who don't run Microsoft operating systems will sometimes have. If your OS does not know about your shiny new FooCard then you are out of luck. In the ideal Maximalist case, the BIOS would supply routines to access all the functions of the FooCard and your OS would Just Work no matter what.

However, the problem with the ideal Maximalist approach is that desiging a BIOS API that will work with all operating systems is HARD . Your BIOS has to have a means of calling back into the OS (since real, non-trivial drivers need to have things like semaphores, queues, interrupt handlers, rescheduling points, etc.), but then you have to insure that all operating systems supply all those APIs with the same semantics.

Now, ask yourself, if you designed a BIOS callback API around the Windows semantics (drivers cannot block, drivers must schedule a deferred procedure call if they cannot complete, drivers cannot cause a page fault to swap) how different it would be from a Unix-y style callback (drivers can block, drivers can pagefault from swap, drivers run til they are done).

The current thoughts are "The OS knows best what to do, let the OS have the drivers".

Now, in the context of a Free driver, you have to decide where between the Minimalist and the Maximalist you want to draw the line. Do you want to force the OS to have the code to set up the memory handlers and PCI bridges, for example? If the OS can handle reprogramming the PCI bridges it sure makes PCI hotplugging a great deal easier!

If you look at the LinuxBIOS approach, it is more of a maximalist approach targeting the Linux kernel. This is great if you run Linux, but what if you want to run *BSD, or Windows, or CP/M-86?

It would be possible, barely, to do like my old Multia did - provide BOTH a Windows friendly BIOS and a *nix friendly BIOS, and a means to switch between them. But now you've just doubled (actually more than doubled) the work for a system manufacturer - he has to write a BIOS for Windows, a BIOS for Linux, an BIOS for NetBSD....

"Just publish the specs, and we will write the driver!"

Again, publishing all the specs is hard - there's always that little "Oh yeah, we found that if the temp is less than 5C you have to wait an additional 50uS for this part to respond to a query - it's not intended behavior but it is observed behavior, Charlie found that out."

And even if you can completely document all the specs, there is still the little issue of "How do I, the end user, get the BIOS for *my* OS flashed onto this board?" - if you think the manufacturers are going to flash boards with seventeen different BIOSes depending upon the customers whims... I have some oceanfront property in Goddard, KS to sell you.

Then there is the issue of add-in cards - how do you integrate any BIOS they may have on them into the BIOS on your motherboard?

Now, I know somebody will point out OpenFirmware - the idea that the cards provide drivers in a bytecoded language targeting an API