About LinuxBIOS

Eric shows how performance and increased adoption of LinuxBIOS is attracting attention from embedded and cluster developers.
What Hardware Does LinuxBIOS Support?

In the LinuxBIOS tree there are currently ports to 13 different mainboards. LinuxBIOS has been ported to both x86 and the Alpha hardware architectures. It has run on the AMD Athlon, AMD Duron, Pentium II, Pentium III, Alpha 211264 CPUs, ALI m1631, Digital Tsunami, AMD 760, AMD 760MP, Intel 440BX, Intel 440GX, VIA VT8601, SiS540, SiS550, SiS630 and SiS730 chipsets. And this is just the code that has been finished and placed in the main LinuxBIOS tree. Other ports are still in progress and haven't been committed as of this writing. So while the hardware support is limited, the list is growing. LinuxBIOS currently is not tied to any specific chipset, vendor or processor architecture.

The quality of the hardware support varies. On the chipset front, support for SiS chipsets is very good. Both Intel and AMD have a standard policy of documenting their chipsets so the support at both is pretty good. Via does not publicly document their newer chipsets, making support here a challenge.

On the processor front, Compaq has made the important details public, so supporting Alpha processors is doable. Development for the Alpha has not been a high priority, however, because the Alpha is an expensive processor with a dubious future.

The Pentium II and Pentium III are fairly well documented in Intel manuals, except for the L2 cache initialization of their slot processors (the L2 cache initialization is now supported). The AMD Athlon and Duron are not well supported because AMD hasn't publicly documented everything that needs to be set up for their processors.

Support from the board manufacturer isn't necessary because, most of the time, components on a motherboard can be identified by just looking at it.

Board manufacturers generally are interested in supporting only one firmware for their motherboards. As LinuxBIOS currently does not provide a compatibility layer for booting other operating systems besides Linux (notably Windows), there hasn't been much interest from board manufacturers in deploying LinuxBIOS in its current form.

Conclusion

LinuxBIOS provides an innovative look at the job of firmware, how it is structured, written and licensed. As machines become increasingly integrated, LinuxBIOS is rising to meet the demand for greater code reuse and flexibility. If the snowballing interest in the technology is any indication, it looks to have a bright future.

Resources

email: ebiederman@lnxi.com

Eric Biederman (ebiederman@linuxnetworx.com) is a software engineer for Linux NetworX, focusing on LinuxBIOS and helping with cluster management tool development. When not deeply involved in LinuxBIOS, Eric reads science fiction, plays with DOSEMU and hikes around the Wasatch Mountains just outside of Salt Lake City.

______________________

Comments

Comment viewing options

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

neat.

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.

http://www.colorforth.com/cf.html

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.

walter

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:

http://www.acl.lanl.gov/linuxbios/contact/index.html

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.....

Tim

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState