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.
It seems like the bulk of my boot time is not spent waiting for the BIOS but the operating system. In the case of Windows, its waiting for all of the (mostly unnecessary) background processes to launch. Removing legacy support in the BIOS may help a little, but I seriously doubt that it will significantly decrease boot time overall.
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
31 Aug 2006 :(
Not only rehashed from digg and reddit, this article is from Aug 2006.
Generally? What if performance is your goal?
In the course of every project, it will become necessary to shoot the scientists and begin production.
I'm sceptical. One would hope, but I would absolutely swear that the time to go from "power on" to a "boot:" prompt has stayed EXACTLY the same over the past 25 years.
You would think that modern CPUs would get through the BIOS quicker than they did for the 8086, the 286, the 386, etc. For each new, faster CPU, I've been amazed that they all still take so long, and take about the same amount of time. The latest CPUs are possibly even slower (that's certainly the case with the Itanium).
Go figure.
From TFA:
Of course, the exact meanings of these codes vary from one BIOS to another, and only some vendors document them. Luckily, the open source vendors are very good about documenting them.
Wow!! - Who are these open source people who are "very good about documenting" beep codes?? Any chance of deploying them to all the other open source projects out there?? - they could sure do with the help!
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/
All those procedures performed in BIOS today are often unnecessary unless you run a legacy operating system like DOS that actually uses the BIOS. Linux as an example only uses BIOS for a limited amount of tasks while it does most of the hardware management in the kernel without much need for BIOS to be around. So replacing or at least speeding up the BIOS would be very nice.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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
EFI does a whole lot more than what I want it to do. A whole lot more than it should do as well. Kind of the same reason I don't want anything to do with things that have a TPM.
Now if only we could have larger bios chips, then having a linux kernel on one makes sense.
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.
I'll probably never use this. My computer(linux) has a very good uptime to down rate, so it is very rare that i'll reboot my machine this year. Even if their is a power failure, my UPS will kick in.
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'm completely behind you - this would be really nice, but it doesn't seem to be the way technology has been panning out. Every new device I get takes longer than the last one: Cable boxes, dvd player, music players, even cellphones. It seems every time I upgrade there is more crap I don't use and it means I need to wait longer from the time I press "on" until the time I can actually use it.
I hope these folks are successful and can lend some advice to device manufacturers as well!
Get a web developer
Heh. I wish that were true. Cisco IOS depends SIGNIFICANTLY on what ROMMON reports, and that's a modern OS (with BSD roots). I would say Modern well designed OS's don't depend on what the BIOS tells them. If you ever looked at the design of ROMMON, you'd break out laughing. It's a classic example of an over-engineered design made by substandard talent. Honestly, if you ask any semi-intelligent technical question on Cisco's internal rommon mailling list, you will usually be greeted with by silence. Simply because the current engineers simply don't know.
I suspect it's because of Cisco's massive importing of H1-Bs, as that seems to make up most of the crowd dealing with ROMMON, but I digress.
Also note well that all OLD UNIX's didn't depend whatsoever on the "ROM BIOS". Hell, originally you had to either flip the right switches, or type in the bootstrap code yourself to boot a UNIX kernel (on the DEC PDP-era machines).
The key point here is that the ORIGINAL model for the kernel was not to use the ROM BIOS at all. And this applies to the first UNIX on the 286 and the 386 PC's.
If you look at the Linux kernel code, you'll see that it's only been lately (within the past 5 years or so), that some people have been adding code for various architectures to depend on specifics from the ROM BIOS (and I don't just mean APCI).
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
The Slashdot effect has kicked in here
Well, then the answer is "no". 3 seconds isn't "instant on", and my scepticism is warrented.
No offense, but 3 seconds is what I'd expect a 3 GHz CPU to do to 386 boot code.
If you want to "replace" the BIOS, write UEFI firmware, preferably 64-bit, based on the UEFI 2.1 specification. Anything else is already legacy.
Apple's computers are half way there, with 32-bit EFI 1.1, though I'd like to see a shell in firmware and a slightly better implementation of the legacy BIOS CSM.
Also, Apple released launchd under the Apache licence specifically to make it easier for other systems to adopt.
Instant would obviously be useful, but the thing that always amazes me is that it takes soooo long to shut a modern computer down! Surely shutdown is a piece of cake? So why does it take (I dunno, about..) 20 seconds or so?
Hold on there, cowboy. The Original Amiga 1000 had Kickstart floppies.
Appropriately geeked by the prospect of LinuxBIOS and OpenBIOS, I recently picked up the first AM2 desktop mobo supported by LinuxBIOS, the Gigabyte M57SLI-S4. Now the MSI K9N-Neo has been added, and I hope to see more recent sockets & chipsets on the supported mobos.
http://linuxbios.org/index.php/Supported_Motherboards
I thought I'd done my homework, too, but wasn't as thorough as required. Replacing proprietary BIOS with LinuxBIOS is more than simply flashing the BIOS.
The Gigabyte M57SLI-S4 has one of two types of BIOS chips, determined by the revision. I was unable to get the revision type from my vendor before purchase, and wound up with the more difficult (and more recent) version. While this motherboard has the space for an additional BIOS chip, both revisions require hardware modification of the sort that includes soldering either a socket (if you're lucky and got the 'easy' revision) or a chip onto your motherboard (among other things.)
I'm very excited at the future possibilities for LinuxBIOS and OpenBIOS. But in reality, at this point and on this mobo, LinuxBIOS on the desktop requires precision soldering. While I'm not adverse to developing this skill, getting a LinuxBIOS desktop will take more time (and hardware) than I initially realized.
My how times have changed. If you want instant on, stop rebooting your machine and learn how to use /sbin/service.
responses with 100 inane examples of why you absolutely must reboot your machine to prove the exception to the rule to follow in 3..2..1...
I dunno - sometimes it's relaxing to watch a linux kernel boot. Kind of like watching fish in an aquarium.
Just disrupt the deflector shield with a tachyon burst.
OpenBEOS !!!???? .....oh..., it's BIOS.....
Oh my goodness, is it 64 bit? I can hardly wait!!!
Awe, shucks!
What about those first however many seconds that the kernel takes to boot, then the initramfs loads even more...
I mean, yes, Upstart is cool, but right now, fairly irrelevant -- hibernate is stupidly fast when you have any kind of RAID. But the BIOS and the initial Linux boot (during which a fresh kernel loads all the hardware support it will need to... load the hibernate-image-kernel) do still take entirely too long.
Then again, it might help to simply have hibernate images supported directly by bootloaders.
Don't thank God, thank a doctor!
Anyone else find it funny that IBM is supporting this project? Given the history of Compaq reverse-engineering *their* BIOS to jumpstart the PC industry?
I believe both GNOME and KDE have something rudimentary set up here, so that if an app supports this, and you log out (telling it to "save your session", which may be the default), it will save your session. At which point, there is no point to putting it on flash -- disk is more than fast enough. It's also a bit more flexible this way -- log out and switch users becomes much faster.
Here's the problem:
1) The on is no longer instant. Sure, it's quick to shut down, but now the app must be "rebooted", which means reading the entire thing off disk. The reason you think Flash is fast for this is because it doesn't have seek problems -- but normal PC hibernate doesn't, either.
2) Every app has to support it, or there's no point. Unless you want to be checking a particular app for "hibernate support", what usually ends up happening here is either the app gets killed completely on hibernate, or it gets started again properly, but without its state stored.
Now, suspend to RAM is fast enough. Suspend to disk is actually almost as fast for me, were it not for the other hassles of boot. I'm going to test this right now:
Very rough estimate:
Boot -> OS is some 25 seconds. This includes at least a few pauses in both BIOS and OS designed to give me the opportunity to press some keystroke to enter some setup -- I believe that's BIOS, RAID, and the Grub bootloader. Lilo and Macs have the right idea -- why not just let me hold a particular key combo while the box is booting? Even Windows was better about this, sometimes -- when resuming from hibernate, I can press F8 if I want to cancel the resume and do something else.
Maybe it's not intuitive that you can hold Apple+C (or is it Apple+D?) to boot from CD, but it's also something that has to be done maybe one in a thousand boots, and I'd rather have the other 999 boots be as fast as possible.
Then, it's still some 5-10 seconds while Linux churns and loads drivers, etc, before it actually gets to resuming.
The actual act of resuming is about 10 seconds flat, after which my desktop is pretty close to ready to use. Maybe 20 seconds, tops, counting disk thrashing, but that may also be my updatedb cron job.
But even 20 seconds, I could live with. What I hate is that there's another 30 seconds or so that's completely wasted, so it ends up being a minute to resume from Hibernate, when it could've been maybe 20 seconds. (It takes even longer to actually boot.)
Magnetic hard disks are certainly not the limitation here.
Don't thank God, thank a doctor!
It's a Psion Series 5mx.
I actually remember reading about "Windows-on-a-flash-disk" when the miniature computers started to pick up. I remember thinking how awexome that would be to have, especially if your system went FUBAR - just tell it to zero out driver settings on next boot. No tedious reinstallation procedure, save for a few drivers.
Why do so many geeks want you to keep your PC running all the time? When i'm done computing, i just shut it down, together with monitors and x powersupplies sucking energy. I do it with lights and washing machines too. It will save you enough electricity to buy a few gigs of memory at the end of the year. Now that's a speed improvement!
Trust me, I work for the government.
MMMMmmmp ...meep!
BBC Computer 32K
BASIC
>
The 2 second pause at power-on was almost all the RAM test, which, if you eliminated, the C64 became an instant-on machine.
;) ). I had a copy of Epyx's Jumpman Junor that fully loaded into RAM and ran in literally seconds. (I wish more games back then were as efficient.)
The slow load times of the C64 was mostly due to a poor implementation of the serial driver in the C64 kernel itself. The drive had an 8-bit bus but the kernel transfered 1 bit at a time. With a properly written loader or something like the Epyx FastLoad cartridge, load times immediately jumped by 8 times! In addition the 1541 disk drive had its own processor, RAM, and ability to be programmed. A really well written loader could make loading blazingly fast (or implement copy protection
Back then, the common slow downs were avoidable, but it took clever programmers. Every new computer I buy lately seems to be slower than the last to get into a usable condition-- it's a shame because it's obviously avoidable. I hope we get back to that with more than just proprietary embedded systems some day.
BTW, some trivia, the Commodore BASIC ROMs originally came (modified or no) from Microsoft (pay once, no royalties) back when the company was starting out. Some have the copyrights shown, some don't (C64 didn't). Fun read: http://en.wikipedia.org/wiki/Commodore_BASIC
--Dave Romig, Jr.
... to check for hardware failure - or failure of a device to init properly. be it due to damage, power surge, etc.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
We've hit a core question here. If fails, restart and probe properly, if not, leave well alone (IMHO).
I give away my age here, but when the Apple ][ got its first disk drives the floppies as well as the mechanisms were dead unreliable, not helped by us punching a hole in the floppy and using the unverified side which made it worse. However, in half a year or so, clone drives came out (yes, I kid you not, CLONES. Apple clones!) which were a lot better apart from where we could resist the temptation to use the wrong sides of floppies. A good friend of me then produced a much faster disk OS by simply reducing the waitstates and repeat readings - whihc was OK due to improved hardware. The same happened with TCP/IP - originally that happened over unreliable modems.
I can't recall the time when a piece of hardware failed on me other than when I tipped over an external USB drive (duh) so it's at leats in my case an exception rather than rule. So my position is that we should get a little bit realistic about just how good the kit is we use these days. Even laptops are much better - and by leaving a fallback algorithm in place (it failed so do it again the slow way) it ought to be possible to get rid of 50% of the bootup time. Zap Windows and kill services you don't need (and again those probes) and you'll get probably rid of another 30% or so. That was also the main advatnateg of a static kernel - it knew what was around. Sure, the modular approach is much better and flexible, but why not build the kernel module structure on first boot (maybe with a BIOS checksum as trigger?) and then make that a sort of 'hibernated' kernel from which you restart?
All desktop, of course. A server needs to probe properly (IMHO).
Insert