|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Tuesday, 12 December 2000||Author: Brian Richardson|
|Published to: enhance_articles_hardware/Hardware Articles||Page: 1/1 - [Std View]|
The Hardware never ceases to amaze us here at Linux.com. Just when I though I'd finally gotten rid of every non GPL'd program on my system I find out I can replace the BIOS too. Here to explain exactly what that means to us average joes is Brian Richardson.
Well, that's not really true. There's still the BIOS. But don't despair . there's a movement to make an open source BIOS. Let's discuss BIOS in the context of GNU/Linux and open source. This article focuses on BIOS in general, and digs a bit deeper into the software that makes your motherboard tick.
This article will cover several major points related to open source BIOS:
Author's Note: While many readers would prefer that I address the fourth point first, the first three points would have to be explained while explaining the fourth point anyway. So in essence the article would turn out the same no matter if the fourth point was first or fourth. Any reader who understands this argument should e-mail me so they can explain it to me, since I have just now confused myself.
1. What does the BIOS do?
BIOS ... Basic Input/Output System. Most users only see the BIOS as an annoying memory count and a setup utility for adjusting boot preferences. BIOS is the firmware on a PC motherboard that is responsible for starting your computer, testing memory, configuring its devices, and handing control over to a bootable media to load the operating system. So detecting memory size, enumerating the video device, handing out resources to PCI devices, and detecting a proper boot device all fall under the realm of the BIOS. Not bad for about 128KB of code.
After the operating system has loaded, the BIOS offers a set of "runtime services". Runtime services come in two forms: software interrupts and data tables. Many of your favorite industry acronyms, like APM, rely on BIOS runtime services. The runtime services provided by the BIOS are what allow backwards compatibility for "legacy" PC software. Software interrupts and the BIOS data found at fixed memory locations are what allow "DOS software" to work across a variety of platforms. The BIOS is a key component in the "backwards compatibility" aspect of the IBM PC platform (which is what made the PC so popular in the first place).
What's good about an open source BIOS?
The various movements for creating an open source BIOS for x86 platforms, like OpenBIOS, are very Linux-centric. Since the Linux kernel isn't designed like a "DOS compatible" operating system, it doesn't rely on many of the BIOS runtime services. The Linux kernel also duplicates some of the BIOS functions, like PCI device configuration.
So a PC system designed to only run GNU/Linux doesn't require many of the functions provided by the BIOS. If the functions aren't required, the code isn't required. Less BIOS code means a faster boot time, which is a serious plus. As long as the platform only runs GNU/Linux, a very compact BIOS can be created.
Once the basic framework for this 'open BIOS' is established, then the fun can begin. Custom boot logo, setup utilities, loading Linux from ROM, security layers ... the possibilities are as open as the source code. As long as the hardware configuration support is solid, modules for an 'open BIOS' can be created from standard C/C++ or assembly code.
Note: Many non-x86 platforms already utilize an "open firmware" model. Non-x86 platforms don't utilize a true BIOS, but do require a some form of "bootstrap firmware" to get going. Many of these systems utilize firmware based on an open standard, so the open source issue is no big deal in this market.
What's bad about an open source BIOS?
As with most GNU/Linux hardware support problems, the real problem isn't technical. Creating a PC BIOS requires knowledge of the system chipset, processor architecture, I/O devices and other system support hardware. Most, if not all, of these documents are only available under a non-disclosure agreement (NDA). Creating code based on documents obtained under NDA then handing it out over the Internet is a big legal no-no.
System Chipset: Hardware responsible for tying major system components together ... processor, memory, peripherals, bus, etc. (a.k.a. "glue logic" or "chipset"). The chipset of a motherboard dictates the processor architecture, memory technology and peripheral bus used by the system.
Even if the hardware documentation is freely available, it usually isn't released to the public until after the product hits the market. That means closed-source companies who signed the proper NDAs have had several months, if not years, to support the hardware. It takes a BIOS vendor about five months to fully support a new motherboard chipset, assuming all of their evaluation hardware worked properly. By the time a group of open source developers deciphers the non-NDA documentation, the product could be gone from the marketplace. Most system chipsets have a six month life-cycle ... I have canned goods older than that in my pantry.
Also be aware that many documents for BIOS developers, whether they be for the chipset or some industry standard, are only available by NDA. Many BIOS developer manuals are never released to the public. There are also a large number of ... er, "interesting characteristics" that are never documented. Many chipset vendors provide software workarounds to BIOS vendors via e-mail or telephone conversations.
Remember, that this diatribe was based on developing BIOS on new hardware. Now let's take the scenario of a developer who wants to port an open source BIOS to an existing motherboard. Even if the proper documentation has been obtained for the chipset (NDA or otherwise), the motherboard vendor may have done something "creative" that requires some extra BIOS code. This can be as minor as some cool blinking LED, or as major as enabling a PCI device. Some of this information can be derived through reverse engineering the existing BIOS, but mileage may vary.
There are also a few technical issues to consider when working with a BIOS, open source or not. The nastiest, in my opinion, is debugging. Assume our open source developer gets all of the proper documentation and schematics. A bug is discovered while writing the memory detection code for their motherboard. In this circumstance, most programmers write test output to the screen ... but that won't work in the BIOS, since video can't be initialized until after memory is initialized. A low-level debugger would be nice ... except it has to fit into the ROM, and INT 3 exception trapping won't work without memory either. This type of problem, like many in BIOS-land, require an In-Circuit Emulator (ICE) that sits between the processor and the processor socket. These generally cost $20,000, pretty steep for a weekend code warrior (two of my cars together aren't worth $20,000). While simple pre-boot problems can be fixed by creative use of a checkpoint card, ugly problems like SDRAM buffer-strength programming require industrial strength debugging.
Why are we discussing software in the hardware section of linux.com?
Now we address the last question, which is the one most wanted answered first. As you may have noticed, the BIOS is an integral part of the motherboard. Despite the fact BIOS is software, its link to the proper functionality of the system makes it part of the hardware. Many problems that are perceived as "hardware issues" are fixed in the BIOS. Then again, there are many "BIOS" issues that later reveal themselves as hardware problems.
BIOS development requires many of the skills that are found in hardware development. Application developers and kernel hackers leave their safe world of integrated development environments and kernel debuggers when traveling into the dark recesses of the little black ROM chip soldered to the corner of the motherboard.
Okay ... what does this all mean
As usual, one expects the last part of such an article to have a moment of clarity, where all of the author's disjointed ramblings are compiled to create a concise statement approximating a conclusion.
Don't you hate it when the author flattens your expectations with his SUV of uncertainty?
I won't go as far as saying that an open source BIOS will never be successful. I know I will eat those words like an Atlanta Falcons fan guaranteeing a return to the Super Bowl. I am always amazed at what the open-source community can pull off.
However, and this is the big however, there are many roadblocks that may prevent an open source BIOS from directly competing with the "established" BIOS companies. Twenty years of industry history, expensive debugging solutions, a lack of cooperation from hardware vendors and non-disclosure agreements the size of a Tolstoy novel are all big problems facing the open source BIOS developer. While many of these problems have already been faced by GNU/Linux developers, they are more intricate in the BIOS environment.
The benefit for developing an open source BIOS is in creating fast and lightweight code optimized for Linux. These attributes are usually sought in embedded hardware, which is an emerging portion of the Linux market. Slow boot speeds are what separate many special purpose computers from acting like home appliances.
The real question isn't if an open source BIOS will ever work on a handful of platforms, but if it will ever become viable for mass market across many platforms.