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.

Comments

Flash drives

[drivinghighway61]

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]

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:Flash drives

[Waffle Iron]

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

[Cyberax]

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:Flash drives

[alan_dershowitz]

If you plugged in a cartridge it was instant-on for those apps too. Now there's even a peripheral, the MMC64 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

[SenorCitizen]

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:Flash drives

[rucs_hack]

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

[TheRaven64]

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.

What about Abstraction?

[CodeBuster]

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.

Re:What about Abstraction?

[krog]

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:What about Abstraction?

[BlowHole666]

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.

Re:What about Abstraction?

[CyberLord Seven]

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?

[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, your BIOS is doing a bunch of slow hardware autodetection, and then passing the baton to your kernel, which ignores that and does its own faster and more reliable hardware detection.

In that sense, if you really want the BIOS abstraction layer, the first step would be to write a reliable one. Putting Linux in there is the logical first step. If you want to hack LinuxBIOS to do the full hardware autodetection, and then hack Linux to trust hardware info from LinuxBIOS, you're welcome to do so (though the benefits are unclear).

We broke this abstraction in Linux for reliability, not performance. If somebody wants to remove some useless old cruft to increase performance for free, I have no problem with that.

Re:What about Abstraction?

[billcopc]

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]

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:Deck chairs on the Titanic

[KC1P]

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]

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

Why not EFI?

[Anonymous Coward]

Why not use EFI?

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

Re:Why not EFI?

[segedunum]

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.

In theory, yes.

[khasim]

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.

I wouldn't touch this!

[schnikies79]

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.

Disk-on-Chip Linux

[RancidPickle]

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.

Benefits from experience

[vil3nr0b]

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]

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]

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.

why the PC is so slow to boot

[Skapare]

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.

Re:why the PC is so slow to boot

[Todd Knarr]

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.

Speed booting???

[gstoddart]

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

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