FOSDEM

LinuxBIOS is working hard to remove one of the last barriers to truly free computing. Learn all about it from the project's creator, Ronald G Minich.

What's your goal for your talk at FOSDEM?

I'd like to communicate the basic ideas -- that Linux is a good BIOS, and why; why LinuxBIOS is built the way it is; where we are going; and how people can help. Most importantly, why it all matters -- and it really matters a lot. We're on the verge of losing control of the systems we buy, and we need to make a conscious effort, as a community, to ensure this loss of control does not happen. That effort will not be without some sacrifice, but if we are to maintain our ability to use and program our machines, and have fun with them, we have to act now. Because, if the computing business stops being fun, what's the point?

We saw the mention on the LinuxBIOS website about one million devices shipped with LinuxBIOS. Could you tell us more about these devices?

Yes, these are internet terminals that were built in India, based on the [x86 system-on-chip] STPC chip, I am told; also, there evidently is a Turkish-built digital TV that runs LinuxBIOS. I have also heard that there are routers and many other embedded devices running LinuxBIOS. I think at this point that 1 million is a low number. I am in contact with other set-top box vendors that are talking about numbers in the 10s of millions for their products. These numbers actually make the OLPC numbers seem small, which is in itself amazing.

What kind of support have you received from chipset and motherboard manufacturers so far?

Mixed. Initially, SiS, VIA, and [ALi] were strong supporters, but they have dropped off in recent years. AMD has been a very strong supporter in recent years; Intel was initially very helpful, but in recent years have become a very strong opponent of LinuxBIOS. Tyan provided great support, but their support dropped off when they did not see a market appear (this problem was due to a number of issues, including an engineering-marketing disconnect). MSI is one of our latest supporters, and I think they may hit the sweet spot -- timing, internal ability, marketing, and so on -- that will spell success. Linux Labs, a system vendor, also shipped LinuxBIOS-based systems for many years.

iRobot had a major involvement, and, I understand, still use LinuxBIOS in one or two products -- but not the Roomba, sadly :-)

Linux Networx deserves special mention here. They have been a key supporter of LinuxBIOS, and in the early years were a major driver for our success.

It is clear that our major successes have been in the embedded market, such as routers and set-top boxes.

Could LinuxBIOS theoretically replace all BIOSes, of are there certain limitations to be taken into account?

It could in theory replace them all, and do a better job than all of them. At the same time, in practice, it's harder: chipset, mainboard, and system vendors are loath to reveal information we need. Rather than condemning these companies, I think we need to undersatnd their concerns and convince them that there is an upside to systems such as LinuxBIOS. We have to make a business case to these companies that the gain in sales dollars exceeds the cost of providing the information, and opening up what they consider to be, in some cases, trade secrets.

It is really the open source OS argument all over again; the same problems we had getting Linux drivers 10-12 years ago, we are now having getting info for LinuxBIOS chipset drivers. All the same arguments get trotted out all over again. It's just a matter of education.

Could you tell us a bit more about the BIOS side of the OLPC laptop?

OLPC is designed from the start as an open system. The chip specs are wide open (with one or two exceptions still being resolved); the board schematics are there for all to see. Because the system is open, OLPC can avoid using "standards" such as ACPI, which mainly exist to protect closed interfaces. OLPC can thus integrate functions into the firmware and kernel that, on other systems, would be locked away in the BIOS and ACPI. OLPC as a result will have far better control over power, and hence far better suspend/resume performance, than any laptop in existence. This improvement will be dramatic -- the system will resume so fast it will seem instantaneous. And, it will have a battery life that will be equally surprising for people used to commercial laptops.

OLPC will show what is possible with an open system that is not oriented to preserving proprietary interfaces and information. The customers will benefit, and, we hope, put pressure on other laptop vendors to provide a similarly high quality environment.

What exactly is the difference between "easy" hardware to write a BIOS for, and the "tough" hardware?

"Easy" hardware is documented; the vendor answers questions and provides sample source; there are lots of people familiar with it; the hardware is well designed, and simple to code to.

"Hard" hardware is undocumented; the vendor hides and obscures information; few if any people understand it; and it has obscure interfaces.

What are your thoughts on the Extensible Firmware Interface (EFI)?

I have spoken with the EFI authors at length. They make no secret of the fact that a "core value" of EFI is the preservation of intellectual property related to chipset programming and internal architecture. To put it another way, EFI is dedicated to the preservation of "Hard" hardware (as defined above), and the provision of binary interfaces and subsystems to BIOS vendors and others.
It is not really possible to build a full open-source BIOS if EFI is involved. The Tiano system, which Intel claims is an open source BIOS, can not be used to build a BIOS unless it is attached to proprietary, binary-only BIOS code provided by a vendor.

Another important thing to realize about EFI is that it also contemplates enabling chipset features that will trap certain OS operations to an EFI-based control system running in System Management Mode. In other words, under EFI, there is no guarantee that the OS owns the platform.
Accesses to IDE I/O addresses, or certain memory addresses, can be trapped to EFI code and potentially examined and modified or aborted. Many see this as an effort to build a "DRM BIOS".
I am not sure what the real intent of this design is, but is is a real concern in secure environments (such as those found in governments, banks, and large search engine companies). A number of vendors and users have told me that they are not sure they can ship an EFI system they are willing to trust in a secure environment.

Additional links:

• LinuxBIOS
• Ron's homepage

This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.