About LinuxBIOS
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.
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.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
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.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
- Bought photoshop CS5 for developing a website :(
1 hour 16 min ago - What the author describes
2 hours 42 min ago - Reply to comment | Linux Journal
6 hours 53 min ago - Reply to comment | Linux Journal
7 hours 38 min ago - Didn't read
7 hours 48 min ago - Reply to comment | Linux Journal
7 hours 53 min ago - Poul-Henning Kamp: welcome to
10 hours 3 min ago - This has already been done
10 hours 4 min ago - Reply to comment | Linux Journal
10 hours 50 min ago - Welcome to 1998
11 hours 38 min ago
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
neat.
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Great article! I enjoyed it very much.
Thank You LJ and supporters.....
Tim