EFI Arrives..Finally

[ronach]

You techies ,overclockers and tinkerers may find this news interesting. Check out these links and post your opinions. http://www.theinquirer.net/gb/...ews/2008/01/19/msi-efi , http://www.uefi.org/about/.

This specification would benefit most of us here at Anandtech..I for one have been waiting for this type of pre-OS bootup control for some time now.

 

[jhu]

i used to be proponent of having a bios replacement, especially after getting my first mac and playing around with openfirmware. now i don't really care anymore since all it does is rudimentary hardware setup and passes control to the os, which does everything else.

 

[QuixoticOne]

Couldn't be soon enough for me.

BIOS is a major bane of the PC right now that turns what could be
"workstation / server" class hardware into "consumer junk".

Even today with a very new / high end "enthusiast" motherboard you're VERY lucky
if you don't have at least 5-6 fairly important BIOS functions that are just ABSOLUTELY
broken beyond use, and generally speaking most of those errors will NEVER be fixed despite
the 6 or so "BIOS updates" the OEM may (if you're lucky) will eventually publish.

Want to run a PC with NO keyboard / display / mouse? Good luck.

Want to boot with BIOS / console output going to a serial port or ethernet or whatever
so you can remotely / automatically control the PC's boot settings? Good luck.

Want to control WHICH of several video display boards / interfaces the system will
actually use for BIOS / boot setup, or tell it to use ANY/ALL of them depending on what's
connected? Good luck.

Want your BIOS to ACCURATELY tell the temperature of your CPU? Good luck; it's VERY
problematic even on the enthusiast / gamer type motherboards, even if your CPU model is
officially supported in the BIOS release. There are several notorious cases where major
M/B OEMs have LARGE systematic temperature errors.

Use a USB hub / keyboard and want to access the BIOS setup, *and* the RAID / LAN BIOS setup and
management screens? Good luck. Bugs galore. Often it just won't work in newer hardware,
and it almost certainly wouldn't work on anything over a few years old.

USB HID KB/mouse/hub has been TOTALLY standardized since around 1997, so for over 10 YEARS
it's been massively broken in most BIOSes. Win98SE supported it badly but from that point on
there's really no excuse for the slightest problem.

Use a USB mouse / keyboard / hub and want to actually be able to use keyboard / mouse
based sleep & wake-up? Good luck.

Want to reliably PXE boot from ethernet not a local disk? Good luck. If it works at all for a start,
chances are the retry / timeout stuff is pretty broken so it'll never be reliable for most BIOSes
if you expect the PC to boot unattended / unsupervised and reboot well even if it crashes /
power fails / the server goes down for a while.

Want to change your CPU Vcore voltage? Or even KNOW accurately what it is?
Good luck. Many notorious problems where it'll pretend to let you specify the value to
1mV precision, but if you check it with a calibrated voltmeter the REAL value the BIOS
sets is like steadily 200 mV off or something like that.

Want to use/set up a useful boot order of disks, floppy, cd/dvd, removable USB boot devices,
firewire / eSATA boot devices? Good luck. Totally broken functionality in every BIOS I've
ever seen so that many options are just IMPOSSIBLE / NON-FUNCTIONAL, and many of the ones
it does support it doesn't let you configure the way you want them.

Want to be able to do something simple like have the BIOS tell the OS that certain amounts
of memory are not present / not used (maybe your 32 bit OS has a problem with too much
memory or whatever)? Good luck.

Want to be able to effectively have the BIOS disable / turn off / report as absent certain disk
drives or disk controllers so the OS will have a clue NOT to use them? Good luck.

Want to be able to configure simple spin-up / sleep type options in your drives so the BIOS
or OS won't unnecessarily activate drives it won't need to boot? Good luck.

Want to boot from a DVD-CD / USB stick / USB CD-DVD? Good luck. Even this doesn't work
a lot of the time in a lot of systems today.

Maybe the DMI stuff can help do a FEW of the remote system management things (if it even
works), but overall the OpenBoot / EFI type systems I have used in SUN systems and so on
have been MUCH better to use / configure and the ability to use more advanced F-CODE
type scripts to control the hardware / boot process is GREAT. As is the richer interaction
of the OS / BIOS where you can pass information better between the console, the BIOS, and the OS.

 

[Peter]

None of this will change with EFI by default - because it's still up to the mainboard's makers to do a good or a shit job. Everything you listed is possible to implement in BIOS, and just as well you can screw up any of them in EFI.

The big benefit is not for the user, but the developer - it's 32- or even 64-bit code in C, not 16-bit assembler anymore.

Users will find that an EFI machine currently doesn't boot ANY of their beloved legacy operating systems. No XP, not even Vista 32-bit, and even will Vista 64-bit won't until SP1 is here. Currently it's Linux and Apple's OS, and that's it. Given how MS won't support 32-bit EFI, so few boards will give you the alternative 32-bit EFI at all.

Yes, EFI is /either/ 64 or 32 bit, and no, the user no longer has the choice of OS type. If your EFI is 64-bit, then you can't run 32-bit operating systems.

So while I, as a BIOS engineer of trade, welcome the new architecture and don't pine the departure of all the old cruft at all, users probably won't like it as much - particularly the "enthusiast" user who likes to swap out stuff while keeping the rest. Buyers of complete PC systems neither notice nor care why the thing is booting ...

 

[Schadenfroh]

Originally posted by: Peter
The big benefit is not for the user, but the developer - it's 32- or even 64-bit code in C, not 16-bit assembler anymore.

That is a big improvement!

 

[Peter]

Originally posted by: Schadenfroh

Originally posted by: Peter
The big benefit is not for the user, but the developer - it's 32- or even 64-bit code in C, not 16-bit assembler anymore.

That is a big improvement!

We'll see. For those who know what they're doing, it's a huge big relief.

However: What typically happens when you make an impenetrably difficult task easier? No, you don't get better quality. You get more halfbakery from people who aren't quite up to the job, but are now enabled to do it anyhow.

 

[QuixoticOne]

Originally posted by: Peter
None of this will change with EFI by default - because it's still up to the mainboard's makers to do a good or a shit job. Everything you listed is possible to implement in BIOS, and just as well you can screw up any of them in EFI.

The big benefit is not for the user, but the developer - it's 32- or even 64-bit code in C, not 16-bit assembler anymore.

Users will find that an EFI machine currently doesn't boot ANY of their beloved legacy operating systems. No XP, not even Vista 32-bit, and even will Vista 64-bit won't until SP1 is here. Currently it's Linux and Apple's OS, and that's it. Given how MS won't support 32-bit EFI, so few boards will give you the alternative 32-bit EFI at all.

Yes, EFI is /either/ 64 or 32 bit, and no, the user no longer has the choice of OS type. If your EFI is 64-bit, then you can't run 32-bit operating systems.

So while I, as a BIOS engineer of trade, welcome the new architecture and don't pine the departure of all the old cruft at all, users probably won't like it as much - particularly the "enthusiast" user who likes to swap out stuff while keeping the rest. Buyers of complete PC systems neither notice nor care why the thing is booting ...

Well, all true.

A different platform doesn't mean that you can't have bugs and
half-baked tools. But at least instead of *ad hoc* throw-away kludge
code to sys-init you'll have more rich, more standardized frameworks,
and a much more powerful configuration / scripting language.

Only the MOST die-hard people today would try to patch a buggy
BIOS themselves (it has been done, though). But it wouldn't be
so infeasible to start independently fixing / rewriting some scripts
for things like ACPI, F-code logic to configure your storage / display /
net boot, etc.

Also modularity should benefit where you can start to have more
3rd party (peripheral manufacturer vs mainboard OEM) maintained
boot code updates / modules for their own peripherals.
Hopefully that means more quality and more accessable / prompt fixes if
it's more of a soft-configuration vs. the entire BIOS.

As to booting legacy stuff? I sure HOPE that's going to be
irrelevant REALLY SOON.

As it is on my latest PCs (quad-core, 8GB RAM) I've run several
legacy OSs in a VM rather than even bother booting them "for real"
and that works pretty well except where physical peripheral
IO that isn't able to be well virtualized yet (GPU,USB) prevents it,
and for the current CPU generation with IOMMU apparently even
the real hardware devices will be able to be given virtualized well.
I'm sure a legacy OS will typically run at MORE than the full speed that
it originally ran on a high end computer of its day in a VM on a
multi-core system with IOMMU.

I'm encouraged by things like the spashtop or sideshow stuff
(though a bit kludgy given today's BIOS / motherboard architectures)
that lets your "BIOS" mode system functionality be more at the
level of an OS itself. You ought to be able to have rich configuration
of the machine and even basic functionality (ftp, www, ssh, disk
partitioning, disk partition resizing, virus scan, access notes, email,
etc.) even WITHOUT the full features of an OS. Sticking in a
2-4 Mbyte "live image" of a useful BSD/LINUX system right into
the hardware for recovery / management / utility purposes isn't asking
a lot given current hardware capabilities.

 

[Peter]

Modern BIOSes aren't half as spaghetti and "ad-hoc throwaway" as you appear to think. Modularity exists on a source code level, but not so much on the binary end of it. 3rd party modules, and updates thereof, are also something that has been existing for a long while. (And besides, poor programming can screw up anything. Even more so if it's "easy to do". I said that )

EFI can do add-on functionality much easier, and on a much bigger scale, owed to the 64-bitness of the environment and standardized APIs for the supported hardware.

 

[jhu]

Originally posted by: QuixoticOne
...

people said the same thing about x86, and yet here we are still using x86

 

[jhu]

Originally posted by: QuixoticOne

I'm encouraged by things like the spashtop or sideshow stuff
(though a bit kludgy given today's BIOS / motherboard architectures)
that lets your "BIOS" mode system functionality be more at the
level of an OS itself. You ought to be able to have rich configuration
of the machine and even basic functionality (ftp, www, ssh, disk
partitioning, disk partition resizing, virus scan, access notes, email,
etc.) even WITHOUT the full features of an OS. Sticking in a
2-4 Mbyte "live image" of a useful BSD/LINUX system right into
the hardware for recovery / management / utility purposes isn't asking
a lot given current hardware capabilities.

here you go

 

[Fox5]

I remember there was a couple open source firmware alternatives. They basically stripped the bios down to the minimum possible, assuming that there would always be a full OS enumerating all the hardware anyway.

 

[QuixoticOne]

Sure I know that they're not so unmodular when you're
the BIOS developer and have the BIOS source code and toolset etc.
e.g. "award modular bios" is even what they proclaim when it boots.

But that level of modularity is almost useless lacking any OEM
quality control and dedication to improving their products with new
releases until they actually work for all specified features.
After about 5-6 BIOS releases even for popular high end motherboards
the OEM just decides it's not worth the bother and doesn't ever fix
anything else even if there are well understood bugs remaining.

Most motherboard OEMs can't even be bothered to devotedly post
current *DEVICE DRIVER* versions applicable to their boards on
their support websites, so expecting BIOS updates is ...quixotic.

Whereas if a 3rd party like Intel, Silicon Image, Marvell, Promise,
Seagate, Realtek, whatever was empowered to write new
F-CODE or whatever modules for supporting *their products*, there'd
be a better chance they'd do it or they'd look bad instead of just being
able to hand off the blame to the M/B OEM for not fixing the overall BIOS.
And of course if the end user could then apply these modules via
patch updates from the 3rd party support sites, there'd be a much
better / quicker process to improve things.

For instance I've got a DELL PDA that has had exactly *two*
firmware updates *ever* (which includes the WHOLE OS and
ALL the basic applications), and that's from the time it was
top of the line state of the art to when it's end-of-life, no more support
EVER. In the same time period, however, Microsoft has made
DOZENS of patches / updates available to its Windows Mobile OS
for OEMs to publish in new firmware images (the end user CAN'T
modularly apply the patches ala carte), but the OEMs just DON'T BOTHER.
Tons and tons of basic software things just don't work right, or could
work a lot better and never will due to this "it's not my concern"
attitude with the firmware leaving it out of the end user's hands and
out of the actual chipset / application / OS developers hands too.

I have yet to see a decently working ACPI PC without at least
some crippled aspects, and in many cases it'd only take some
TRIVIAL AML script fixes in the BIOS to change something that
crashes on wake-up or fails to suspend to something that actually
*works*. No BIOS code change at all, just ACPI tables; it's never done.

Originally posted by: Peter
Modern BIOSes aren't half as spaghetti and "ad-hoc throwaway" as you appear to think. Modularity exists on a source code level, but not so much on the binary end of it. 3rd party modules, and updates thereof, are also something that has been existing for a long while. (And besides, poor programming can screw up anything. Even more so if it's "easy to do". I said that )

EFI can do add-on functionality much easier, and on a much bigger scale, owed to the 64-bitness of the environment and standardized APIs for the supported hardware.

 

[jhu]

well, that's a completely different issue then: oems supporting hardware via firmware updates. i don't think efi would help much in that regard.

 

[VirtualLarry]

Originally posted by: QuixoticOne
Want to be able to do something simple like have the BIOS tell the OS that certain amounts
of memory are not present / not used (maybe your 32 bit OS has a problem with too much
memory or whatever)? Good luck.

I've wanted that for a while now. It would make it easier to triple-boot with Win98se with a modern rig, since Win98se has errors with greater than 512MB of RAM. It would also allow an easy workaround for the Vista 4GB install bug.

 

[Peter]

Yeah, QuixoticOne, your software quality rant is heard, but really, it's nothing to do with the choice of firmware platform. It's a symptom of the general end user's buying behaviour. There's an impressing willingness to put up with sh*t software rather than put the money where the quality is. Always the latest and greatest, if it still has rough edges, "it's just software issues, let's wait for updates" rather than return it and buy something slightly older that's actually been developped and tested all the way through. Etc. etc.

Getting the software right upon release is possible - and where customers demand it, it is actually being done. Server gear, embedded x86 computing in mission critical aero, space, medical applications, they all can do it. It costs money, it takes time, and you're not getting a "new and improved" piece of hardware every three months either.

The normal computer buyer is different. When Intel or AMD present a new chipset or CPU, everyone here expects product on shop shelves five seconds later. Of course it's not going to be good product, but it's being bought anyway, even at the premium prices charged for "early adopter" kit. As a manufacturer in this area, you need to be first to market, not first to market with something that works right - and by the time you'd know enough to actually achieve the latter, you're already two or three generations of halfbakery further down the line. Project engineers don't grow on trees, so the "old" product quickly has to be abandoned.

So much for the general direction of the problem. Now, details.

Even with EFI, you, the end user, is not going to create any patches nor are you going to merge any 3rd party updates into some uncaring OEM's base frame - at least no more than you can now use a BIOS ROM module manager tool to replace a PXE boot image or an integrated VGA BIOS.

Likewise, ACPI is far from being "just tables", vast misconception there too. ACPI is mostly code, existing to abstract the board specific implementation of certain hardware features so the OS can remain generic. With few exceptions of bleeding obvious coding errors, modifying the ACPI in a way that makes sense requires in-depth knowledge of the particular hardware design and what the boot firmware does with it.

 

[Peter]

Originally posted by: VirtualLarry

Originally posted by: QuixoticOne
Want to be able to do something simple like have the BIOS tell the OS that certain amounts
of memory are not present / not used (maybe your 32 bit OS has a problem with too much
memory or whatever)? Good luck.

I've wanted that for a while now. It would make it easier to triple-boot with Win98se with a modern rig, since Win98se has errors with greater than 512MB of RAM. It would also allow an easy workaround for the Vista 4GB install bug.

I repeat: You're not going to boot a 32-bit OS on an EFI machine.

Pretend-RAM-reduction is something that is perfectly possible in a legacy BIOS just as well - as long as the chipset hardware can actually do it.

 

[ViRGE]

Originally posted by: Peter

Originally posted by: VirtualLarry

Originally posted by: QuixoticOne
Want to be able to do something simple like have the BIOS tell the OS that certain amounts
of memory are not present / not used (maybe your 32 bit OS has a problem with too much
memory or whatever)? Good luck.

I've wanted that for a while now. It would make it easier to triple-boot with Win98se with a modern rig, since Win98se has errors with greater than 512MB of RAM. It would also allow an easy workaround for the Vista 4GB install bug.

I repeat: You're not going to boot a 32-bit OS on an EFI machine.

Pretend-RAM-reduction is something that is perfectly possible in a legacy BIOS just as well - as long as the chipset hardware can actually do it.

Correct me if I'm wrong, but doesn't the EFI specification allow for BIOS emulation? My understanding has been that EFI was designed with the transition in mind, so we'll start with EFI boards featuring BIOS emulation to keep old operating systems, and then slowly wean users/OEMs from the BIOS.

 

[Fox5]

For instance I've got a DELL PDA that has had exactly *two*
firmware updates *ever*

If it's a x50v or x51v, then a nice gent that goes by football has released some home made updated firmware for them that works damn nice. Makes the devices work like they should have when they were launched.

 

[Peter]

Originally posted by: ViRGE
Correct me if I'm wrong, but doesn't the EFI specification allow for BIOS emulation? My understanding has been that EFI was designed with the transition in mind, so we'll start with EFI boards featuring BIOS emulation to keep old operating systems, and then slowly wean users/OEMs from the BIOS.

The "legacy emulation" layer you can include in an EFI is minimal, barely good enough to boot to DOS, but nothing on top of that. No PnP or PCI services, none of any recent stuff, just the bare PC-AT basics like they were in 1984 essentially.

 

[RebateMonger]

Gateway did an integrated media center PC (Gateway 610 Media Center) back in 2003 with EFI. It ran XP. Apparently, it still contained a legacy BIOS to allow it to boot Windows.

I've (unfortunately) seen one of these. I had to strip EVERY SINGLE PART from it (about an eight-hour job) to reach the failed hard drive for data recovery.

 

[Nothinman]

Want to be able to do something simple like have the BIOS tell the OS that certain amounts of memory are not present / not used maybe your 32 bit OS has a problem with too much memory or whatever)? Good luck.

That would be much better done in the OS anyway. Linux and NT both support kernel parameters to limit the amount of memory that they'll use. I'd much rather use that method than have to go into the BIOS on boot to change it anyway.

I repeat: You're not going to boot a 32-bit OS on an EFI machine.

Tell that to all of those Apple users who have 32-bit XP or Vista dual-booted on their machine.

The "legacy emulation" layer you can include in an EFI is minimal, barely good enough to boot to DOS, but nothing on top of that. No PnP or PCI services, none of any recent stuff, just the bare PC-AT basics like they were in 1984 essentially.

Maybe the reference "legacy emulation" included with EFI is too minimal but it's obviously possible since Intel Macs use EFI and it's possible to dual-boot them with BootCamp.

 

[Peter]

The secret to "how do I boot a legacy OS on an EFI machine" lies in what you've already explained: You write your own bootloader - one that uses the EFI interface to replace the original one that uses legacy BIOS interfaces.

If your legacy OS has minimum requirements toward these legacy APIs, then you may get away with the "compatibility layer" of EFI. Fat chance though that it doesn't (unless it's plain DOS or some embedded OS), or that the machine vendor didn't even bother putting a CL in (like Apple, for obvious reasons).

 

[VinDSL]

Originally posted by: QuixoticOne
Couldn't be soon enough for me.

BIOS is a major bane of the PC right now that turns what could be
"workstation / server" class hardware into "consumer junk"...

True that...

You should see the BIOS in this (typical) Toshiba laptop!!! :laugh:

BIOS doesn't allow the possibility of changing hardly anything - looks like something from the early 90's!

EFI couldn't be soon enough for me either...

 

[Peter]

And one more person fails to grasp the essential difference between how things are done and what is being done.

In a laptop, there is exactly zero reason for having a ton of "tweaks" in BIOS or EFI. The hardware is a given, no expansion slots (other than for a well known, predetermined set of manufacturer options) and no upgradability, so why should there be ANYTHING the user should need to futz around with? (Note the difference between "need to" and "want to"!)

Face the facts - in a well built and well tested closed system, there is absolutely no reason for having any of that. Boot device selection, time and date adjustment, that's all you'll ever need. This is not a sign of something being "from the early 90s", it's in fact the total opposite. Back then, BIOSes had a ton of chipset, RAM and even bus timing options ... and you actually did need to spend hour after hour figuring out how to get the thing to be stable. Thanks to the departure of the ISA bus and the arrival of /truly/ auto-detectable hardware like PCI and DIMMs, none of that sh*t is needed anymore.

And you better be glad, or else I'll give you an early 1990s PC puzzle to solve ... VESA local bus graphics and multi-IO, eight SIMM slots, cache RAM in sockets, 80 MHz AMD486DX, ISA SCSI card, and a SoundBlaster megamonster with its own pair of SIMMs on. Two dozen hardware configuration jumpers on the mainboard and about this many on the cards before it even twitches, three pages of obscure chipset configuration tweaks before it's stable and some more before it's stable and fast - and then install your operating system, which is another fun game if you don't have PnP.

 

[VinDSL]

Originally posted by: Peter
And one more person fails to grasp the essential difference between how things are done and what is being done.

In a laptop, there is exactly zero reason for having a ton of "tweaks" in BIOS or EFI...

Face the facts - in a well built and well tested closed system, there is absolutely no reason for having any of that...

Um...

What if I decide to do the same thing as OEMs (Dell, Lenovo, Toshiba, Sony, et cetera) - buy a line-built barebone from an ODM (like Compal or Quanta) and custom build it myself?

Truth be told...

I'm rolling my own next time, just like the big dogs, and rebadging it with MY name!