Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Intel Upgrades

Why Intel Wants BIOS Dead 65

Posted by timothy from the because-bios-stole-its-harley dept.
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."
This discussion has been archived. No new comments can be posted.

Why Intel Wants BIOS Dead More

Why Intel Wants BIOS Dead

Comments Filter:

  • For the lazy... (Score:5, Informative)

    by avalys ( 221114 ) * on Friday September 17, 2004 @07:17PM (#10281706)
    For those too lazy to read the article, it basically says Intel wants to drop the current-generation BIOS because it requires backward-compatibility. For instance, when designing the Itanium, they didn't want to have to make their fancy-schmancy 64-bit processor emulate a 16-bit 8mhz CPU simply for the sake of the BIOS.

    Note that, despite the hyperbolized title of the Slashdot summary, Intel doesn't want the BIOS dead. They don't have any problem with the concept of a BIOS, they just want the current firmware standard to evolve to better meet the needs of today's technology.

    • Re:For the lazy... (Score:5, Insightful)

      by FooAtWFU ( 699187 ) on Friday September 17, 2004 @07:25PM (#10281769) Homepage
      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."

      • Re:For the lazy... (Score:4, Informative)

        by IntlHarvester ( 11985 ) on Saturday September 18, 2004 @02:06AM (#10283576) Journal
        Don't let DRM cloud the issue -- the PC BIOS sucks phenomenally and should have been replaced decades ago. DRM is coming whether or not that happens.

        • Re: why has Intel killed Alpha 21264? (Score:1, Informative)

          by Anonymous Coward
          The x86 has a lot of garbage that the OS doesn't use it frequently. It was suboptimized using the older and worse technology since 1980.

          I should go to use Alpha systems, but it's dead, it was assassined by Intel Corp.

          Mea culpa.
        • But since the BIOS wasn't killed, a whole industry has evolved around that backwards compatibility. Intel finds themselves in a fix because they didn't kill it earlier, and now they have an obligation to maintain that tradition. Inertia is a tough force to fight, and Intel is learning that now.
    • 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" philo

  • OpenFirmware (Score:5, Insightful)

    by noselasd ( 594905 ) on Friday September 17, 2004 @07:25PM (#10281760)
    Why can't all the PC architecture vendors just get along and use OpenFirmware [openfirmware.org] like most other sane architectures ?
    • Because MS and Intel don't control OpenFirmware.

    • Re:OpenFirmware (Score:5, Informative)

      by AnwerB ( 255422 ) on Friday September 17, 2004 @08:01PM (#10281982)
      Why can't all the PC architecture vendors just get along and use OpenFirmware like most other sane architectures ?

      There is absolutely no market pressure whatsoever to do so.

      As long as there is either influence or money to be made on BIOS, and no pressure to move to an open standard, then none of big players will move in that direction.

      I realize that what I just said was obvious, but no one has said it yet (at the time of this writing).

    • Re:OpenFirmware (Score:1, Funny)

      by Anonymous Coward
      Go forth and programmeth the BIOS.

      That's all I had to say. I'm done now.

    • Re:OpenFirmware (Score:4, Informative)

      by IntlHarvester ( 11985 ) on Saturday September 18, 2004 @02:02AM (#10283559) Journal
      The technical reasons are (A) backward-compatibility for older OSes and (B) easier migration path for newer OSes. And of course some NIH factor.

      OpenFirmware apparently has some fans because Apple and Sun use it. But OF is just a means to an end, and EFI accomplishes the same objectives. The best thing for Apple/Sun customers would be if they adopted EFI and became truely compatible with Intel hardware standards, fulfilling the promise made when they adopted PCI/AGP.
      • truely compatible with Intel hardware standards

        Well, except of course for the CPUs with entirely different instruction-sets...

      • Re:OpenFirmware (Score:3, Interesting)

        by RalphBNumbers ( 655475 )

        I'd say OpenFirmware has fans because it's been doing most of what EFI promises to do 'real soon now' since the late '80s, and has been doing it as an IEEE standard for a decade.

        And of course, there's the fact that OpenFirmware is still the only firmware standard out there with it's own official theme song [sun.com]. Ha!

      • Does anyone have a working EFI [intel.com] test PC yet?

        I don't understand why legacy 16 bit code cannot be loaded on demand from a disk or flash for legacy boot while using new protected mode boot for a modern OS. Those who need the old code for compatibility simply turn it on in the bios menu.

      • Re:OpenFirmware (Score:5, Informative)

        by oxygene2k2 ( 615758 ) on Saturday September 18, 2004 @04:26PM (#10286852)
        OpenFirmware is standard of 300 pages.. EFI is 3000 pages, I think..

        also, intel claims that it took them "hundreds of man years" to do EFI, while it took a friend of mine and me (basically) the spare time of about 1.5 years to implement most of OF.

        see http://www.openbios.org/ [openbios.org]. (and yes, we're to busy to update the website)
        • Cool project. What's your assessment of the difficulty of providing traditional PC BIOS support on top of OpenFirmware?
          • didn't look to closely at it yet, but it should work the same way as for linuxbios:
            fire up a VM86 and run bochsbios or something like that in there.

            it seems to be enough to run various windows versions with LB, so it should be enough for us, too..

            otoh we currently tend to support new platforms, amd64 and ppc are the first two we've booted on. ppc is nice because it's already an OpenFirmware environment, but there are quite a few buggy implementations in the wild that we hope to replace.

            currently we also
  • For some reason, while I read this my first thought was "Franklin".

  • It's DOS, not BIOS (Score:4, Insightful)

    by LordNimon ( 85072 ) on Friday September 17, 2004 @07:34PM (#10281830)
    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.

    • >There's nothing preventing a vendor from producing a PC with a BIOS >that doesn't support DOS.
      And that won't be a problem for all the worlds bootloaders which _does_ and have to depend on the mode the computer is in when it starts ?
      • Those bootloaders depend on real mode only because that's how the BIOS works today! All that needs to happen is for the BIOS to provide a protected-mode interface that replaces INT 13h, and the bootloaders need to be updated to use it.

        The BIOS developers have all the power already. There are only a few companies out there that have BIOS development teams, and if they just got together and spec'd out a new bootloader interface, the problem would go away in a few years.

    • Re:It's DOS, not BIOS (Score:4, Informative)

      by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Saturday September 18, 2004 @01:45AM (#10283510)
      Back when SGI had their brief love affair with Microsoft, they produced workstations called VisualWS or something. They needed a custom copy of Windows NT, because they didn't have the usual real-mode boot or the DOS-mandated memory layout. This is from memory and I never actually touched one, so I could be wrong of course.
      • To clear up confusion:

        SGI made two batches of PCs. Their first batch, the Visual Workstation 320 and 540 were dual and quad Xeons based on the architecture of their (MIPS/IRIX) O2 workstation. The 320/540 didn't have a traditional BIOS as you pointed out, instead it had an ARCS loader and a PROM, like their MIPS/IRIX workstations. To the end user, this meant a pretty boot screen with an option to go into an equally pretty pointy-clicky GUI "Settings" mode.

        Because of this, the 320 and 540 worked best with
    • Not just DOS! Removing BIOS would break Windows 98, Novell Netware, OS/2. It would also break bootcode in older versions of Linux/NT/BSD/etc. (And even if it was just DOS, may corps still use it to "Ghost" every new machine that comes in the door.)

      Believe or not, millions of customers still use this stuff. Killing back-compat would be a sales disaster. It's not like Apple where they can force customers to run OS x.y.z (released yesterday).

      On another level, there's the psychological factor. All the hardwar

      • Re:It's DOS, not BIOS (Score:4, Interesting)

        by jrumney ( 197329 ) on Saturday September 18, 2004 @05:52AM (#10284104)
        Removing BIOS would break Windows 98, Novell Netware, OS/2. It would also break bootcode in older versions of Linux/NT/BSD/etc.

        Who in their right minds is going to buy a new PC and put such an old OS on it? If you need old versions of OS's around for testing, then keep a few old PCs to run them on. There is no point in keeping 16bit boot support around for hysterical raisons.

        • Re:It's DOS, not BIOS (Score:5, Insightful)

          by anti-NAT ( 709310 ) on Saturday September 18, 2004 @06:45AM (#10284192) Homepage

          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.

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

            Yes, there will always be a need for legacy application support for exactly the reason you stated. But you can get your backwards compatibility with software emulators these days while still getting excellent performance and reliability. My guess is that those legacy apps were designed to run as efficient as possible on hardware that by today'

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

          To run DOS games, of course! How else will you be able to run such great oldies like Civilization, Dark Sun, or even Leisure Suit Larry. Then there is Space Quest, Mega Traveller II, Life and Death, and many other titles, which simply do not exist on any other platform. Windows games these days are mostly of the 3D FPS kind and are rather boring. Linux has no games at all, except for those that can run in an emulator (if yo
          • How else will you be able to run such great oldies like Civilization, Dark Sun, or even Leisure Suit Larry.
            With an emulator.
            A lot of today's hardware should be able to emulate older hardware faster than the older hardware itself ran.
            (OK, that last sentance was somewhat convoluted, but you know what I mean.)

        • Re:It's DOS, not BIOS (Score:3, Insightful)

          by Thing 1 ( 178996 )
          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...

      • Not just DOS! Removing BIOS would break Windows 98, Novell Netware, OS/2. It would also break bootcode in older versions of Linux/NT/BSD/etc. (And even if it was just DOS, may corps still use it to "Ghost" every new machine that comes in the door.)

        It will affect the boot code of all x86 OS's, not just old ones.
        Every boot loader, master boot record bootstrap code and the boot sectors themself assume that the PC boots in 16 bit real mode.
        Making the BIOS fully 32 bit protected mode prevents any existing OS f
      • > It would also break bootcode in older versions
        > of Linux...

        I know nothing in any Linux kernel that needs the BIOS. Older Linux kernels will boot perfectly well with newer bootloaders.
    • I just liked the Rush quote. In addition, I think we might see it happen. Intel hasn't yet ever abandoned their 16 x86 roots, so I guess if past predicts the future....But something tells me that eventually, to lower costs, they may eventually make the switch. Seriously...in 5 years will we still see legacy 16 bit support on multiaple core chips?
  • Make SCO sue me, if Mictosoft won't "help out" with the new firmware! ...And while they are at it, a DRM is implanted=(

  • Ugh. (Score:4, Insightful)

    by bluephone ( 200451 ) <grey@nOspam.burntelectrons.org> on Friday September 17, 2004 @09:52PM (#10282601) Homepage Journal
    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.

  • What's the big deal. I was porting OS's back in the
    early 80's and if by "BIOS" you mean that miserable
    piece of shit that lives in ROM it was mostly only
    capable of loading sector zero of the "whinnie"
    (which is exactly what we did when it didn't).
    (translation for newtimers: Winchester = hard disk.
    "whinnie or winnie = hard disk right?).

    So, why in name would you stick this thing in a ROM? It could have always lived and been loaded off the friggin disk. Do it that way and you get the
    benefit of being able to up
  • How did God create world in 7 days, He had no installed user base to consider.

Slashdot Top Deals

Life is a game. Money is how we keep score. -- Ted Turner

Close