Slashdot Mirror
Get Speed-Booting with an Open BIOS
An anonymous reader writes to mention that IBM Developer Works has a quick look at some of the different projects that are working on replacing proprietary BIOS systems with streamlined code that can load a Linux kernel much faster. Most of the existing BIOS systems tend to have a lot of legacy support built in for various things, and projects like LinuxBIOS and OpenBIOS are working to trim the fat.
Speeding up BIOS processes combined with flash boot drives will seriously decrease loading time. Are we closer to instant-on computers?
Isn't it more important for the BIOS to present an efficient abstraction of certain hardware resources that *any* OS can easily communicate with according to a standard interface than to optimize support, possibly at the expense of flexibility and abstraction, for a single OS (even if that OS is Linux)? The violation of abstraction merely for performance improvements is something that engineers should generally be very reluctant to do.
The majority of boot time is spent initializing drivers and bringing the system to a usable state. The 3 seconds it takes for the BIOS to init the disk, locate the MBR, load the bootloader, and jump to it is negligible compared to the tedious hardware scanning and initialization done by the OS itself when it is finally loaded by the bootloader.
If you want to speed up the boot sequence, take a look at cutting the number of attached devices down to the bare minimum. Don't start any services during init. Do as little as possible to get the system to its usable state and you'll have minimized the boot time. Unfortunately, technology just doesn't work that way. System requirements (of both a hardware and a software nature) will require that you perform extra initialization at boot time, so any possible gains are already offset by the increased load.
Getting off of x86 may be one way to optimize the boot process, but how many of us really have the wherewithal to make an architecture jump from x86?
It does what you want and has been in desktop computers (Macs) for over a year now.
But the problem is that the BIOS's cannot be trusted today.
... or just simplifying the BIOS to the point where it can boot the OS and allow the OS to probe everything.
So the more advanced operating systems probe the devices themselves to see what capabilities are available.
We've arrived at the point where we need to choose between updating the BIOS's on the motherboards every time a new capability is added (and all previous motherboards)
It's easier to update the OS than the BIOS.
As the subject states, I wouldn't touch this, unless it was an official release from my board manufacturer. With a bad install or software bug, I can just re-install, but a bad bios can hose the motherboard. I might try it if someone had it running on the exact same hardware, down to part #'s for the ram.
I'm admittedly not terribly bleeding-edge when it comes to hardware or electronics, but mucking with my bios is a no no.
Gone!
If they could come up with a dedicated Linux Bios combined with a Disk-on-Chip setup, it would make an impressive little computer. Fast-on, perhaps with a drive or removable flash drive, and all updatable. It certainly could make an inexpensive box, and could be an ideal homework machine for the kids or a combo stand-alone box / terminal for offices. If the network went down, people could still work.
"First things first, but not necessarily in that order."
- Doctor Who
I have repaired clusters for the last two years and most have OpenBios. These are the likes: 1)Fast as hell!! 2)Easy to change options 3)Can mount the file to a disk, edit, and then replace. 4)Errors can be determined by watching console, No video needed. One serial cable, One laptop=priceless. 5)Free
Why? Well, Trusted Platform Computing needs to start on the BIOS level in order to maintain a trusted environment. If motherboard manufacturers actually move to an always-on TPM, then OSS developers may be locked out of newer hardware.
The mobo manufacturers will love the price versus commercial tpm and thereby limiting tpm deployment.
That's why getting involved with these projects in particular is essential to everyone who understands the importance of computing Freedom and overall innovation.
Got Trader Joe's? friendwich.com RSS feeds work now!
No, I don't know that much about what's happened in the field in the year and a month or so since this article went up, a month or so after I wrote it. I've been busy.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I want my PC to hibernate to flash, storing an image that requires only the slightest update to reflect network state, time, and a few other counters. And all apps to store their state so they can be "rebooted" to flush memory leaks, but return to their highlevel state.
That would give instant-on that's great for mobiles, but also good for desktops. Why is that so hard? Isn't hibernating to flash with a little update a lot easier than rewriting the BIOS?
--
make install -not war
You honestly think your BIOS is slow? Ever watch a 4.77MHz IBM XT with 640KB RAM go thru its memory test and POST?
16 KB OK.....(5 sec).....32 KB OK.....(5 sec).....48 KB OK.....(5 sec).....64 KB OK.....(5 sec).....
I seem to remember it taking 1 minute to go thru the memory test.
Windows 3.1x calc: 3.11 - 3.10 = 0.00
You can be as skeptical as you like. LinuxBIOS has been doing 3s boots.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
One major reason a PC is so slow to boot is the totally free-wheeling nature of attached devices. There's actually too much liberty to do bad things in device hardware. In some cases, probes to see if a certain specific device is present can cause some other device to go into a locked up state. PCs also have the complication that interrupts don't really identify the device in the same terms as how you access the device. This means we have to do things like timed waits in device probes. Ideally we should be able to discover all the devices in a computer within a millisecond for as many as 100 devices.
We need a whole new system level (as opposed to CPU level) architecture. We need to have a uniform device address range for all devices, and a uniform set of basic commands for all devices. Then all devices in the same class (storage devices are one class, network interfaces is another class, etc) to have a common set of commands to operate the normally expected functions of that device class.
And we really don't need a BIOS, or at least not much of one. A simple switch that lets us select between 2 flash areas to load at reset or power on would handle almost all cases. And even that's not necessary if we choose to run a stripped down boot selector program from flash that lets us select other flash areas to load. That combined with a hardware based "JTAG over USB" protocol to store new flash images when no present ones work (maybe when an on-mainboard or rear-access switch enables it) would provide any needed recovery capability.
And why can't we have gigabytes of flash? I bought a 2GB SD card the other day for $20. Can't they put that on the mainboard? An SD slot would not only provide for a lot of capacity (way more than what you get on a CDROM), but also a means to stop writing, and a means to swap out bad flash or reload it in another computer.
I have been working on a description document for a new architecture. It's not ready, yet, or I would post it here. But I'll try to speed it up.
now we need to go OSS in diesel cars
Speed boot: (noun) What we water ski behind in Canada.
:-P
Thanks, I'm here all week. Try the veal.
Lost at C:>. Found at C.
My Home server boots from a Sandisk 4G CF drive. Speedwise, it is blazing. The mounts are a bit different. / is on the drive, while /home, /opt, and parts of /var (such as /var/logs) are on HDD. Roughly, any directory that varies is put on HDD. Next year, I will buy another CF only it will be 8G. By then, the price will be much lower, and the speeds increased.
I prefer the "u" in honour as it seems to be missing these days.
My main bone of contention with the bootup checks is that they test for somethign new where 99% of the time such 'new' doesn't exist. Once a box is stable, all that will go in and out is USB devices and the odd CD or DVD, so it would immensely speed things up if we could register the device status somewhere and thus get rid of all this useless probing.
:-).
We're running machines that are clocked in the GHz, yet bootup is still no faster than an ancient 80386 at 25MHz - despite Linux BIOS demonstrations that were so fast to come online they had to slow it down because the hard disks hadn't quite spun up yet.
When we get to the OS, the same observation applies. There too are wait states which only exist because of the default assumption of change. Why not give the user the option to lock that state so you don't have to probe for it other than (as said) USB, DVD and maybe a new DHCP lease? That was what suspend is trying to do as well, but that is made more complex by the need to come out of it and (again) check if something has changed other than time..
About the only time you'd need to trigger a full check is unplanned shutdown because such a drop may have caused damage. Just my 2 cents, of course. I haven't designed hardware or coded in a good 2 decades now so I may be a little bit rusty
Insert
And then the OS (as long as it's less than 10-15 years old) does it all over again. A Modern BIOS should do as little as possible before handing operations over to the operating system.
"Prefiero morir de pie que vivir siempre arrodillado!"
Also, Apple released launchd under the Apache licence specifically to make it easier for other systems to adopt.