Why Intel Wants BIOS Dead

An anonymous reader writes "This brief, readable whitepaper by Brian Richardson, a product manager at BIOS-vendor AMI, examines the history of BIOS firmware and explains why chipmaker Intel has invested much time and effort to create and promote a firmware framework to replace BIOS. Why would a chip company care about firmware? Read Richardson's paper about the 'Evolution of BIOS: EFI, the Framework, and beyond' to find out."

Comments

OpenFirmware

[noselasd]

Why can't all the PC architecture vendors just get along and use OpenFirmware like most other sane architectures ?

Re:For the lazy...

[FooAtWFU]

they just want the current firmware standard to evolve to better meet the needs of today's technology.

For values of "today's technology" equal to "Microsoft's latest DRM systems."

It's DOS, not BIOS

[LordNimon]

I haven't read the article, but the reason for 8086 compatibility is for DOS, not BIOS. There's nothing preventing a vendor from producing a PC with a BIOS that doesn't support DOS. That will eliminate the 16-bit interfaces, all the real-mode crap, and tons of PCI code.

Vendors like Dell see the BIOS as a necessary evil. They pay BIOS developers big bucks to keep updating the BIOS for new motherboards. Occasionally, a new feature creeps in like USB keyboard or bootable CD support. To rip out all that legacy code (which no one has touched 15 years) would be a development and testing nightmare.

Of course, switching to Open Firmware would make more sense, but we'll never see that happen.

Re:It's DOS, not BIOS

[anti-NAT]

Who in their right minds is going to buy a new PC and put such an old OS on it?

Corporates who need to upgrade to a new server for performance, yet can't afford to spend huge amounts of money upgrading the applications to suit the newer OSes.

I'd be guessing you haven't worked in the large(ish) enterprise/corporate world. If you haven't, and haven't been exposed to custom applications, you probably aren't aware that hardware and the OSes to run the applications is a very, very minor cost when compared to the total costs of developing, deploying and supporting a custom application.

The great advantage of the existing PC architecture has been the fact that if your applications weren't performing fast enough, you could just throw newer hardware at it. An over-the-weekend upgrade could result in dramatic performance increases. Compare that to having to port an application to a new architecture, test it, fix bugs, and if it the opportunity was taken to improve it at the time by changing the way it worked, running training courses for users and support staff, all of which may take six to twelve months or more.

Continuing backward compatibility is probably the primary reason for the success of the PC architecture over the last twenty years.

Re:It's DOS, not BIOS

[Thing 1]

Who in their right minds is going to buy a new PC and put such an old OS on it?

We do it all the time at work. It's called Ghost. We don't have to install DOS, but we do have to be able to boot a DOS floppy. I guess there are Linux solutions available that'll boot from a CD or a floppy perhaps, but we standardized on Ghost...

Ugh.

[bluephone]

Yes, I RTFA, and Jesus H. Christ on a stick, that's a worthless article. I'm sending the site an email, I want those 5 minutes of my life back. As any high school geek could have said, the article boils down to the BIOS is still limited to Real Mode 8086 emulation, and thus everything until an OS kicks in is limited to this as well, as hopefully 80% of /.ers know. Then, it goes on to say EFI solves this. Not how, no technical details, aside from you can boot from USB devices (as you can with some modern BIOSs) without emulating a disk device.

Worthless article. I could have gotten that from the Intel EFI press releases put out FOUR YEARS AGO.

... or the wicked?..

[Fallen Andy]

I'm puzzled. Yes you need to be able to emulate INT 10H but in real terms that's a *high* level interface. (may be a shock to virginal C++ programmers I guess). When I first started programming (and that was in the early 80's) most machines weren't anything like anyone elses machines. I was porting the UCSD p-system - a system based on an interpreted Pascal (Borland's Pascal up to 5.x is very similar). UCSD Pascal is best thought of as an early attempt at the Sun/Java "write once execute everywhere" philosophy. It didn't work out (sadly). But pre "PC's" no machine was even remotely similar to another machine. Developers couldn't target anything or earn enough. I always call this the "Pre-Cambrian explosion" because the machines and environments were so weird that only a drug fiend could have invented them. To cut a long story short - all the bios (sic) needs to do is load sector zero off the winchester (big grin for newbies) and let rip. Real programmers can cut their own debug code. (Now being a slower forty something I shudder when I think about it, but it was fun at the time). It would still be a good exercise to drop someone expecting an IDE into such an environment for evaluation. Never mind "bastard operator from hell", some of you gals/guys come up with "bastard sys programmer from hell".

Boot quicker?

[cbreaker]

Text mode is higher resolution then 320x240. But if your BIOS shows some graphic during POST, it won't be any better even with a completely new BIOS type unless all the graphics card makers also agree upon a standard interface for high color, high resolution graphics on boot.

Most modern BIOS's boot very quickly. With a "normal" workstation setup with a single IDE hard disk and a CD-ROM drive, it often takes under three seconds before it starts to read the OS from the hard disk.

A new BIOS firmware won't help much in either of those cases. And if you have SCSI controllers and all that jazz, it will take just as long as before to detect all the drives.

I'm not saying that improving the BIOS isn't something that doesn't need to be done, but none of the features you mentioned will be improved.