At the edge of kernel technology, operating systems and libre softwares, proprietary logic still keep the hand on. If theses systems tends to openess, softwares and hardware specifications used to initialize them via a code, the BIOS, remains proprietary.
But several years ago, pushed by necessity, researchers and some manufacturers team up in order to widen the field of use, and to free BIOSes from their initial, deprecated and buggy implementation. In this aim, some projects are now available out of laboratory use, such as OpenBios, FreeBios, LinuxBios.
The goal of this libre BIOS research and development project is to boot a linux kernel onto a thin client from a customized and derivated LinuxBios BIOS. Linuxbios is a project lead by the LANL (Los Alamos National Laboratory) in close collaboration with OpenBios and Free Bios projects. Primarily it has been made to work in a cluster environnement in order to wake and initialize machine grapes. Applications : Grid computing, parallel computization, massive calculus.
What Linuxbios offers is simple : build, cutomize and flash a BIOS into a chip : the CMOS.
I've started working on the initial version as Linuxbios evolved into Version 2. Totally refactored it is more easy to port, derivate, understand. This book describes how and why I have derivated Linuxbios to fit embedded device. Developments had already targeted theses devices but none led to a documention support available to the largest audience like this is.
First task was to qualify Linuxbios, to identify "the pros and cons", and detect future difficulties during development process. See the feasability study.
Second was to look for 'functional gaps' if exists and propose external simplest solutions. In other words, "integration is my friend". See the Linux and the BIOS study. See the software solution study.
Third task consist of an implementation I made in order to carry out a prototype. This is the pure HOWTO part. See the implementation.
Linuxbios father project from which my Linuxbios has derivated made me shiver by the time I realized plenty the sense of "bazaar organization". Do not let this blizzard frizz you to the bones : welcome to the Permafrost ! The source tree is "just" 800 subdirectories including 590 for the src/ directory ! All right, this WAS version 1.
Don't worry, version 2 is now just 350 including 240 in src/. But take this advice to you, do not dump too quickly version 1 from your CVS tree because this is a treasure cave talking about source code.
Let's also say this frankly : there were very few documentations in the immediate surroundings of Linuxbios. Nevertheless, useful informations have aggregate along Linuxbios pipermail forum and mail archive : forum questions/remarks and answers mechanisms works correctly. (cf. quick landmarks in Linuxbios maillist archive)
If you are ready to get started, I'am sure it's no use asking if you read the disclaimer or remembering you to save your personnal data, or remembering you to have a boot cd or a boot floppy at hand, or remembering you to save your CMOS state, or not to test code in root mode (as much as you could). hehh don't be that touchy, that was just to mention... ;)
Well, let's talk about architecture.
Please note this doc will not cover crosscompiling. I've worked in the simplest case : one machine, called build machine, will (guess what) build your Linuxbios from the source depending on software and hardware environnement. Actually, it is also the target machine. The other, called server machine, will recovers debug string from the BIOS while running. Moreover, it can serve kernel dynamically to the build machine to boot Linux or another OS : Windows, NETBSD, Plan9... You will see that the boot matter is merely described in this documentation.
When you'll have your Linuxbios BIOS burnt and running, you'll have to read debug lines to see and check out if sequence is ok or ko : this is debug mode. Typically Linuxbios send theses debug strings to serial port (ttyS0 aka COM1) but this could be changed. Theses strings couldn't be displayed onto the build machine because video card/chip initialization is done at the end of the BIOS sequence. Thus, build machine screen could remain off until video is set up. And this is why a null modem cable is needed to connect build and server machine serial ports. This enables networking... basic networking yes but networking anyway.
Linuxbios Test appareil showing the null modem cable connection to retrieve debug strings from client to server.
You can note that this is a classic serial cable, where Rx (Reception pin) and Tx (Transmission pin) crosses (crosswired). See here to make your null cable modem.
My target machine (build machine) is a VIA EPIA-M mainboard for which a bios will be build. It is powerfull enough machine to build a kernel self without having to wait too long. By the way, that is why crosscompiling can be avoid. See the complete hardware description of my build machine. Please refer to Linuxbios web site to get a list of supported, tested mainboards.
In order to qualify Linuxbios project but also to determine whether Mangrove Linuxbios could succeed or not, and under which conditions, I made various studies. Actually, Linuxbios as every project has its risks and ablities, typically if you derivate into another use.
There were visible success and hourrahs about BIOS first run in the forum. But some success were very humbles. This study's main objective was to collect testifies and experiences to draw a neutral review and to qualify Linuxbios.
Born in 1999, Linuxbios has grown but not all functionalites are tested. Some are newly available but are still unstable. There are two Linuxbios major versions V1 and V2. The later mainly responds to user's need to run it on recent motherboard. Best is to stand a constant technology review to get the lastest patchs and updates. It's also good to test functionalities and running BIOSes on a stress test protocol basis. Lastest notes : Linuxbios home site is fully refactored in a wiki style. More ports, ressources, docs are available.
Some low usage Linuxbios items are left abandonned. Most of the time, either that item malfunctions, either it is too much of a pain to get it working properly. Even sometimes, no one seems to understand its usage but if it is present in the main CVS branch, it surely had a past glory. If you don't want to make a bad choice, remember reading the very relevant changelog (when author had time filling it). Also look for the maintainer activity : too busy maintainer are like soccer's goalkeeper defending on several balls. If you'll have to work with V1 and V2 (eg. code porting) remember another simple idea : many compounds, many updates !
Apart from some manufacturers and hardware vendors, still most of them retain their specifications and informations. Obviously, such a bios program has to 'know' all of hardware layer to initialize it, so this is a major risk. Worse sometime you believe having endly an access to specifications whereas you just hold a commercial or marketing advert. looking like true papers. Stick working on manufacturers and vendors that actually support Linuxbios and get your stuff with them. Also be careful because, if you get relevant infos from an employee who is tied with a N.D.A (Non Disclosure Agreement) you could bring problems to the community, and your work could be tainted.
Linuxbios is reknown in enabling fastest boot time ever, 1 to 10 seconds to OS hand over depending on the OS. This is mainly because Linuxbios activates what is strictly needed by the kernel. On the other scale, Linuxbios project which follows an FLOS colloborative development have various active and skilled vulunteers.
It is important to note that what Linuxbios offers aims to be at least as good as original proprietary BIOS. Even better, most of the time theses BIOS are buggy, more rigid and less efficient leading to counter-performances. Because Linuxbios is ported to many hardware, it is bound to fit to your specific machine and it offers a wide OS boot abilities like Linux, Debian, Windows CE, Windows NTE, Plan9 and many more.
Linuxbios propose you to master the BIOS from the begin at BIOS init. time, down to the end at OS boot time. Thus, you have complete hand on the entiere loading of your machine, reducing the frontier of theses two codes. Theorically this spots redundancy and, if erased, permits some gains. Also, this spots that some attributions until now attributed to BIOS have to be redesign. Moreover, this type of bad assignments and drove-off generates capacity limitation which forces frequent updates and costly hardware renewal. At least but not last, accessing the BIOS source code permits inline tests from OS but also distant BIOS updates.
This early access to the BIOS widen the field of software actions. To the very first microsecondes of BIOS initialisation you can add your own compound : authenfication modules, splash screens, pre-networking pane, security pane, etc.. And of course, you can boot your OS from a IDE disk, a CDROM, a floppy, a compact flash (CF), a disk on chip (DOC), a disk on module (DOM), a distant disk (NFS)..
Linuxbios arrange your BIOS memory regarding to your chip size. If you boot your OS from a DOC/DOM, your BIOS could reside just beneath it, reducing BIOS+OS space to fit one uniq chip. Reduction it is also of the cost, know that your Linuxbios is GPL'ed, sparing you the expensive licensing costs of CMOS chip and BIOS software.