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.

Flash drives

[drivinghighway61 (812488)]

Speeding up BIOS processes combined with flash boot drives will seriously decrease loading time. Are we closer to instant-on computers?

Re:Flash drives

[CastrTroy (595695)]

I seem to remember the Commodore 64 being instant on. Granted our current computers are much more complicated than a Commodore 64, but it would be nice to get back to that instant-on era. Everything else seems to have gotten faster, or remained the same speed, the only thing that seems to continually get slower is boot times.

Re:

[Junior J. Junior III (192702)]

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.

Re:Flash drives

[Waffle Iron (339739)]

Sure, the C64 booted in a jiffy. Then it took 5 minutes to load a 50 KB app from the floppy drive. (Which is kind of silly, since the floppy drive had a CPU inside with as much horsepower as the main system unit itself.)

Re:Flash drives

[alan_dershowitz (586542)]

If you plugged in a cartridge it was instant-on for those apps too. Now there's even a peripheral, the MMC64 [wikipedia.org] that lets you use SD cards on your Commodore 64, so I don't see anything that indicates we couldn't have instant on for writable media either nowadays, which was the point of the original post.

Incidentally, did the 1451 drive have as fast a CPU as the Commodore 64? I know the 1451-II's CPU was actually faster, and you could actually offload CPU processing to it across the serial interface, and some games even did this.

Re:Flash drives

[rucs_hack (784150)]

All you C64 people, grr.

My spectrum was awesome, and by dint of the fact that I couldn't afford a C64 (or even a Vic 20), I opted for the '48k ZX spectrum beats your computer any day' line of reasoning, and affected temporary blindness when anyone started showing off sprites.

Ah yes, the hours of tapping away on a rubber keyboard. Hungry Horace, oh how many evenings you ate.

I took it out of storage and showed my son last year. He looked at it in a puzzled fashion and asked where the dvd drive was.

Crying is not manly, so I just mumbled and put it away again..

Re:Flash drives

[Cyberax (705495)]

I work with embedded systems, and my MIPS-based 166MHz board boots Linux in about 5 seconds, kernel loading starts almost immediately after power on.

I always wanted to have the same capability for my notebook. Sigh...

Re:

[droopycom (470921)]

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....

Re:Flash drives

[TheRaven64 (641858)]

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.

Re:

[Saxerman (253676)]

The original Amiga 1000 had the Kickstart ROM chips, which allowed them to boot nigh-instantly. This included the important parts of the OS, and later even drivers and the kitchen sink. You would literally have a splash screen for a second, and then having a functioning computer complete with GUI. Of course, this means surgery was required to swap in a new Kickstart ROM. And as later software required different versions of Kickstart to run, we started playing with different software kickers which allowe

Re:Flash drives

[SenorCitizen (750632)]

No, that's not quite right. The original Amiga 1000 didn't come with Kickstart ROMs, because the OS was still in a state of change. Instead, you had to load Kickstart from disk, and it ate up 256k of the 512k of RAM installed. Later Amigas came with ROM Kickstarts and could be started without a disk. The full Workbench environment still had to be loaded from disk, just like with the A1000 - on which you actually needed two disks to get the whole OS up and running.

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.

Re:

[GreggBz (777373)]

You definitely have it backwards. The A1000 had no Kickstart ROM, you had to load it from disk. This changed with every model afterwards. I will say that it took some time to load Workbench, with that drive churning away.

If you just wanted a shell and bypassed your startup sequence it was faster still. Even with the full blown GUI, it was still much quicker then it's PC counterparts.

Now, an Amiga with a flash drive, that's a sight to see. My A1200, which once had a 44 pin IDE-Flash adapter booted all

Re:

[rs79 (71822)]

Correct.

Its predecessor the Atari 800 was instant on. Pop in the basic cartridge, turn the power on and ther you were. In Basic land. At least the Amiga had C.

And cool graphics.

I was shocked to find there were people (Mike Meyer, how can I remember this stuff and still not remember where I put my glasses?) that didn't give a rats ass about the grpahics but just wanted to code C on a CPU with a linear address space ("segments are for worms").

Matt Dillon (Of FreeBSD and Dargonfly BSD fame) ported Bash to the

Re:

[the_humeister (922869)]

In Windows you can have the computer's current state be saved and loaded the next time the computer is booted. Is there an option to load the state of the machine on a fresh boot? That would save time on reboots.

Re:

[vux984 (928602)]

Is there an option to load the state of the machine on a fresh boot? That would save time on reboots.

I have 4GB of RAM (2x2GB) with Windows x64, and expect to have 8GB within the year. I've tried the hibernate or whatever its called. Its not really faster. The time time to save and load that 4GB file is non-trivial. In theory its nice when you've got a lot of open stuff on the go, but then I don't trust it enough not to save all my work properly anyway.

Overall, I don't think its that great, and I particular

Re:

[Bert64 (520050)]

Yeah, i come from the school of leaving your machine running 24/7, and I always liked the convenience of all my apps immediately available when i started work in the morning. I never had a laptop, and i always had a lot of programs running. If i ever had to reboot for whatever reason it was a HUGE annoyance having to reload everything. Not just the loading time, but the time spent laying my apps out just how i like them on all the virtual workspaces i had.

Re:

[DrSkwid (118965)]

You can be as skeptical as you like. LinuxBIOS has been doing 3s boots.

Re:

[JesseL (107722)]

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.

What about Abstraction?

[CodeBuster (516420)]

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.

In theory, yes.

[khasim (1285)]

But the problem is that the BIOS's cannot be trusted today.

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) ... or just simplifying the BIOS to the point where it can boot the OS and allow the OS to probe everything.

It's easier to update the OS than the BIOS.

Re:What about Abstraction?

[krog (25663)]

Modern OSes don't trust what the BIOS tells them, due to older BIOSes that can't be trusted. With this fact in mind, you can imagine how getting the BIOS mostly out of the way can gain a few seconds at boot time without losing anything practical.

Re:

[ultranova (717540)]

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)?

Why ? Does any OS actually use BIOS for anything except booting anymore ? AFAIR even most DOS programs bypassed BIOS screen routines (which is why redirection didn't work so well on DOS) and talked to the

Re:

[BlowHole666 (1152399)]

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 inter

Re:

[by Anonymous Coward]

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)?

These guys are simply taking advantage of the fact that the BIOS is an unusably bad abstraction. Linux doesn't make BIOS calls, nor does Windows (since before Windows 2000). If you're booting Linux and XP,

Re:What about Abstraction?

[CyberLord Seven (525173)]

Danger! Will Robinson! Linux boxen tend to be used far longer than Windoze boxen.

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.

Re:What about Abstraction?

[billcopc (196330)]

You, like many others before you, are confusing BIOS with what was once called "CMOS Setup".

The BIOS is essentially a set of low-level device drivers for the motherboard and basic peripherals (keyboard, display). Overclockers don't care about it, as long as it works.

The "CMOS Setup", or more appropriately System Setup, is an interface to configure the motherboard's features. The fancier ones offer many tweaking options, some even have a minimal Linux OS like the Asus P5K3 Deluxe (extremely handy for pre-boot stuff - or web/media browsing). Overclockers love big feature-rich control panel on their board as they allow them to tweak their system to further heights, and offer added functionality like built-in flashing (from a USB key or hard drive) and "smart" overclocking which is like the opposite of Intel Speedstep :)

Deck chairs on the Titanic

[BadAnalogyGuy (945258)]

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?

Re:

[Chirs (87576)]

I don't know what hardware you have, but it takes a LOT more than 3 seconds for my machine to do its POST, check the floppy drive, check the CDROM, check the SCSI cable, find my hard drives, check the partition tables, and finally start up my bootloader.

Probably more like 30 seconds.

Re:

[sconeu (64226)]

Because it's so easy to boot from a hard drive that hasn't spun up yet.

Re:Deck chairs on the Titanic

[KC1P (907742)]

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.

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 ... 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.

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.

Re:Deck chairs on the Titanic

[Karellen (104380)]

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.

We're working on it... [ubuntu.com]

Why not EFI?

[by Anonymous Coward]

Why not use EFI [wikipedia.org]?

It does what you want and has been in desktop computers (Macs) for over a year now.

Re:

[DeathPenguin (449875)]

EFI is a specification, not an implementation, where the core pieces are still controlled (And _never_ opened up) by vendors and is usually still a big wad of real mode assembly that nobody wants to touch. There is no 100% open-source EFI-compliant BIOS implementation. The specification alone for EFI is over 1,000 pages.

To top it all off, to even begin development on stuff like Tianocore you need to agree to draconian licensing terms such as: "You acknowledge and agree that You will not, directly or indirec

Re:Why not EFI?

[segedunum (883035)]

Because EFI is very much proprietary, and the subject of this article is Linux and Open BIOS.

EFI is also pretty broken. It tries to look better than BIOS, but really it isn't. Think of ACPI (Intel brain damage, as Linus Torvalds calls it) which looked good and looked like we'd get some standard interfaces.........and we didn't because hardware was too complex, it had quirks and everybody ended up doing variations on a different theme. EFI is the same, because of course, everybody's intellectual property has to be protected. I mean, we can't just have manufacturers downloading, installing and contributing to a standard Linux or OpenBIOS, because that would be too easy, it would make things work far too well and everyone would have wonderful boot times ;-). Maybe a motherboard manufacturer will bite the bullet and implement Linux or OpenBIOS when they realise how much better it will make their hardware, and how much cheaper it is without umpteen updates.

EFI is also an awful lot more complex than BIOS, which adds to the list of things to go wrong in terms of different implementations. At least the BIOS we have today is a boot loader - and it doesn't really pretend to be anything else (hell, you'd be crazy to try anything else with it!). Now think about how many BIOS updates we have for various boards today to fix lots of broken things, and then extrapolate that out........... It's not a pretty picture.

Re:

[TemporalBeing (803363)]

Why not use EFI?

Because it an UEFI - and its cousin that PheonixBIOS, which now seems to be defunct (can't find a reference to it) - are part of the Trusted Computing [wikipedia.org]/Paladium nightmare. if you want TPM to lock you out of your computer or tell you how to use your computer, than so be it.

I choose freedom.

I wouldn't touch this!

[schnikies79 (788746)]

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.

Re:

[DeathPenguin (449875)]

>>I might try it if someone had it running on the exact same hardware, down to part #'s for the ram.

Fortunately, you don't need exact matching hardware to recover from a botched BIOS update if you have a socketed BIOS chip. The flash memory your BIOS is stored on can be easily removed, placed in someone else's computer with a compatible socket (It can be a whole different architecture, even), and reprogrammed with the vendor's BIOS using Linux+Windows compatible utilities such as Flashrom ( http://lin [linuxbios.org]

Re:

[evilviper (135110)]

With a bad install or software bug, I can just re-install, but a bad bios can hose the motherboard.

No it can't.

First, it's been several years since I saw a motherboard with a socketed Flash chip, and even then, it was only the dirt cheap OEM boards from the likes of Dell/HP/etc, while the retail boards used a socket.

It's actually pretty easy to buy a replacement Flash chip, or salvage one from a dead system, and do a little hot-swap trick to Flash it with your current BIOS image for back-up/recovery purpose

Disk-on-Chip Linux

[RancidPickle (160946)]

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.

Re:

[AnotherBlackHat (265897)]

If they could come up with a dedicated Linux Bios combined with a Disk-on-Chip setup, it would make an impressive little computer.

Yeah, but who would do such a thing? http://www.phoronix.com/scan.php?page=article&item=870&num=1 [phoronix.com]

Not needed.

[WindBourne (631190)]

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.

Benefits from experience

[vil3nr0b (930195)]

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

Open BIOS is Mission Critical.

[asphaltjesus (978804)]

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.

To save time:

[seebs (15766)]

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.

Flash Hibernate

[Doc Ruby (173196)]

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?

why the PC is so slow to boot

[Skapare (16644)]

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.

Yeah - but why do this check every friggin' time?

[cheros (223479)]

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 wer

Re:why the PC is so slow to boot

[Todd Knarr (15451)]

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.

Re:

[evilviper (135110)]

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.

The cost of the hardware needed to support an SD card slot (fully, in hardware-only, before POST) would be more than the cost of a lot of ($40) low-end motherboards.

Directly wiring a Flash chip to the memory space is MUCH cheaper, and what's more, the most basic socket for the Flash/CMOS has all the same advantag

Speed booting???

[gstoddart (321705)]

Speed boot: (noun) What we water ski behind in Canada.

Thanks, I'm here all week. Try the veal. :-P