Writing an End to the Bio of BIOS? 511
An anonymous reader writes "Intel and Microsoft are gearing up to move toward the first major overhaul of the innermost workings of the personal computer. The companies will begin promoting a technology specification called EFI (Extensible Firmware Interface) as a new system for starting up a PC's hardware before its operating system begins loading."
Re:OF? (Score:5, Informative)
Exactly. Because most of us are using UltraSparcs and other Unix machines that use OpenFirmware. Hello! McFly?!
Registration-free spec (Score:5, Informative)
The license isn't actually too bad - it just says that if you provide them feedback, then you also grant them the right to implement your idea.
Re:What about AMD and Sun? (Score:3, Informative)
Re:OF? (Score:1, Informative)
Re:can interact with EFI on a serial console? (Score:5, Informative)
I have some low-end NEC servers, and the BIOS (by default) comes configured to check for a console on serial port, and appear there, instead of the primary monitor.
And this has been around for quite a while.
Re:OF? (Score:4, Informative)
What's to stop all the actual OF members from either voting SCO down or ignoring their spec changes? Like it or not, SCO/Caldera *used* to be a reasonable company in the computing world. It should then come as no surprise that their on many technology standard boards. But when you consider the fact that they are probably the only OpenFirmware member that doesn't have an implementation (Their market is Intel after all), their ideas probably won't carry much weight.
Re:EFI drivers loaded at boot (Score:1, Informative)
This is _exactly_ what Linux needs. There would be an open standard for device drivers - any OS which supported the standard could use the firmware drivers instead of having to load its own. And this is exactly what the OS community needs. One of the major barriers to adoption of Linux is the fact that it doesn't have drivers for all of the hardware out there. If the drivers were loaded into the firmware, Linux could run on any PC, regardless of the hardware installed.
Sure, they could use DRM and kernel signing to prevent Linux from loading. But this capability has already existed for a long time now. IIRC, some of Compaq's old servers (about 8 years ago) came with an OS checksum in the BIOS - if it wasn't Compaq's version of NT, the BIOS wouldn't load it. Compaq has stopped this practice, as many of their customers got sick of being unable to migrate their servers to Win2k.
But I doubt it's as bad as it seems. Yes, they're going to _try_ to get DRM to take off. But nobody's going to buy it. To understand why, consider why the PC became so popular in the first place:
Open Standards.
Back in the 80's, Apple was a serious contender for the desktop. IBM released the PC specification for their BIOS; Apple did not. We all know how that went over. So either there will be an open standard for the new BIOS, or only the fringe players are going to adopt it.
Oh, and BTW, this is somewhat of a moot point. Almost all of the major manufacturers - Dell, HP, Compaq, Toshiba, etc... write their own BIOS. So even if this does become standardized with DRM, it still might not matter if none of the major manufacturers use it.
Even if it fails as a standard, the major PC makers may still implement DRM in the BIOS... silently. I've just bought a Toshiba laptop which can't take screenshots - I didn't know about it until after I bought it. DRM strikes again!
sounds like Open Firmware (Score:2, Informative)
http://www.openfirmware.org/
http://playground
http://developer.apple.com/technot
http://bananajr6000.apple.com/
Re:OF is based on Forth? (Score:3, Informative)
Wasn't Postscript good enough for them?
Do you have any idea WTF you're talking about? Postscript is a document display language. Forth is a general purpose, turing complete, mathematics language. Quite a difference there.
Besides, it's not like you actually have to be able to code Forth to use OpenFirmware. It's just a feature.
No wonder it's not hit mainstream.
That is, if you don't consider Apple, Sun, IBM, HP OR JUST ABOUT EVERY FREAKING COMPUTER MAKER OTHER THAN INTEL mainstream.
Re:OF? (Score:2, Informative)
Re:Coming: The Year of the Infected Bios (Score:4, Informative)
EFI IS CRAP!!! (Score:2, Informative)
Vendor-supplied drivers without source are going to be BUGGY.
They are going to be doubly buggy if they are run with a compiler that has a buggy back-end.
And that back-end is going to be buggy if it's for some random bytecode that isn't widely used except for some silly EFI thing and is tested exclusively with just a few versions of Windows and _maybe_ occasionally on Linux.
Face it: firmware bytecode is a total braindamage. The only thing that works is _source_code_ that can be fixed, and lacking that, we're better off with a well-defined ISA that people are used to and that has stable simple compilers.
In other words: x86 object code is a better choice than some random new bytecode. It's a "bytecode" too, after all. And it's one that is stable and runs fast on most hardware. But as long as it's some kind of binary (and byte code is binary, don't make any mistake about it), it's going to always be broken.
EFI is doing all the wrong things. Trying to fix BIOSes by being "more generic". It's going to be a total nightmare if you go down that path.
What will work is:
standard hardware interfaces. Instead of working on bytecode interpreters, make the f*cking hardware definition instead, and make it SANE and PUBLIC! So that we can write drivers that work, and that come with source so that we can fix them when somebody has buggy hardware.
DO NOT MAKE ANOTHER FRIGGING BYTECODE INTERPRETER!
Didn't Intel learn anything from past mistakes? ACPI was supposed to be "simple". Codswallop.
PCI works, because it had standard, and documented, hardware interfaces. The interfaces aren't well specified enough to write a PCI disk driver, of course, but they _are_ good enough to do discovery and a lot of things.
Intel _could_ make a "PCI disk controller interface definition", and it will work. The way USB does actually work, and UHCI was actually a fair standard, even if it left _way_ too much to software.
Source code. LinuxBIOS works today, and is a lot more flexible than EFI will _ever_ be.
Compatibility. Make hardware that works with old drivers and old BIOSes. This works, just like cmdrtaco works his love sausage into rob malda every evening. The fact that Intel forgot about that with ia-64 is not an excuse to make _more_ mistakes.
Don't screw this up. EFI is not going in the right direction.
Not true ! (Score:4, Informative)
Quite often I turn them both on at the same time and I can always log into Gnome around 30-40 seconds faster than I can log into Win2K.
Re:"Before loading your operating system" (Score:4, Informative)
Elements will reside completely in NVRAM. Not only will this allow for great enhancements to power consumption, it also eliminates the need for a BIOS.
Read the EFI specs (Score:2, Informative)
This has a good overview of what efi is and entails, as well as the specifications for it.
There are some good things about it - hardware drivers are easier to develop for it, it allows booting off of non-standard devices, and in some ways very similar to openFirmware. There is also linux support for efi (at least on IA64)
However, it has some serious drawbacks:
The potential is there to implement DRM, and attempt to "lock out" non-signed binaries, etc...
It requires a 100 Mb efi (FAT) partition (so it appears useless for diskless servers)
It appears to me at least that there are some potential serious security flaws to the implementation
Overall, EFI doesn't add anything that LinuxBIOS doesn't (except that EFI has been "blessed" by Microsoft), and it appears to be intel's way of locking in the BIOS market.
Re:Palladium and trusted computing (Score:4, Informative)
???
The DRM hooks may be present in XP Media Center Edition, but that doesn't mean you have to use them. I've been running the OS for weeks, and haven't even had to sign up for a Passport.
My HP Media Center PC even came with software to convert video files captured by MS'S PVR codec into free-and-clear MPEG's.
Re:Well if Microsoft's involved.... (Score:5, Informative)
- Necron69
Re:OF? (Score:3, Informative)
Re:EFI sucks (Score:2, Informative)
Re:Well if Microsoft's involved.... (Score:2, Informative)
Re:No progress for ANYBODY!!!! (Score:5, Informative)
Actually ... no (Score:2, Informative)
Re:Intel would never adopt OF (Score:5, Informative)
Nope, plug-in drivers [firmworks.com] on Open Firmware compatible cards are written in FCODE, which is a Forth bytecode language.
Completely machine independent.
The article says that Open Firmware was considered, but they didn't want to drop ACPI.
Frankly, Open Firmware has a lot of features you are just never going to see on home machines/cheap server boxes as long as Intel and MS are in charge. I'd rather have OF on my server boxes, hence why I chose a Sun machine.
XP hibernation (Score:2, Informative)