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?
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
Funny that is what the OS is supposed to do also. But now they come with stuff built in. Maybe if the BIOS was left alone and the OS was fixed to do just what it was supposed to do and not worry about the rest of the crap.
It does not matter if I run Linux, or Windows they both start with crap running in the background. A normal user has no clue what is running. Why not when you install the OS you just ask "Do you want a Firewall? Do you want a Server? Do you want to update your system time over the internet? Do you want to back your computer up every night" It is like most systems just install bloat ware because they *think* normal users want this stuff. Or it provides security. Well write the OS correctly where you do not specifically need a firewall or anti virus, or updates every Tuesday.
Sorry got on a rant. I am just saying Let the Bios do its job...boot the system. Let the OS do its job, Schedule task, manage memory, and provide access to hardware.
I smoked pot once. But I DID NOT inhale. Will you hire me?
You're absolutely right. It seems like every OS (including Linux) goes through this -- in the early days it boots much faster than the competition, but once people start routinely layering all kinds of junk on it then it starts taking minutes to boot even on super-fast hardware.
... one at a time ... if the name server isn't answering. All those "wait X seconds for Y to happen" things can really add up.
What really bugs me is how much of the startup config is done serially. A lot of startup tasks take time, and step N+1 has to wait until step N is finished whether or not it depends on that step. It seems to me that it would be worth the trouble to mechanize startup so that each step is isolated from all the others and knows which previous step it's dependent on and waits for only that step, while everything else cruises ahead in parallel. It'd be a big change from the way things are done now but it'd be worth it. Having my system stop dead for 60 seconds on every boot just because one of the NICs is unplugged (so DHCP isn't answering) is really annoying. Same deal with Apache choking on virtual domains
Also, Linux isn't the entire universe, and some of us really do use those legacy BIOS features. Backwards compatibility is the *only* reason the PC architecture has survived, so deciding to toss that to the wind now is just stupid. The cost is minimal (it's not like the code is going to change once it's written) and if whipping up a few tables and setting a couple of INT vectors is honestly adding dozens of seconds to the boot time, well that's just programmer incompetence, it's not the architecture's fault. The rest of the older BIOS code doesn't do anything if you don't call it, so this just sounds like an excuse to be lazy.
Purely anectdotal, but I see a LOT of Linux boxen that are very old running not so old Linux kernels.
This means, over a period of time, you have a greater chance of creating a NEW Linux only legacy support issue with newer kernels running on old machines.
This should not stop progress, but it is something that should be recognized up front.
We have always been at war with Eurasia!
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
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
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
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.
I don't think any reasonably modern OS actually does what you suggest, other than possibly as a last resort fallback (though I'm not even sure anybody does that). Linux for example can run perfectly fine on a BIOS-less system with only extremely minor modifications in the boot/init code (I don't know if even that is needed anymore - it's been years since I did that last).