About LinuxBIOS

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

More than a year ago I was hired by Linux NetworX to work on LinuxBIOS, and I've been on a steep learning curve ever since. After working on LinuxBIOS, I am qualified to say that I have no question that the kernel code is high-level code and that C is a high-level language.

What Is LinuxBIOS?

When a microprocessor powers up, it starts executing instructions located in a ROM chip. These initial instructions are responsible for initializing the hardware (especially enabling RAM) and loading an operating system. The implementations and interfaces to this functionality vary from machine to machine, but its basic responsibility remains the same.

Figure 1. Boot Process Stages

On the Alpha platform the microprocessor reads an entire serial ROM, referred to as the SROM, into the instruction cache and begins executing code. The code in the SROM initializes the processor and memory and loads the SRM from a Flash EEPROM. The SRM then loads the palcode (basically the real kernel on the Alpha), initializes a little more hardware and loads an operating system. Since the firmware is split into two pieces, the SRM can be upgraded or even replaced. In fact, the initial design of the Alpha architecture specified that there would be different firmware (at the SRM level) for each operating system.

The x86 microprocessor begins executing code in 16-bit mode at 16 bytes short of the end of the address space, with the CS register pointing to 64K below the end of the address space. On the 8086 this is at address 0xf000:0xfff0 == 0xffff0, just below 1MB. On the 80286 the address is 0xfffff0, just below 16MB. And on the 80386 and above, this space is at 0xfffffff0, just below 4GB. For the 286 and later Intel processors, the value in CS is not one that you can ever load again. To compensate for this, the hardware maps the ROM chip at both 0xffff0000 and 0xf0000.

Unlike the Alpha, x86 processors fetch instructions one at a time from the ROM chip. As ROM chips are essentially ISA devices, this leads to some interesting consequences, the first being that until some form of caching is enabled, the code runs quite slowly. The second effect is that the chipset must come up mostly enabled, as the usual path to the ROM chip is from the CPU to the Northbridge, to the PCI Bus to the Southbridge, to the ISA Bus to the ROM. When working with a known good board, this second fact makes the debugging of initial devices much easier.

The standard PC BIOS has the responsibilities of initializing the hardware, loading an operating system and providing a variety of services (mostly in the form of minimal device drivers) after an operating system has loaded.

SPARC and PowerPC architectures have specified firmware, also known as OpenBoot, Open Firmware or the defunct IEEE 1275. The standardized Forth firmware sits close to the same location that the SRM does on the Alpha. There are several unique things about Open Firmware: it runs on multiple processor and machine architectures; it uses a Forth-based byte code, so the binaries are processor-independent; and it does most of its system initialization from this Forth-base byte code.

The Itanium/IA64 architecture uses the EFI firmware and is more architecture-dependent than Open Firmware because its drivers are either IA32 or IA64 code. In scope it appears to be even more ambitious; EFI includes an IP stack and some filesystem drivers. As with Open Firmware, the early hardware initialization stage is not specified.

Requirements placed upon the firmware by the Linux kernel are minimal. The Linux kernel directly drives the hardware and does not use the BIOS. Since the Linux kernel does not use the BIOS, most of the hardware initialization is overkill. Linux is not alone in this respect; I don't know of a modern operating system that doesn't follow this trend. Modern operating systems require only basic system initialization services. Extra device drivers and system features that firmware like EFI, Open Firmware or even a PCBIOS provide are not necessary except to help load the operating system. Since these services are not necessary, the LinuxBIOS code does not provide them.

The LinuxBIOS code is sufficient to load a standalone program encoded as an ELF executable from a Flash ROM. A standalone program can be an operating system kernel like Linux, but most standalone programs are hardware diagnostics or boot loaders (e.g., Memtest86, Etherboot and RedBoot). LinuxBIOS is expected to be paired with a standalone boot loader in order to load the operating system.

The original idea of LinuxBIOS was to load the Linux kernel from the ROM and build a boot loader on top of that. The boot loader nbc implements this idea, loading a Linux kernel or a standalone program over the network and booting from Linux using the kexec kernel patch. This solution works fine when 512KB of ROM (or more) is available. Unfortunately, most standard motherboards shipping today have only 256KB of ROM. For the x86 platform it is nearly impossible to get a useable Linux kernel under 360KB.

Various strategies have been developed to address these systems limited by the amount of available ROM. Some of these strategies include Tiara, which appears to be a complete firmware and boot loader for the SiS630 chipset; Etherboot, which has been ported to work under LinuxBIOS; RedBoot, which runs under LinuxBIOS but is not yet useable; and some hacks on LinuxBIOS itself.

Alpha firmware requires a standalone program to be familiar with the motherboard it is running on, which can be problematic. While having this level of familiarity is nice, supporting a new motherboard can be extremely difficult because of the number of pieces of software that must be updated. With LinuxBIOS we do our best to avoid that problem.

We start with the traditional x86 approach: initialize the Super-IO chips to working and expected values (i.e., serial ports at their expected legacy address, IRQ, etc.) and then provide IRQ routing tables and mptables for SMP.

For the long term we need a table tracking the capabilities Plug-and-Play has identified. This software lists what hardware is present and configures which resources the hardware will use, or at a minimum it lists which resources an individual device uses. The solution I am working on involves creating a table of devices with information about how they are connected to each other on the motherboard. The table will list devices not currently participating in any kind of Plug-and-Play enumeration, as well as give enough information so that IRQ routing can be handled. Additionally the idea seems to fit in well with the struct device tree planned for the 2.5 kernel. ACPI appears to offer an alternative solution but it seems PC-centric, and the interpreted byte codes seem unnecessary and even dangerous.



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

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot