In-Depth Look At LinuxBIOS 284
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."
Re:A bootloader? (Score:5, Informative)
Re:Motherboard support (Score:3, Informative)
Re:A bootloader? (Score:5, Informative)
Re:Already tried...? (Score:3, Informative)
Windows is not going to run on LinuxBIOS and Linux isn't going to run on Phoenix/MS BIOS.
While it's all well and good for the majority of us it's not good for the consumer.
Re:A bootloader? (Score:4, Informative)
Re:Clustering (Score:5, Informative)
Re:Does it allow console access via serial port? (Score:3, Informative)
Re:Already tried...? (Score:5, Informative)
http://www.linuxbios.org/news/index.h
Re:How do I try it? (Score:3, Informative)
No athlon64 mobos are on the list, sorry.
Re:It really is amazing... (Score:2, Informative)
Handy tips... (Score:5, Informative)
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
Re:For the end consumer... (Score:4, Informative)
Here's a list [linuxbios.org].
This isn't really aimed at Joe Linux, but that may change when DRM starts getting imbedded in the major BIOSes.
linux bios faq (Score:2, Informative)
Re:A bootloader? (Score:5, Informative)
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.
Re:Boot Time... (Score:3, Informative)
At least, that's how I'd measure it.
Re:What is the bios for? (Score:3, Informative)
The trick is finding a bootloader that doesn't depend on legacy BIOS services [te.to].
Re:For the end consumer... (Score:3, Informative)
Re:OpenFirmware (Score:1, Informative)
By the way, it is an IEEE standard: standard #1275. For more info, you might want to check out The OpenFirmware web site [openfirmware.org].
Re:LinuxBIOS to boot other OSs (Score:3, Informative)
Re:OpenFirmware (Score:5, Informative)
Re:Using x86 PCI adapters in the Macintosh? (Score:5, Informative)
A lot of PCI cards that do not have any firmware, work just fine on a ppc/linux setup to begin with, even when the cards do not have any support in MacOS or OSX.
I have a realtek ethernet card and a generic AMD usb card in my oldworld 603e machine already.
In addition, a lot of cards that do have firmware will work as long as you do not care about the device being available from boot. I have an older matrox card and an adaptac 2940UW in my machine.
Both work just fine as long as I don't need them until the linux kernel takes over. With proper kernel parameters, the matrox card is even my console, I just don't see anything until the kernel is booting. Ditto, I boot and load kernel from a 250MB narrow-scsi drive on the machines onboard scsi. My root partition is on an UW drive on the adaptec card.
Took a little bit of doing, but this 'grossly obsolete' machine is running just great after adding some 'somewhat obsolete' parts. With 256MB, a fast drive, and a card with decent X performance (the 10-year-old matrox)... It performs a heck of a lot better than it's 180Mhz would make you guess.
Re:Clustering (Score:5, Informative)
It initializes the necessary hardware and then loads any "payload." The payload can be anything--A kernel image if you have enough space on your flash part, a bootloader [te.to] to boot from over a network or local disk, etc.
Currently the Lightning cluster (Ranked at #6 @ top500.org) uses LinuxBIOS to load a bootloader (Etherboot or FILO, I forget which) which then loads a kernel and BProc [sourceforge.net]. No spinning hard disk, no CD-ROM, just an added solid state flash device on the IDE bus containing a bproc-patched kernel with a driver for the interconnect and bpslave. The rest of the operating system for slave nodes, which is only a few kilobytes, is pulled down over the network (Not necessarily ethernet) and loaded into RAM.
>> How are kernel updates done if it is the latter.
Since all the hardware is same for a cluster like Lightning, a kernel update can be done pretty easily with the bpcp (BProc copy) command if you have a new kernel sitting on the master node. I haven't used it in a while, but I think the command goes something like: bpcp vmlinuz 0-N:/boot/vmlinuz, where N is the last node. The syntax is very similar to RSH/SSH, but you can specify as many nodes as you want so you don't need any shell scripts to count up for you. I guess you might also need to tell bpsh to mount a boot partition, depending on how you have it set up.
If you have your kernel in the BIOS, then you have to rebuild and reflash. With the magic of BProc, you don't even need to put the BIOS flashing utility (See their flash_and_burn utility) on the slave node. Just run bpsh 0-N flash_rom newbios.rom. LinuxBIOS even provides fallback functionality so if something goes horribly wrong during this process or the new image doesn't work it can automatically load an old image that does work.
These are just a few of many possible configurations, of course. There are no strict guidelines as to how a LinuxBIOS system must be used. It's extremely flexable, which is one of its main appeals.
Re:Heres a picture (Score:2, Informative)
A real picture of LinuxBIOS:
0100110001101001011011100111010101111
Re:plug n play smp's (Score:2, Informative)
Unisys, for example, have been using Intel processors in their machines for a long long time. They realised that the CPU was not their selling point, it was their archetectural experience. So they stopped making their own CPUs and started using Intel ones instead.
u-boot is superior and much farther ahead (Score:3, Informative)
More information at the u-boot [sourceforge.net] homepage. The u-boot README [sourceforge.net] file lists all the architectures, supported platformas and options.
Credit goes to Wolfgang Denk, the father of the project.
Best wishes,
A firmware engineer
Re:oh yeah? (Score:3, Informative)
Re:fetch from 0xfffffff0? (Score:3, Informative)
The processor can address 4GB using 32 address lines, and that defines an address space of 4GB.
Newer processors address 64GB using 4 extra address lines but they are yet another add-on that has to be enabled lateron by special software support.
Re:This is a wonderful idea... yeah right. (Score:4, Informative)
You can do that today. Get a CompactFlash to IDE adapter and a CompactFlash device of the size of your choice. You probably think that's slower than putting it in the same Flash as the BIOS. Well, it's not. The BIOS Flash sits on most motherboards on the ISA bus, which is notoriously slow.
Remember, the BIOS is nothing more than a Flash device. And because it sits on a relatively slow interface, it really is not a great place to store large amounts of data.
BIOS itself should be a relatively powerful microprocessor.
You misunderstand what the BIOS is. The BIOS is just a chunk of code, nothing more. It's not a microprocessor. The microprocessor is whatever Intel, AMD, Via etc. chip you have on the board. That's what executes the BIOS.
and since the BIOS is designed for the computer (by the factory) or configured (by a hacker who puts together his own system), there is nothing to detect or load
Again, this is something you can do today. You have to configure the Linux kernel to do that. Before modules people would do this a lot more often, but one of the downsides of Linux going 'big' is that most people don't know/understand how to strip their kernel from stuff they don't need, while on the other hand, features such as Plug and Play detection etc have increased the boot time dramatically.
then you "freeze" it a la VMWare, put it in the BIOS Flash,
Remember that Flash write speed is very slow compared to a harddrive, no matter what bus it sits on. Even CompactFlash is much slower than even a slow harddrive. Imagine storing a snapshot on a fully loaded system with 1GB or RAM. That's a lot of stuff to write to anything.
Anyways, I know where you are coming from, but with all due respect, you don't really have the background to come up with a realistic system design.
Believe me, BIOS & OS coders _do_ come up with ideas like this all the time and I think that alternatives to the old (obsolete) BIOS will come up more and more. (hint: I am a BIOS coder that might be working on a skunkworks project
In the meantime, if you want a fast boot, do the following:
- use LinuxBIOS
- put your kernel on CompactFlash. CompactFlash is available almost immediately vs. the 3-5 sec spin-up time of a normal HDD.
- configure your kernel properly and link all drivers you need statically instead of using modules (as much as you can).
- As soon as the HDD is ready, you can mount your main filesystem on that.
Not _THE_ kernel, _A_ kernel (Score:3, Informative)
If things move to LinuxBIOS you won't be flashing every time a new kernel is released, you'll be installing kernels normally, and instead of GRUB the LinuxBIOS will handle 'bootloading'.
moving THE kernel into flash isn't practical, my kernels are typically about 2MBytes, today's flash on most PCs is about 2Mbits (512KB). The typical full-kernel would have NO CHANCE of fitting into there.
What this does, essentially, is give us something much like OpenFirmware for x86 machines, it's a full 32-bit protected system from the second you hit the power button, and it can initialize and configure much more 'native' info to the full kernel that it loads subsequently. Pairing this with a 16MB DiskOnChip would be excellent though, if you'r system fails you could boot to the DOC (with a small system onboard) and repair the main drives, or change configs, or chroot into the 'real' system and get something done.
Intel and Extensible Firmware Interface (Score:2, Informative)
From their page:
"The EFI specification defines a new model for the interface between operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together, these provide a standard environment for booting an operating system and running pre-boot applications.
The EFI specification is primarily intended for the next generation of IA-32 and Itanium(R) Architecture-based computers, and is an outgrowth of the "Intel Boot Initiative" (IBI) program that began in 1998."
/me is betting that MS is involved in this initiative too.