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.
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.
I can remember the Amiga taking 1.5 seconds to boot into a full multitasking GUI, and rendering a fractal while it boots. One day they'll get it again, thanks to the success of OSS.
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!
I have an instant-on computer. It's a Commodore C64.
Sure, the C=64 was instant-on, but you had like 30 second seek times for the floppy disk, which is where anything exiting to run lived. If all you wanted to do was simple command line instructions to "load $program * , 8" you could call it "instant on" but you got almost nothing for it, and to get to any user app functionality up and running, it still took a long time, vastly longer than it does now.
You see? You see? Your stupid minds! Stupid! Stupid!
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!
The Atari ST, on the other hand, had the whole OS in ROM, except for the very first models. Even STs weren't instant-on though, because the bootloader would waste at least half a minute looking for a disk to boot from - it was actually faster to have a GEM disk with custom settings in the drive when turning the power on than booting from ROM only.
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
That depends on the hardware. If you have to deal with legacy ISA devices, yes. Anything in the last 5 years or so doesn't have an ISA bus. The PCI bus has a defined way for devices to identify themselves and what I/O addresses and interrupts they need. USB similarly has a defined way to determine what's on the bus. Since the BIOS itself controls things like on-motherboard serial ports, it already knows which ones it's turning on and where they go. So basic initialization should be relatively quick and easy.
Frankly the only things the BIOS should need to do with modern OSes is to reset the hardware and provide the basic I/O interface to the disks, screen and keyboard that any boot loader's going to need (so the boot loader doesn't need drivers for video, USB vs. keyboard-port keyboards, etc.).
Alternatively, the BIOS should initialize all hardware, assign all interrupts etc., and the OS should simply take what the BIOS gave it. But IMO having the BIOS do only the minimum required and leaving the bulk of the work up to the OS gives more flexibility and resilience in the face of hardware changes or failures.
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!"
The thing is if you want capabilities on your embedded systems to come close to your notebook's capabilities, they will take 1 minute to boot instead of 5 sec.
My CD player used to boot instantly... but just try to boot an HD-DVD or BluRay player....
I believe part of the time is spent probing the various busses to construct the correct ACPI tables (or OpenFirmware device tree). This is not required in an embedded system, where the hardware configuration is expected not to change.
I am TheRaven on Soylent News