Re: How to tell whether a new computer uses EFI or BIOS?

Mark Conrad wrote:

..., to answer your question directly, I _think_ I need EFI capability for a complex reason.
1) I use a real PC as a sort of test bed, namely to run Vista and Vista app's BEFORE I install them on my Mac.


Well, my direct answer to your question is that I don't know how to tell
if a new computer uses EFI or BIOS, but at the present time you will *not* be booting an EFI computer with Vista. From earlier findings we know that many if not most new run of the mill motherboards are EFI ready. In the context of Microsoft newsgroups, and speaking of Microsoft operating systems, if you are not booting Server 2003 Enterprise Itanium or Server 2003 Datacenter Itanium you are not booting an EFI computer.

As mentioned earlier, EFI was initially developed by Intel Corporation
and published in the EFI 1.0 specification. EFI has been used as the
only supported firmware on Intel Itanium-based systems. As of early
2007, Itanium is supported by Windows Server 2003, multiple
distributions of Linux (including Debian, Red Hat and Novell SuSE,) and
HP-UX, OpenVMS, and NonStop from HP, all natively.

Intel sums up EFI and BIOS as follows:

[Quote, Intel]

The main purpose of Extensible Firmware Interface (EFI) is to abstract
the firmware and hardware layers from the operating system layer so that
the operating system vendors and developers do not have to battle with
the cumbersome 16-bit real-mode BIOS interfaces and constantly changing
hardware configurations. This interface became even more important when
the 64-bit CPU architecture was revealed because the legacy BIOS, which
is tightly coupled with the 32-bit CPU technology, could no longer work
for it. That is why EFI was first introduced in the 64-bit Itanium
architecture.

There has been rapid evolution of the personal computer platform since
the 1980s. These advances have included orderof-magnitude increases in
performance, ease-of-use, storage capacity, and connectivity. But there
is one element of the PC that has not changed for the past 23 years,
namely the BIOS (basic input/output system).

The task of boot firmware (whether the BIOS or firmware based on the
Framework) is to make a collection of hardware before the boot look like
a complete system after the boot.

To begin, let’s review the role of the BIOS in today’s system. The BIOS
is stored in some nonvolatile storage on the platform and commences
execution upon restart of the system. The BIOS is responsible for the
initialization of the system. This is typically referred to as power-on
self test (POST).

The POST for BIOS is typically written in some monolithic, statically
linked 16-bit, real-mode assembly language and relegated to a small
region of code space for execution. The assembly language construction
and lack of consistent system services, such as a modern memory manager,
coupled with the restricted execution space, impedes algorithm and
feature development.

Beyond POST, there is the operating system (OS) invocation and ability
to provide services to the OS. Herein, the operating system services are provided by 16-bit software interrupts. These software interrupts
include Interrupt 13h for access to the Disk, Interrupt 10h for access
to the Video, and Interrupt 16h for access to the Keyboard. Operating
system loads rely on the existence of these services. The limitations of these BIOS services include difficulty in extending new services,
limited parameter passing through registers, and restrictions of
real-mode. The Extensible Firmware Interface provides an opportunity to
have a common operating system loader across different platform
architectures, such as IA32 and Intel® Itanium® processor-based
platforms. Today’s legacy OS loader is relegated to the IA32 PC world.

[end Intel quote]

The Unified EFI committee is the industry group that is now responsible
for developing, managing and promoting the ongoing evolution of the UEFI
specification. One of the implementation criteria of UEFI is that it be
specific to the bits of the operating system, that is that 32-bit UEFI
be capable of booting 32-bit operating systems only and that 64-bit UEFI
be capable of booting 64-bit operating systems only. This important
implementation criteria is responsible for certain decisions made by
Microsoft with regards to UEFI and its operating systems.

[Quote, Microsoft]

The UEFI committee decided that UEFI firmware and the operating system
must match bit-wise; that is, the maximum number of address bits used by
the operating system must match the maximum number of address bits used
by firmware. For example, 32-bit UEFI implementations have the ability
to boot 32-bit operating systems, but not 64-bit operating systems.
Likewise, a 64-bit UEFI firmware implementation has the ability to
natively boot a 64-bit operating system, but does not support natively
booting a 32-bit operating system. This restriction was reached for
technical reasons related to runtime UEFI support. The UEFI
specification also allows firmware vendors to add flexible support for
booting operating systems that are designed to boot on traditional BIOS.
For this, the UEFI vendor will integrate a firmware interface layer that performs the compatibility functionality while presenting the BIOS-type interface to an operating system that expects BIOS-type interfaces to boot.

Thus, any UEFI implementation can be written to provide boot support for
native 32-bit, native 64-bit, and legacy BIOS-based operating systems.
However, supporting all three of these options requires a very large
firmware image which would not fit on a traditional PROM, adding to the
cost of the bill of materials (BOM). This also adds to the validation
costs for a platform, which in turn adds to the non-recoverable
engineering (NRE) cost for the system manufacturer. However, it is
practical to support both a native UEFI firmware implementation along
with the BIOS firmware interface layer.

Microsoft expects that most UEFI platforms in the near future will
choose native 64 bit support along with a BIOS compatibility module so
that these platforms can run earlier versions of Windows that support
boot only through a BIOS. Nearly all new processors in the Windows Vista timeframe will be 64-bit capable. Microsoft would like to use the advent of mainstream 64-bit computing as a transition point to enable a move toward EFI boot. Although a platform vendor could choose to have UEFI 32-bit support, this has a short life and diminishing returns. In the near future, OEMs won't need large, multipurpose firmware images.

Given the advent of mainstream 64-bit computing and the platform costs
previously discussed, Microsoft determined that vendors would not have
any interest in producing native UEFI 32-bit firmware. Microsoft has
therefore chosen to not ship support for 32-bit UEFI implementations.

Windows 2003 Server supports EFI 1.10 on Intel Itanium platforms.
Microsoft Windows Server codename "Longhorn" supports EFI 1.10 on Intel
Itanium platforms, and also introduces support for native UEFI boot on
x64 64-bit platforms. Although the initial release of Windows Vista will not include UEFI x64 64-bit support, a subsequent Windows Vista release will support UEFI.

[end Microsoft quote]

So there you go, at the present time unless you have an Itanium computer
you are not booting an EFI computer using any Microsoft operating
systems. If you are using a 32-bit computer you will never boot using
EFI with any Microsoft operating system. If you think you need an
Itanium computer then the following from Wikipedia will be of interest:

"As of 2007, several manufacturers offer Itanium 2 based systems,
including HP, SGI, NEC, Fujitsu, Unisys, Hitachi, and Groupe Bull. In
addition, Intel offers a chassis[20] that can be used by system
integrators to build Itanium systems. HP, the only one of the industry's top four server manufacturers to offer Itanium-based systems today, manufactures at least 80% of all Itanium 2 systems. HP sold 7200 systems in the first quarter of 2006.[21] The bulk of the sales are of
enterprise servers and machines for large-scale technical computing,
with an average selling price per system in excess of US $200,000. A
typical system uses eight or more Itanium processors."

Of course, the above information is in regards to Microsoft operating
systems. How other operating systems implement booting with EFI is an
other matter altogether. Intel Macs only support booting via EFI, and
Linux supports EFI.

John

Sources:
http://www.intel.com/technology/efi/
http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/itanium/optimization/43666.htm?page=1
http://www.intel.com/technology/magazine/systems/it01043.pdf
http://www.intel.com/technology/magazine/computing/dt05041.pdf
http://www.microsoft.com/whdc/system/platform/firmware/efibrief.mspx
http://www.intel.com/products/processor/itanium2/index.htm
http://www.intel.com/design/servers/platforms/SR9000MK4U/index.htm
http://en.wikipedia.org/wiki/Itanium
http://www.microsoft.com/technet/windowsserver/evaluate/features/compare.mspx
Windows XP 64 does not support IA64
http://download.microsoft.com/download/B/8/6/B868C664-13FC-4F91-9651-5B6D4F1A2F60/Is_Windows_XP_Professional_x64_Edition_Right_for_Me.doc



It appears that almost any run of the mill Intel board is EFI capable

However, having an EFI capable board and actually using
it is another matter.

Why do you *absolutely* need this?


Gadd, wish you had not asked that. My answer will get me banned from this NG permanently, if I am any judge of human nature.

Oh well, it was short and sweet here.

FWIW, already I have been banned from Mac NGs, because they are totally against any mention of Windows operating systems there.

I made the mistake of letting slip that I was running Vista Ultimate on my MacBook Pro hardware, and was very happy about how Vista ran on my Mac. Especially happy running my $900 Dragon Pro software, because there is nothing close to it in Mac software.

All hell broke loose in that Mac NG, I was damn near tarred and feathered.


Anyhow, to answer your question directly, I _think_ I need EFI capability for a complex reason.


Warning, Long Winded Reason coming up, Do Not Read the
Following Under Any Circumstances, It will Render You Blind.
***********************************************************
***********************************************************

1) I use a real PC as a sort of test bed, namely to run Vista and Vista app's BEFORE I install them on my Mac.

2) Running a Vista app' called KillDisk, I found I did not
have enough smarts to get it to run. Wanted to use it to wipe free space on my Mac's Vista partition, without it zapping any regular Vista files. The creator of that Vista util' specifically claims that his version 5.0 can do that wiping task, in his website at:

<http://www.killdisk.com/>

3) Could not get KillDisk to run on real PC hardware, despite
all efforts phoning the KillDisk people. PC nerds, geeks, in the shop that built up my ASUS PC could not get KillDisk
to work, left the PC and KillDisk DVD with them, told them I would pay them $1,000,000,000 or a very large free meal at any drive up window of their choice. So far no word from them about success or failure.

I told them of my suspicions, namely that Killdisk itself might have some sort of weird EFI compatibility problem.

Refuse to stick Vista KillDisk in my Mac until I can get it running on real PC hardware!


Oh yeah, almost forgot, reason I want to run KillDisk is to wipe free space in the Vista partition, so that my zip compression util' can make a smaller compressed backup of my Vista partition.

*********************************************************
*********************************************************
End of Long Winded Tirade -

Don't blame me if you go blind from reading it.


<sob> Now I am about to be banned from Windows NGs also.

Mark-

.