Slashdot Mirror
In-Depth Look At LinuxBIOS
DrSkwid writes "With PhoenixBIOS reading your email because of such inordinate boot up times for Windows and other OSs, it was remarked in #plan9 about our 5s boot times using LinuxBIOS. My friend f2f pasted an article from Linux Journal which looks at the basic structure of LinuxBIOS, the origins of LinuxBIOS and how it evolved to its current state. It also covers the platforms supported and the lessons they have learned about trying to marry a GPL project to some of the lowest-level, most heavily guarded secrets that vendors possess."
Well, for starters if my understanding of eXecute In Place is holding, it's completely different. The ROM chip holds a compressed kernel, that's decompressed on the fly and used to start the system. The only thing this skips is the need to do a startup seek for harddrives, and that whole step of initalizing slow hardware (ie, Hard Disk platters). eXecute In Place is intented to simply run the program natively, ie uncompressed kernel image sitting in ram, so it can just be thrown straight into the processor and executed. The difference is slight, but none-the-less important.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
I was recently doing some research to get started working with LinuxBIOS. The first thing I have done is to order a BIOS Savior.. This is a little gadget that runs about 15 bucks. It puts a switch on the outside of your case allowing you to switch to an alternate BIOS. With it, you can happily screw up your LinuxBIOS image all you want and still be able to boot your computer from the original BIOS.
Some motherboards have a dual BIOS or similar arrangement; however, there is not always a foolproof way to switch to your backup if the primary BIOS is hosed..
Keep these things in mind if you want to start playing with LinuxBIOS
How it typically works is you develop a kernel with a small foot print. The LinuxBIOS guys are really sane about things, there is a few lines of assembly which is just about enough code to start running C code. After that the gist of it is C with some assembly macros. There isn't anything too complex, we're talking about outp mostly. There isn't anything too secret here, it's just that booting a PC is not documented really well. Some BIOS vendors have software that does runtime function with system managment interrupts. DRM will be something like that. Supposedly and there have been discussions about it on the LinuxBIOS list, Phoenix and company do some hardware error checking and such and that's why they are so slow but some of the LinuxBIOS folks think that they don't do that and that the code is so complex and has so much legacy that it does a bunch of extra crap that it doesn't need to.
That code does enough to turn on memory, it may do some checking now, when I looked at it last there wasn't a ton of integrity checking code. Light up a few other components, like VGA. Then copy a kernel from flash in to memory (think of it as a slightly tweaked bzImage) At that point you can pretty much jump to the start of the kernel and execute it. The kernel doesn't use BIOS for most device IO so it knows how to spin up drives and light up the rest of the hardware.
Now how we did it and understood the goal of LinuxBIOS to be was we had an initrd that the kernel from flash would load and execute. Said initrd would look at the drives, look at some other variables, authenticate the system, possibly do a fsck on the disks if needed and then locate a kernel on the disk. After locating that kernel it would use kexec, now called fastboot, and replace the kernel in memory. The idea was that we could upgrade kernels on disks without changing flash.
It works very well and has been incredibly reliable. We can get in to kernel space in a few seconds. Subsequently, if it's a settop box type device, it could download a brain from cable or satellite. It could rebuild itself if needed. You could have diagnostic code in there for manufacturing, etc, whatever you want. Pretty much only limited by flash size and memory.
I know that they now and do other things like boot windows and such, at which point LinuxBIOS is potentially a serious threat to Phoenix and company, the BIOS is an expensive piece of the computer.
I've been toying around with some linuxbios type projects. Since disk space is so insanely cheap and disks are so big anymore, you could set aside a backup partition, easily do a really quick backup daily and then weekly do a backup of that to long term media from "BIOS land" regardless of the operating system. Or you could have something like snapshots of your system, maybe a clean install, a configured system, a backup, a different OS or something like that and then all from "BIOS Space" pick them at boot time and have it restore them. Something like that, I have always wanted backup support at the BIOS level.