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.

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.

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?

Why not EFI?

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

[Nazlfrag]

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.

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.

Re:Flash drives

[Anonymous Coward]

I have an instant-on computer. It's a Commodore C64.

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?

[ultranova]

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 hardware directly. And I'm certain Linux doesn't use BIOS for hard disk access, since Linux can use the whole disk even if BIOS is limited to the first 120MB or so of it in some really old machines.

Re:Deck chairs on the Titanic

[Chirs]

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

[Junior J. Junior III]

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.

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.

Re:Why not EFI?

[DeathPenguin]

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 indirectly: (i) reverse engineer, decompile, disassemble or otherwise attempt to discover the underlying source code or underlying ideas or algorithms of the Software; (ii) modify, translate, or create derivative works based on the Software; (iii) rent, lease, distribute, sell, resell or assign, or otherwise transfer rights to the Software; or (iv) remove any proprietary notices in the Software." ( https://www.tianocore.org/nonav/servlets/LegalNotices?type=TermsOfService [tianocore.org] ).

So I guess your question is sort of like asking why people don't like to use proprietary drivers, even though there are some out there that work very well. The nice thing about Macs is that Apple seems to have went out of their way to make EFI invisible to the user. I don't trust that this will happen on most other pieces of hardware. The BIOS belongs out of the way, IMHO.

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.

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.

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

[cheros]

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

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.

Re:Did you ever notice?

[JesseL]

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.

Re:Flash drives

[droopycom]

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]

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.