About LinuxBIOS

Eric shows how performance and increased adoption of LinuxBIOS is attracting attention from embedded and cluster developers.
Is LinuxBIOS Doable?

Since the first IBM PC, the hardware architecture of the boot ROM has evolved considerably, so that today virtually every machine has a BIOS that can be upgraded in the field or recovered from a failed upgrade. The common technique to accomplish this is to have a socketed Flash ROM on the motherboard. The Flash chip allows software to update it while the socket allows replacement of the chip if the update somehow fails. With this type of hardware architecture, developing custom boot firmware is now possible. For production machines, you can update firmware with no special hardware, and during development you can recover if something goes wrong.

A downside to current PC hardware architectures is that normally boot ROMs, at 256KB, are too small. This is enough space for firmware, but it isn't large enough for the Linux kernel.

The Linux kernel can run from LinuxBIOS as well as it does from a standard PCBIOS, when the port is done correctly. To date I successfully have ported LinuxBIOS to three motherboards. On the latest board, the results of booting Linux from LinuxBIOS and the PCBIOS are indistinguishable. So while there are significant technical hurdles in porting LinuxBIOS to new platforms, these can be and have been overcome.

Having access to adequate documentation is a nontechnical factor to consider. Convincing hardware vendors to support LinuxBIOS, or to release the documentation for someone else to code it, has met limited success to date. Missing or limited vendor support is not a new issue for free software, and it has been overcome in the past—now is not the point in the game to be discouraged. It is worth remembering that without these kinds of efforts there would be no new hardware on which we could run free software.

What Applications Are Available for LinuxBIOS?

Currently two different interest groups are working on LinuxBIOS: one working on embedded systems and one building large-scale computer clusters. For these applications the legacy x86 firmware is suboptimal.

LinuxBIOS has a lot to recommend itself for embedded applications. As it is released under the GPL, LinuxBIOS is royalty-free. LinuxBIOS generally weighs in under 64KB and doesn't waste ROM space with unnecessary functionality. Because it isn't a legacy design, LinuxBIOS starts up fast, even without code optimization.

In August 2001, General Software announced a 0.8-second boot to LILO on an embedded board after a hardware reset. This is a reasonable amount of time to do the job, but under LinuxBIOS such impressive results are routine. I can load the kernel over the network from a cold power-on in two seconds flat on a dual-processor server board—without optimizing LinuxBIOS.

The small footprint of LinuxBIOS has impressed SiS enough that they have devoted a developer to port LinuxBIOS to their chipsets, aiming at embedded applications. This demonstrates one well-supported platform.

For computer clusters, which is what Linux NetworX specializes in, LinuxBIOS has a lot to recommend itself as well. The serial port is the native console, so you don't need video hardware. Serial connections can be redirected easily into a terminal server for remote console access. The early setup of the serial console also brings benefits. For example, LinuxBIOS can report all errors and hardware failures over the serial console. A normal BIOS, even with serial console extensions, will initialize the serial port too late in the game for some failures to be detected, and it will usually fail if the CMOS is cleared.

LinuxBIOS also supports network booting on most hardware platforms, allowing changes to boot options to be made simply by altering a setting on a DHCP server. Since the code is open source, if the network booting policy is not to your liking it can be changed. The fast booting of LinuxBIOS means that if you are debugging something and have to reboot a node, the hardware doesn't waste the valuable time of the system administrator.

The openness of LinuxBIOS and its focus on Linux allow it to be configured and managed from user space under the Linux kernel. Anything done from user space also can be set up to be done remotely. This is a great advantage in homogeneous clusters, allowing firmware changes to be made and managed globally instead of one node at a time.

With large numbers of machines, the probability of hardware failure is much larger than for a single machine. The reduced hardware requirements of LinuxBIOS—such as unneeded floppy drives, CD-ROMs or hard drives to boot from, and no need for a video card and keyboard to control the system—can lead to a less expensive and more reliable system. Fewer hardware components lead to a reduced risk of hardware failures.

For clusters, LinuxBIOS also brings the potential to plug in to the cluster and, with nothing more than the firmware running, have a machine that acts as a single system, instead of a rack that looks like a collection of nodes.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Anonymous's picture

begin 2c

unfortunately the linuxbios page contains a deadlink or two in reference to supported hardware...

not to decry the coolness of this project... very cool, interesting and motivation to buy a supported board as well...

it is odd how people can complain about support for something in a gpl project... especially when supporting that something, i.e. windows.. is not really necessary for the design considerations of the project... of course in the case that you run across a gpl project designed for a specific purpose and notice something that you would like the project to support, rather than complaining you need to create a fork...

end 2c

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

Given the fact that a growing part of motherboards are produced in China and neighbours and China is developing it's Red Flag Linux and a processor industry to gain national independence from American Intel and Microsoft and other manufacturers, it seems like an obvious project to support for China.

And they can certainly produce the market and the plants.

Europe will then be supplied from China as the patent infested American industry will be shutting most of the IT-industry besides MS/Intel down.

March on and relief the oppressed!

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

I don't claim to even begin to understand all the issues with green computing. However, why would one have a dual processor box and expect it to be green? After all, if you need the horsepower then the box prolly has no business going into green mode anyways.

What about UPX? (it's on sourceforge somewhere)

Anonymous's picture

Have you looked into UPX? It's an in-place executable (.elf, .exe, etc) decompressor.. very lightweight. Alot of people in the demoscene (scene.org) use it on their programs to keep them ultra-tiny. Check it out!

256kB limit

Anonymous's picture

The 256kB limit is mentioned twice. If that s such a bottleneck, couldn t it be overcome by using a tailored compression ?

Couldn t a little extra CPU to analyse the kernel image, maybe in light some extra statistics about the sources and the compiler proprerties, bring the 360kB down to less than 256kB ?

Re: 256kB limit

Anonymous's picture

Can it be written in forth to make it more compact.


Stand-alone! Includes operating system.

Compact! 2K bytes for core software.

Fast! Optimized object code.

Simple! Applications stored as source. No object library.

Innovative! Text compressed and pre-parsed

Just a thought

Some thoughts

Anonymous's picture

Investigating Amiga ROM methods might be an idea.

They could do (in 2.0 onwards) a heck of a lot of useful stuff, like selecting drives to boot from, run in fully accellerated GUI mode, loading non-native filesystems before any OS booting is done, preconfigure all hardware devices, etc, and then go on to boot the native OS in about five seconds on a lowly 50mhz machine with no L2 cache on a second rate HD.

Something like that for the PC that's clearly documented, unencumbered by nasty patents and licensing and such, that's not biased towards any OS, would be wonderful.

(Note however some things may not be possible with x86-type CPUs and 8259 interrupt controllers and the like, some of the AmigaOS's ability came from the chipset and other aspects of the hardware design. ON the other hand, some things on modern PCs could make other things not possible before, possible now, like being able to use flash-type roms, etc)

Re: Some thoughts

Anonymous's picture

Good points, fellow Anonymous.. :-) Just to let people know:

The Kickstart preconfigured the hardware from day one. That's the boot sequence's main function.. It's a POST, you can follow the progress by the screen colour changes. (dropped in 3.0, though)

We had autoconfig ever since the first Amiga came out.. No pesky irq or mem jumpers on our cards! Just bang it in and AutoConfig(TM) does it's magic.. That includes drivers that can come from the card's rom if wanted. And it worked correctly ever from the start too, by the way, unlike some kludge called PnP. Someone said that the PCI spec stole some Commodore patents regarding the Zorro bus, but I don't know for sure.

Loading of non-native filesystems from the RDB (partition table) came with ver 1.3, when it became possible to boot from other places than the first internal disk drive.

The boot menu came in 2.0, and was upgraded to have chipset degrading, pal/ntsc selection and an expansion card diagnostic screen in 3.0

The Amiga doesn't have any "bios detection" of the hard disk - it's all written in the Rigid Disk Block, along with any filesystems you'd like to use and of course the partition information.. All this sometime in the late 80s when the A2091/590 controllers came out ..

There's a certain reason why Amigans are such big zealots.. There's a lot of nice stuff in there that you don't see if you only ever used your A500 as a games console. :-)

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

I dont see a reason why 256k shouldnt be enought to get a basic linux running. Nobody exspects a complet system running from within the BIOS. making the network and some other heavy weights a module should be enought to trimm a std. linux below the 256k treshhold.


Re: Kernel Korner: About LinuxBIOS - Open Firmware

Anonymous's picture

What happened to IEEE 1275 and Open Firmware? I thought it was the future. It seems to have many of the needs of BIOS covered and a builtin programming language.

Re: Kernel Korner: About LinuxBIOS - Open Firmware

Anonymous's picture

IEEE 1275 aka Open Firmware aka Open Boot is from the perspective of LinuxBIOS a bootloader. It does not attack the fundamental problem of setting up the hardware on a board.

If you want to write an IEEE 1275 compliant bootloader go ahead. Loading it from LinuxBIOS or a legacy bios should be straight forward...

Eric Biederman

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

WOW I love this idea, I use Linux as a desktop computer, would a LinuxBIOS be the right thing for me? I would really love the capibillity to turn my computer on and off without having to seem my computer, i've also been thinking about making a "headless box" but I would want to make is so that all it's mantence would be remote, this might be the answer for me.

I have many more qestions Id like to ask such as,

Is this a mirco or mono kernel,and would it accept modules that reside on the harddrive? What about compaqs which have a softBIOS?

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

There are maturity issues with using linuxBIOS on

the desktop right now. Desktops are general

purpose machines so have to have more functionality solidly working to really support.

If you have lots of questions please see

the linuxbios contact page at:


Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

This idea amazes me as much as I think of it. I find it quite hard to understand why we haven't seen yet boards with just processor, memory, NIC and serial. Lots of them ;)

I think that if LinuxBIOS really catches on, mobo manufacturers will be driven to include more flash (as price of flash will inevitably falll).

So thank you for creating that demand!

Sasha (gsasha at cs.technion.ac.il)

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

Will (or can) LinuxBIOS be (made) generic enough so that

other operating systems can benefit from it too? Specifically I'm thinking about BeOS, which boots fast

enough that the BIOS initialization takes up the majority of the boot-time on many machines, mine included. If LinuxBIOS could be made to load the BeOS kernel, I could boot-to-desktop in about 7 seconds on my machine.

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

LinuxBIOS is generic enough now. All it needs is for the other operating systems to be ported. I wouldn't be supprised if issues turned up. When software becomes more widely used they small issues always turn up.

Eric Biederman

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

The "porting BeOS" part might be a bit hard, as BeOS is now defunct. But what kind of issues are you talking about? AFAIK, BeOS doesn't need the BIOS, so if LinuxBIOS initializes the hardware enough for the BeOS kernel/loader to find the harddrive I should be all set, right?

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

Well, here's my 2c on booting BeOS fast. I can understand fast initial boots for embedded systems, but do you actually need to reboot BeOS that often? Last time I ran it I had no issues with stability...

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

That's an awfully strange thing to embrace. Often people embrace slow boot times because you don't need to reboot. Stable OS users take it as a badge and the inferrence is that Windows needs to be able to boot quickly because it crashes.

Most people power-down their computers. From studies people have been shown that they are ready to use a new interface two seconds after sitting down at it (it takes this time to ready the mind to do something new). Waiting for anything isn't fun.

Although there are some issues with parrellisation of bootup (don't bring up the network interface after accessing a server) the boot process tends to be very linear. It's only a few elements that need to be loaded in order.

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

I'm building a home stereo component that is a BeOS based mp3 player. It's pretty much done, but the thing

that still bugs me a bit is that it takes 30 seconds or so from power-on to usability, because the BIOS sequence takes so long. A device that presents itself as a consumer electronics device should be as much "instant on" as possible.

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

I am not the author of the parent of this thread, but I'd like to point out that some of us live in areas (such as California) where it is advisable to shut down a workstation when it is not in use, in order to save electricity.

one question: laptops?i'd

Anonymous's picture

one question: laptops?
i'd be awesome if i could start up my laptop on the train without having to wait forever.

Re: Kernel Korner: About LinuxBIOS

Anonymous's picture

Great article! I enjoyed it very much.

Thank You LJ and supporters.....


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up and watch now

Sponsored by Skybot