Slashdot Mirror
Writing an End to the Bio of BIOS?
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."
I wonder if this new BIOS replacement will be designed based on the assumption that everybody is running the most current version of Windows.
One thing I've always hated about the standard PC BIOS is that you need a keyboard, video and mouse (kvm) to configure the thing.
It'd be great if EFI initialised a serial console if detected that there was no KVM attached to the system. It'd be great for custom-made PC routers and servers on generic hardware running Linux or xBSD.
OpenFirmware is older than the hills, well tested, loved by all, and used on just about every machine EXCEPT Intel. Is anyone getting a sense of NIH syndrome?
Javascript + Nintendo DSi = DSiCade
The excuse "WEll, current BIOS systems is just patch written upon patch written upon patch. ITs a mess."
But it works. Is an EFI system going to be markedly faster? When you tell me you are loading device drivers at the BIOS level, that tells me "No"- you are creeping the OS lower.
So whats the deal?
from Intel's EFI web site: Together, these provide a standard environment for booting an operating system and running pre-boot applications.
AHhhh! Running PRE-BOOT operations! This sounds like a lame way to shoe-horn in DRM or something similar onto my machine before it loads up.
Maybe I'm acting paranoid, but the slowest thing on my windows computer is WINDOWS, not the bios- that runs pretty fast.
In the future, I would want to not be isolated from my friends in the Space Station.
There's been lots of worry about this sort of thing, given MS busines practices in the past.
Freedom is a hard concept for some folks to deal with
I hope that this turns into a financial disaster for them.
"It is a greater offense to steal men's labor, than their clothes"
I noticed that the first PC to use EFI was a Gateway "Media Center" desktop. For those who do not know, Media Center is Microsoft's first attempt at highly integration of DRM (Digital Rights Management) into the core functionality of the OS. Knowing the agenda for Palladiam and so called "Trusted Computing" (Who do you trust today?) I would really think twice before letting the likes of Microsoft and Intel (remember the P4 CPU ID?) rewrite my PC at the BIOS level.
The "competition" between Pheonix BIOS and EFI could be the beginning of the split between closed platform "Trusted" PC's and open platform PC's. I would not be surprised if EFI has provisions (at some future point) to require the OS is signed. That rules out Linux, BSD, etc.
Naturally they are doing all this for our best interests.
"Anything is possible with enough programmers, time and pizza." (Substitute caffeine for time as needed.)
The original PC BIOS has incredibly remained basically unchanged since the days of the IBM PC, more than twenty years ago. We have all that legacy stuff in our PC's firmware that harks back to the days of MS-DOS and its limitations are being stretched to the breaking point by hacks and kluges (e.g. the disk size limits imposed by the real-mode BIOS calls). It would be nice to see it all go away for good.
On the other hand, it's Microsoft and Intel working together on this. This could very well be the next step towards the groundwork for Palladium, and more ugly DRM embedded into the lowest levels of PC hardware, that may well prevent anyone from running any operating system on commodity PC hardware besides that of Microsoft, among other baneful things. I'm not willing to bet that this new specification doesn't lay this type of groundwork in any way.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
EFI sucks. Even Linus says so.
:wq
Take ACPI, for example. If you take out the P of ACPI, and stick to the configuration features, you end up with something very similar to (some parts of) OF. A device name tree? OF has it. An intermediate language for device initialization? OF has it.
OF has only one difference to ACPI: OF works. Devices are made with valid machine-language drivers, so that the OS doesn't have to patch it upon boot, etc, etc, etc. Don't take me wrong, I really believed that ACPI would be great, but when people started implementing it, we saw what mess it became. It was one of the reasons I moved away of the x86 platform. It is just a bunch of hacks.
So why Intel created ACPI? Because while ACPI is also "open", Intel can control it. And Intel knows that while it keeps the power of defining standards, it will be the leading chip manufacturer: it helps to keep it top of mind in terms of consumer ICs.
For those who don't know what OF is, take a look at this.
This stuff runs essentially the same as it did in the 80s. Sure, it uses more memory, bigger hard drives, etc, but its all just built from the same thing. Which leads into #2-
The solutions which were created to deal with things (such as the BIOS) were only intended, by their creators, to be temporary solutions until somebody designed something better. However, the IBM PC became a standard, and everything since then been built upon that foundation.
So, for the first time in decades, people are looking at the PC and trying to make it better. Why cant we have computers which boot up in seconds, rather than minutes? Why cant we have power saving which actually works? Those features, and many more, will only be possible with a redesign. The old way of doing things carries too much baggage.
Its sad, because I had always thought computer people always look for the best way to do things. Unfortunately, computer people are just like everyone else, and all too willing to accept the status quo.
Manipulate the moderator system! Mod someone as "overrated" today.
If you run ia64 (all 5 of us :) ) you already run EFI. For some of you out there who may not have actually seen EFI in action, I'd thought I provide some small examples of what it looks like.
EFI does a running check of the hardware that it understands, drivers for which were provided by the Motherboard maker.
Here's a snapshot of the EFI SCAN on my INTEL Tiger4 system.:
EFI version 1.10 [14.61] Build flags: EFI64 Running on Intel(R) Itanium(R) 2 processor EFI_DEBUG
EFI IA-64 SDV/FDK (BIOS CallBacks) [Wed Jan 1 23:33:30 2003] - INTEL
Cache Enabled. This image MainEntry is at address 000000007FA02000
Searching for EFI 1.1 SCSI driver....
Scsi(Pun0,Lun0) MAXTOR ATLASU320_18_SCAB120 (320 MBytes/sec)
Scsi(Pun1,Lun0) MAXTOR ATLASU320_73_SCAB120 (320 MBytes/sec)
Scsi(Pun2,Lun0) MAXTOR ATLASU320_73_SCAB120 (320 MBytes/sec)
Scsi(Pun6,Lun0) ESG-SHV
Invoking PxeDhcp4 protocol to obtain IP address.
At the end of this, I get a menu that I can manually select from (cursor up and down), or let it automatically try the options(which can be modified to suit the user's needs). Here's a snapsnot:
EFI Boot Manager ver 1.10 [14.61]
Please select a boot option
Network Boot/Pci(1|0|0)/Mac(0007E9D8147A)
Linux
Floppy/Pci(1F|1)/Ata(Primary,Slave)
CD/DVD ROM/Pci(1F|1)/Ata(Primary,Master)
EFI Shell [Built-in]
Boot option maintenance menu
Use ^ and v to change option(s). Use Enter to select an option
As you can see, EFI has detected the network card, a bootable linux partition, the floppy (LS240 in this case), and the cdrom drive. Anything you can detect, you can boot off from.
The EFI shell option brings you into a shell. Once in the shell, you can easily switch to another filesystem by executing a changefilesystem command, similar to msdos:
fs1:
The shell prompt (for filesystem 0, which is the first filesystem EFI finds, whether its on a floppy, a cdrom, a harddrive, usb key, whatever)
fs0:\>
The shell looks like a dos shell, but runs commands that the motherboard manufacturer includes, such as "edit" "ls" "cat" "cp" "mount" and others. These commands live in ROM.
EFI understands the FAT32 filesystem and can perform operations on files living there including editing. EFI can access any FAT32 on any device EFI has a built-in driver for, and any device that the user can obtain an EFI driver for.
Another nice feature is that you can create a partition on the disk that efi will use to hold more commands, or updated commands, or drivers for newer hardware. These extra commands when then be available to you at boot time.
To the user, EFI looks almost like an built-in mini OS that understands enough of the hardware to give you several boot options, as well as the ability to manipulate files on the devices it sees.
I've seen no evidence of DRM support, or OS lock-in, but that certainly doesn't rule out the possibility. The thing is, EFI is enough of a standard that the user might have the possibility of replacing the stock EFI with some other version to meet their personal needs. This would certainly put us ahead of where we are with current vendor lockin on motherboard bios.
The Internet has no garbage collection
If the OS isn't using BIOS, this is actually safe, with two caveats:
1) The OS shouldn't be making BIOS calls. Last thing you want is to be in the middle of a hard drive write operation when you yank the chip. (This risk is negligible for modern OSes)
2) Use a proper PLCC extractor for the chip. Shorting out contacts or breaking the socket with a screwdriver is bad. Pulling the chip properly is safe. You're just cutting/restoring power to the voltage, ground, and signal leads of the chip within milliseconds of each other -- the same way you are every time you power the machine up or down.
For the record, yes, YMMV, but yes, I've done this, and yes, it worked. (I was an I-Opener h4x0r; this was an PC masquerading as an embedded system that lacked a floppy, and for which later versions of the BIOS wouldn't boot from a hard drive. The "hot flash" was needed under those circumstances - boot a machine with a hard drive and a "good" BIOS, remove "good" chip while system powered up. Insert "bad" BIOS chip extracted from a nonbootable unit into empty socket of powered-up "good" machine. Reflash "bad" BIOS chip with data extracted from "good" BIOS chip. Power down. Insert "good" chip into your machine. Insert reflashed chip into formerly-nonbootable machine.)
I wouldn't recommend it as standard procedure, but if you don't have an EPROM/EEPROM burner, hot-swapping BIOS chips between live machines is a viable field expedient.