Next Previous Contents

2. Project

2.1 Abstract

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.

2.2 Structure

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.

2.3 Tools and resources

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.

2.4 Feasability

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.



To conclude this study, indeed Linuxbios has fair argues on many points. Customization and reduction abilities tends to favor my embedded device development. Maybe you can find your trend in this bilan but it's surely not enough to draw out your Linuxbios project. From now on, I'll use Linuxbios to designate Linuxbios V2. Let's consider Linux and the Bios together and then to see that frontier.

Next Previous Contents