BIOS Will Be Dead In Three Years 532
Stoobalou writes with news that MSI is planning a big shift towards UEFI (universal extensible firmware interface) at the end of 2010, possibly spelling the beginning of the end of the BIOS as we know it. "It's the one major part of the computer that's still reminiscent of the PC's primordial, text-based beginnings, but the familiarly clunky BIOS could soon be on its deathbed, according to MSI. The motherboard maker says it's now making a big shift towards point-and-click UEFI systems, and it's all going to kick off at the end of this year. Speaking to Thinq, a spokesperson for the company in Taiwan who wished to remain anonymous said, 'MSI will start to phase in UEFI starting from the end of this year, and we expect it will be widely adopted after three years.'"
Re:A GUI for the motherboard? (Score:5, Informative)
I've seen quite a few machines like this when I did computer repair. Most were major brands at the time -- Compaq, Packard Bell, etc -- and the GUI tended to be a knockoff of Windows 3.1.
Presumably this was to make users less afraid of changing their BIOS settings, although considering some of the users I dealt with, that might not have been such a good idea.
Re:I read the article... (Score:1, Informative)
Just some marketing bullshit, don't worry.
BIOS vs. EFI (Score:5, Informative)
Very uninformative. It sounds like UEFI is a BIOS (basic input-output system), only it's mouse/graphics based rather than text based. What am I missing here?
EFI, which is already used in Mac computers with Intel CPUs, doesn't implement the syscalls inherited from IBM PC BIOS. Things like Boot Camp add PC BIOS on top of EFI.
Comment removed (Score:3, Informative)
Re:I read the article... (Score:5, Informative)
traditional BIOS are an archaic nightmare really.
Most new technologies in them are work around hacks required to maintain some support for very old communication protocols (6GB SATA drives still have to support IDE mode why?) etc.
Give this a read:
http://duartes.org/gustavo/blog/post/how-computers-boot-up [duartes.org]
Re:So .... (Score:4, Informative)
Linux has supported EFI for quite some time. And EFI has BIOS compatibility modes (or it can.. that's one of those "extensible" things). Mac's, for instance, use EFI and have since they went Intel (possibly earlier, but I think the Intel macs were the first).
Linus is not a big fan of EFI though.. says it's a bigger, clunkier bios.
Re:Security (Score:1, Informative)
*BSD and Linux support EFI (Score:5, Informative)
Is it likely to cause problems for Linux and BSD?
Intel Macs already use EFI [wikipedia.org]; therefore at least one BSD (Darwin) already supports it. Linux supports EFI too.
Re:about time (Score:3, Informative)
My thinkpad 600x has a gui bios for the date/time, this is about 1993 vintage. Back then apple were trying to sell tablet devices.
Re:about time (Score:1, Informative)
I don't think you understand UEFI. UEFI is not an open standard. It is far more locked down and proprietary than the BIOS has ever been. There is a big push to use LinuxBIOS instead of UEFI because of the proprietary and narrow minded approach that UEFI takes.
Re:about time (Score:3, Informative)
Apple's "first" was not doing it; but doing it exclusively across all their models.
Re:about time (Score:5, Informative)
No, Microsoft implemented EFI in Vista, although they only put it in the 64 bit versions IIRC. I can't wait for 32 bit Windows to die a horrible death... then more people (like Adobe) will start fully supporting 64 bit windows (and no, 64 bit Photoshop is not enough, let's get a 64 bit flash).
Primordial? (Score:3, Informative)
BIOS is not dead (Score:5, Informative)
From the faq at uefi.org:
Q: Does UEFI completely replace a PC BIOS?
A: No. While UEFI uses a different interface for "boot services" and "runtime services", some platform firmware must perform the functions BIOS uses for system configuration (a.k.a. "Power On Self Test" or "POST") and Setup. UEFI does not specify how POST & Setup are implemented.
Re:A GUI for the motherboard? (Score:5, Informative)
Oblig:
http://en.wikipedia.org/wiki/UEFI [wikipedia.org]
It's more a strategy to remove 16-bit and other legacy restrictions from the firmware interface:
"The Extensible Firmware Interface (EFI) is a specification that defines a software interface between an operating system and platform firmware. EFI is a much larger, more complex,[1][2]:4 replacement for the older BIOS firmware interface present in all IBM PC-compatible personal computers."
Re:A GUI for the motherboard? (Score:5, Informative)
It's more than that. This will cause a DOS compatibility issue. This means that the floppy boot process and other handy-dandy things we've been doing that uses DOS of some kind (Microsoft, IBM, FreeDOS, whatever) to boot up and get devices working through the config.sys and all that used BIOS hooks to get much of the I/O accomplished.
I don't know whether or not UEFI's services provide compatible techniques or if whole new things need to be created, but it would seem to me that many low-level recovery and imaging tools may be lost to us. Perhaps Symantec needs to update its Ghost to run on Linux, for example, as Ghost currently runs on DOS which uses BIOS hooks for I/O.
Re:I read the article... (Score:3, Informative)
GPT is part of the EFI standard.
It is used on some BIOS based system.
The problem with the standard MBR is that it does not support _partitions_ (note partitions, not disks) greater than 2 TB.
It also doesn't allow the start address to be higher than 2TB. This means your boot partition has to start in the first 2TB of the disk and be smaller than 2TB. The disk can actually be larger than 2TB.
Re:Wow (Score:5, Informative)
EFI has been around for about 15 years, but was an Itanium thing... UEFI was created about 5 years ago and adapted it for use with x86 and x64 computers. Apple has been using it since 2006 in all their Mac based PC's.
Unfortunately, OpenFirmware was withdrawn from the IEEE in 1998, so OpenFirmware isn't really a standard. And there wasn't really an Open Source implementation until 2006 (a year after UEFI was introduced).
So to say (paraphrasing) "Why didn't intel use OpenFirmware instead of creating their own?" is to ignore the face that OpenFirmware was a non-player at the time.
Re:A GUI for the motherboard? (Score:5, Informative)
You should switch to FOG, it is free and uses PXE. It is better than Ghost in every way.
None of what you speak of should be done with dos floppies in 2010, linux boot usb sticks are the way to do this stuff.
Re:A GUI for the motherboard? (Score:5, Informative)
Ghost also runs in the WinPE boot environment without any problems. WinPE should boot off EFI based systems without a problem as it's used in the Vista and 7 boot DVDs. Just run Ghost32.exe from within WinPE and use Ghost like you always have.
Re:A GUI for the motherboard? (Score:3, Informative)
The point isn't the GUI. The point is that EFI is a REPL, much like Sun + Apple's OpenFirmware. The BIOS just does a few things: scan ram, handle input and output. Your "BIOS screen" really didn't have anything to do with the BIOS, except that the BIOS hosted it. (Presumably you could load up new firmwares through it, which would change how the BIOS is programmed to operate)
Now, picture a world where device drivers are written at the EFI level, using a nice language. Where any operating system that speaks EFI can use any hardware with EFI drivers.
Re:Security (Score:5, Informative)
HW Manufacturers will require EFI firmware to be signed in order to install it. See "executable verification" in this PDF [intel.com]
Re:I read the article... (Score:4, Informative)
AMI Winbios was GUI-based. And it existed in 1995!
Re:A GUI for the motherboard? (Score:3, Informative)
Compaq used a special service partition on the HD to run that GUI based BIOS and diagnostics.
There was one true GUI BIOS out there, the AMI WinBIOS. Nobody really adopted it and stuck to the old "pink screen" AMI BIOS. (remember those?)
Re:Finally! (Score:5, Informative)
Read: http://kerneltrap.org/node/6884 [kerneltrap.org]
Linus continued in a followup email, "don't get me wrong - the problem with EFI is that it actually superficially looks much better than the BIOS, but in practice it ends up being one of those things where it has few real advantages, and often just a lot of extra complexity because of the 'new and improved' interfaces that were largely defined by a committee." He went on, "so EFI has this cool shell, a loadable driver framework, and other nice features. Where 'nice' obviously means 'much more complex than the simple things they designed in the late seventies back when people were stupid and just wanted things to work'. Of course, it's somewhat questionable whether people have actually gotten smarter or stupider in the last 30 years. It's not enough time for evolution to have increased our brain capacity, but it certainly _is_ enough time for most people to no longer understand how hardware works any more." As for BIOS, Linus noted, "not that I'd ever claim that the BIOS is wonderful either, but at least everybody knows that the BIOS is just a bootloader, and doesn't try to make it anything else."
Useless abstraction layers are useless.
Re:I read the article... (Score:4, Informative)
It may be _a_ basic input output system, but it is not the BIOS, which -- if I understand correctly -- was originally how all input/output was done through PCs.
BIOS was originally the small part of CP/M that had to be tweaked with the details of how to get to the devices on your particular hardware. It consisted mainly of things like character drivers for the keyboard, console text display (if present), and serial ports, and sector read/write drivers for the floppy disks.
As of the early xx86 IBM PCs the equivalent functionality (and more) had been added to the boot ROM, rather than having the boot ROM be JUST a basic boot-and-launch driver. Then with bigger/cheaper ROM in successive generations there was a race between bloat, "feature protection" (such as anti-overclocking) and "trojan horse features" (DRM, AMT, ...) in the BIOS vs. OSes recovering control of the hardware interfaces to improve flexibility for functionality upgrades (at the cost of having to understand more about the particular machine's hardware).
These days even Wikipedia doesn't seem to cover the origins.
Re:I read the article... (Score:3, Informative)
"IDE Controller,"
The correct term is "IDE host adapter" or "IDE host bridge". The IDE controller sits on the device, where the BIOS can't reprogram or otherwise influence it in any way...
Re:But... (Score:3, Informative)
Depends on manufacturer, some is F2, some is F10, some is DEL, some is F12 and there are probably a lot more fun combinations (like the one where you access the "hidden" Dell software for testing).
Re:A GUI for the motherboard? (Score:3, Informative)
FOG is nice, but it does not have all of the features of Ghost Solution Suite (the enterprise product under the Symantec brand, not the consumer one under the Norton name). I really wanted to use it, but it was missing two major features that I could not live without:
1) It will only run under PXE boot, so it requires that you have control over DHCP wherever you are. With GSS I can use a "virtual partition" to boot from, so it will download the boot system from the server, then boot without ever requiring me to get special information from a DHCP server. Since my clients need to be able to roam to many network segments (that I have no control over, and may have their own network boot servers), including home networks, I can't use FOG.
I should note that this is one thing I hope will change under UEFI. Apple's implementation (while being a bit off the standard) is a great example of the flexibility that having a more intelligent boot system can do.
2) The system tray item does not allow my clients to initiate a re-image when they want. For my purposes they have to be able to trigger a re-image of a computer in front of them in a easy-GUI way. We get a lot of people flowing through and while I may have my pain-points on the GSS version of the system tray icon, it is drop-dead simple to implement and only requires a "see, here is the tool you use" level of training.
So no, FOG is not better in all ways than Ghost (at least not GSS).
Not About The GUI, It's About ROM Space (Score:1, Informative)
I have several hundred IBM x3x50-M2 series machines in my data center and as of this generation they're all running UEFI. It's not about the GUI at all - most of the operations are still text-based move-with-arrow-key kind of operations. The point is that UEFI is supposed to present better forward compatibility with 64-bit and above systems.
One example is that BIOS bootstrap ROM address space is limited to ~64K of space to load device BIOS information. I have machines that are loaded with FC HBAs and additional NICs and if you put just ONE too many peripheral cards in a server it will experience the dreaded 1366 error and refuse to boot. This is because each card you install is taking from 2K to 16K of BIOS ROM address space for its own mapping. The only fix for machines like this are to either disable the card BIOS from the server BIOS configuration screen and allow the OS to pick it up post-boot or remove the card entirely.
UEFI on IBM machines is capable of mapping up to 2TB of address space (I think they're only equipped with 16MB of memory for this function however). You'll never run out of space for additional devices.
Pros to UEFI:
-No limit to peripherals.
-Ability to view and configure peripherals directly from the UEFI configuration screens rather than post-POST CTRL-key operations.
-Large code space enables some pretty esoteric functions to be performed if programmed for them.
-Handles 64-bit and above OSes and address spaces without resorting to cheap hacks.
-Potential for open-source UEFI code to customize machines.
Cons to UEFI:
-Godawful horrible slow boot process. Has to essentially boot a mini-computer in place of a hardwired BIOS and then "configure" it. Takes up to 5 minutes from a cold start to POST.
-GUI screens don't interact well with most KVM systems.
-Code is still very flaky even after over a year in the field.
-Maintaining a working UEFI environment will be hell on earth for the hardware developers as they'll have to not only customize each machine's UEFI but add all of the working "modules" to it.
If they can make UEFI smooth and fast (don't worry about a freaking GUI - just make it work) I see the potential in it. We are coming close to the limits that BIOS can handle without introducing more hacks (BIOS64?) and complications.
This probably isn't the most cogent thing I've written, but then again, I've got a machine in the back I need to go work on that's endlessly recycling on a UEFI boot screen... ;)
Completely wrong! (Score:3, Informative)
Re:A GUI for the motherboard? (Score:3, Informative)
It will only run under PXE boot, so it requires that you have control over DHCP wherever you are.
You might like to try gPXE. [etherboot.org] You can, either by chainloading SYSLINUX or PXELINUX or using COM32 modules, implement exactly what you describe using almost any medium you desire, whether that's floppy, PXE/DHCP/ProxyDHCP, local disk, USB, etc, configured as you desire, so that as long as it's on any network that can route to your boot server, it'll behave the same every time. You could even burn gPXE directly into the NIC of your target machines, and remove the need for a "virtual partition" altogether. Of course you can set everything up in the DHCP server, or, if you like, point the client at an HTTP server and sort it all out with PHP or something.
:-)
Most likely, you're looking to use an embedded script that wants DHCP from the local segment, then contacts a specific server every time, regardless of DHCP settings.
Also, gPXE already supports EFI in addition to BIOS based systems. In the meantime, I'm gonna go look at FOG
Re:Security (Score:3, Informative)
That's the *chortle* brilliant *chortle* slashcode developers at work.