PC firmware, a murky world of interwoven software code that dates back to the original IBM PC and its clones, is about to be modernized. In a move that experts say promises to lead to fewer headaches for IT staff by creating more stable and manageable desktops and notebooks, the PC industry has begun transitioning to the United Extensible Firmware Interface. Dubbed UEFI, the interface offers a standardized way for a PC’s firmware, the underlying software that controls its hardware, to interact with the operating system. The new interface offers a standard method for loading an operating system, as well as running pre-boot applications.
This was news 12 months ago(on here!)
EFI is great for netboot and exotic configurations, but it opens up the doors for a new kind of evil BIOS virus. I saw a presentation on EFI in 2003 at a monthly meeting of TACLUG http://www.taclug.org
Edited 2006-02-01 20:26
Conspiracy Drive at full power, but I’m thinking a new “BIOS” will allow makers to sneak in finer DRM control. Why not? If you can access the internet even without the OS loaded that’s just perfect.
All I can say is that I hope that is not the case. I would like to put my foil hat away.
Conspiracy Drive at full power, but I’m thinking a new “BIOS” will allow makers to sneak in finer DRM control. Why not? If you can access the internet even without the OS loaded that’s just perfect.
You do realise that they’ve already done this with the current crop of BIOS firmware – IIRC, its being sold by Pheonix and used in IBM computers.
I admit I don’t know much about UEFI, but I do know this much: the needs of corporate IT departments and the needs of individual/small users are not the same. In fact, they are usually the exact opposites. Take the idea of network being accessible before any OS even boots – why would that be a good thing for me? It sounds positively EVIL as far as I’m concerned.
I regard anything that promises to “make life easier for corporate IT departments” with utmost suspicion. MY computers will not be moving to UEFI as long as the old BIOS is around.
I wouldn’t mind being able to netboot my laptop. Sure could save on some power usage if you had your desktop close by!
Just because they’re not good for _you_ doesn’t mean they’re not good for other home users.
I’ll happily move to anything which abolishes ACPI and ushers in an erra where vendors stick to the standard
.
Just how exactly would this save power usage? What crackpot booting scheme are you thinking of?
It’d lower cpu usage during cpu intensive tasks by almost 100% since your server would do everything and you simply view it.
It’d require no disk accesses, that saves an enormous amount of power.
And it’d require fewer memory accesses.
The only thing that’d hurt you is the increased wireless bandwidth which may make up for half or a little more of your gains.
I think overall you’d seen improvement though.
Well, I always enjoy how people brag about only running and using Free software… And then see their face the moment you tell them virtually ALL x86 computers have closed-source software built-in which you can’t replace with an open-source solution… The BIOS
.
So, in other words, is UEFI anything like Openboot? As in, actually open?
OpenBoot is more-or-less equally open as the traditional x86 PC BIOS.
So, in other words, is UEFI anything like Openboot? As in, actually open?
EFI isn’t just an x86 solution, the idea was that it could also replace OpenBoot – the idea was to take the good aspects of OpenFirmware, correct the crappy problems, and voila, a firmware that doesn’t suck.
The biggest perk I think people forget is this, UEFI/EFI uses good old fashioned C vs. Forth which is used in OpenBoot, which opens up a whole new world of possibilities – the old story, how many people know C vs. Forth?
UEFI is a completely openstandard and there is already code made available under the BSD licence as to ecourage the adoption of it.
Personally, I would also like to see SUN adopt it as a replacement for their firmware – why not? SPARC processor, UEFI/EFI Firmware – it would also finally allow people to upgrade their components without worrying whether they’re OpenFirmware compatible – it would also allow SUN to lower their costs as they could source more parts from more vendors.
the bsd code is built onto a black box binary only package – so you get the frontend, but you still don’t know what the hardware is actually doing.
as for c vs. forth, codegen has this nice c-to-forth compiler.. ugly code, but it works well enough – and it’s still 100% portable across ISAs.. are EFI’s binaries?
and as for standards, EFI is about 3000 pages, openfirmware is 300 – what’s easier to implement?
there are three reasons intel didn’t go for OF:
1. NIH syndrome
2. “protecting the affiliated vendors (ie. phoenix/award) from an established market”
3. keep acpi alive (that ugly beast could have been avoided altogether had they moved to OF earlier)
1) It doesn’t get compiled into native code, its compiled into this weird intermediate language – you’ll need to look into further; that was my first question when I heard C being used, I thought, “isn’t that going to string the thing to a particular ISA?”, apparently they’ve worked around the issue.
As for the reasons, OpenBoot was considered, but it had limitations – why use something that has problems when you can learn about the good things, hiff out the bad things and come out with something that be is better over all?
1) It doesn’t get compiled into native code, its compiled into this weird intermediate language
Cool! Funny how the news items on EFI don’t seem to mention such an important detail. Perhaps Intel is concerned that people will reject EFI because of the performance implications of interpreted bytecode compared to assembler-hacked BIOS.
Hmm, not too sure why they have – because when I read up about it, apparently there are a whole heap of things to consider with it, which the performance pentalty is apparently very small to non-existant.
Alot of people see Java and think, “ah, so thats what bytecode performance is like’ when in reality, they’re simply basing on the GUI responsiness where as in the case of firmware drivers, its all going to be low level, no gui, very stripped down and basic.
I had a look at the Spec; the bytecode stuff appears to be a bit of an afterthought and while it’s compulsory for the EFI implementation, it’s optional for devices.
Drivers are basically fat binaries with any of bytecode, IA32, IA64 and other processor’s code alongside each other.
While I’d expect Intel to provide the bytecode for their stuff, I suspect the majority of hardware vendors will only put the IA32 code in their devices because it saves a bit of space and they can’t be bothered to maintain anything else.
As for performance: interpreted bytecode will certainly be a lot slower to execute as I don’t think they’d use JIT compiling in the firmware. But I guess it doesn’t really impact performance because it’s not a lot of code and OSs come with their own drivers anyway.
it would also finally allow people to upgrade their components without worrying whether they’re OpenFirmware compatible
No, only for the Opteron machines. Since they’re written in C, EFI firmware would still need to be specially compiled for other processors. OpenFirmware’s Forth on the other hand is compiled into bytecode that can run on any processor.
what i would like to know more about is the advantages it has over something like open firmware
If UEFI EEPROM’s are of greater capacity than the current 256 kilobyte BIOS EEPROMS, than it might mean we can safely kick all vendor supplied firmware of the board and flash it with fully featured Linuxbios or an equivalent.
@Thom.
We know that BIOS is proprietary. Good thing is that BIOS is severely hampered by size limits, so it is fairly harmless and can be treated like circuitry (not much room for corporate spyware in there). Updating it is always dependant on user interaction, so it doesn’t have a very large impact.
I hope it will come with a serial console and a serious way of choosing boot-drive, booting from network, etc.
I turned on a MicroVAX/3100 last month and it’s firmware had more functionality than today’s PC’s BIOS.
Yes. Evern seen the BIOS on an Alpha based system? You get a shell…
Only because Apple took the right path and used EFI in their new intel packed machines.
It is kind of sad that no one else has had the balls to implement it earlier.
Kudos Apple.
That’s because MSFt didn’t support it. Apple is always using and supporting up and coming tech, whereas wintel PC’s are 5-10 years behind them. Sure apple is just using EFI now. but they were using Open Firmware before. It’s what made Apple’s plug and play work reliably.
Let’s face a few facts bios were still limited to 15 irq slots. Sure modern hardware and software hacked around that but why should it have to?
That’s because MSFt didn’t support it. Apple is always using and supporting up and coming tech, whereas wintel PC’s are 5-10 years behind them. Sure apple is just using EFI now. but they were using Open Firmware before. It’s what made Apple’s plug and play work reliably.
Wrong. Apple’s adoption of EFI has nothing to do with this transition. It’s been in the works for years. Not only is MS one of UFI’s supporters, they are on the board of directors.
Apple is is just piggybacking off the fruits of the PC industry’s labor just as they did with PCI, AGP, IDE, USB, and other technologies.
Edited 2006-02-02 13:36
Sure apple is just using EFI now. but they were using Open Firmware before. It’s what made Apple’s plug and play work reliably.
I’ve read that claim several times, but I’ve never seen it substantiated. In what way does OS X use OF/EFI to aid in hardware detection/driver loading? (Above and beyond the role of a typical x86 BIOS, obviouslsy).
EFI has been around for quite a while, AFAIK it was introduced in Itanium servers (it may have appeared elsewhere before that, but thats where I first encountered it). Many servers in the last 1-2 years have been shipping with an EFI shell and BIOS compatability layer, Apple are by no means the first!
In what way does OS X use OF/EFI to aid in hardware detection/driver loading?
The MacOS boot code builds its device table directly from the OpenFirmware device tree. It uses the OF routines to parse the table, finding the device info and any embedded drivers. MacOS hasn’t done any of its own device probing since well before OSX. Although I haven’t looked at how MacOS handles EFI, I’d assume it was VERY similar.
and for EFI they sacrificed the (imho) superior openfirmware – bad apple..
Ten years ago, I was saying that devices should have their drivers in on-board ROMS. Imagine, I said, Plug in the mouse, printer, scanner, controller, or whatever; and it would be recognized and all needed drivers would be installed. Even if the drivers were updated by the manufacturer at least the base-line functions would be available. Imagine also, being able to use a mouse on the BIOS setup screen. Even better, think about OS independent drivers!
No, I don’t see this as the end of the world, maybe the start on a new one? Finally!
Imagine also, being able to use a mouse on the BIOS setup screen.
Actually, there were some BIOSes from Phoenix Technologies or American Megatrends (I can´t quite recall) that showed some windows with icons within them and that allowed one to use his/her rodent to operate the thing. The default color scheme was awful but it could be changed to something more bland or even black and white.
Last time I saw one of them was 09 years ago or so, but I won´t forget the shock when I saw the first one! 🙂
I’ve seen mouse driven Bios too, often on Compaq where there was a small partition on the Hard-drive for all this rubbish, of course as PCs were upgraded the partitions tended to get trashed meaning you couldn’t enter the “BIOS”, but heck at least you had mouse support! and running it around was fun why waiting for the Bios to boot up!
On the American Megatrends we had P75 and you could change the BIOS colour sceme to something like “Army” which was all tan and green, which I though was quite cute!
I saw and used those about ten yrs ago, on american Zenith Data Sys 486DX100 machines – mouse support, windows widgets, etc. AFAIR could not move windows, they had fixed positions and could not overlap. Functionwise it was usual BIOS, nothing special.
Ah! You mean autoconfig on the Amiga from the 1980`s!
How long before virtualization is added to UEFI? Will current OSs become applications?
OS: UEFI 3.0
Web Browser: Gentoo (with a Mozilla plug-in)
Wordprocessor: Windows (with an Office plug-in)
3D Game: Quake 7.3 (running directly on UEFI)
Here’s an interesting and detailed article on EFI:
http://www.kernelthread.com/publications/firmware/
Thank you for posting that link !.
It was a informative bit of reading.
Benefits
EFI aims to be a powerful and modular firmware that is readily extensible, even by (power) users. Some noteworthy aspects of EFI include:
* EFI is implementation agnostic.
* EFI does not require real mode.
* EFI runs in a flat memory model, with the entire address space being addressable.
* EFI is written in C. Therefore, it is both easy to write and portable.
* EFI does not place a restriction on the total size of option ROMs. EFI drivers can be loaded anywhere in the EFI address space.
* EFI aims to replace VGA over time with simple graphics primitives courtesy the Universal Graphics Adapter (UGA).
* EFI includes an optional shell that gives the user a lot of freedom and flexibility.
* The pre-boot environment provided by EFI has a BSD socket compatible network interface, with a port of the FreeBSD TCP/IPv4 protocol stack.
Edited 2006-02-02 18:45
this news comes out every 8 months or so for the past several yrs…. personally, i like bios and see no need to change or add to its functionality. and y would my OS need to hav any major comunication with bios after preboot?
personally, i like bios and see no need to change or add to its functionality.
Right, but you’re probably not one of the poor sods who has to maintain the mess and try to extend it whenever something new comes up.
y would my OS need to hav any major comunication with bios after preboot?
Power management? Pluggable devices? Performance monitoring?
And generic drivers in the firmware are nice as a fallback for any OSs that don’t have their own drivers for many devices.