[Beowulf] UEFI (Unified Extensible Firmware Interface) for the BIOS

[Andrew Shewmaker]

On Thu, Nov 12, 2009 at 5:47 PM, Rahul Nabar <rpnabar at gmail.com> wrote:
> Has anyone tried out UEFI (Unified Extensible Firmware Interface) in
> the BIOS? The new servers I am buying come with this option in the
> BIOS. Out of curiosity I googled it up.
>
> I am not sure if there were any HPC implications of this and wanted to
> double check before I switched to this from my conventional
> plain-vanilla BIOS. Any sort of "industry standard" always sounds good
> but I thought it safer to check on the group first....
>
> Any advice or pitfalls?

Here's something on EFI I wrote up for myself in 2005.  It's a bit out
of date, but it covers some stuff that wikipedia doesn't.  In
particular, I would read the old Kernel Traffic to understand how
various developers dislike EFI.

And in case you are wondering, this post looks a bit different because
it is in moinmoin wiki markup.

== Firmware Awareness ==

You may have heard of Intel's EFI, but have wondered how does it
compare to legacy BIOSes, Open Firmware, and LinuxBIOS.  Here's some
stuff you might want to be aware of.

=== Acronyms ===

ACPI - Advanced Configuration and Power Interface

EBC - EFI Byte Code

EFI - Extensible Firmware Interface

UEFI Forum - The Unified EFI Forum is a group of companies (all of the
big PC players) responsible for the devolopment and promotion of EFI

LinuxBIOS - small, fast open source alternative to proprietary PC BIOSes

OpenBIOS - open source Open Firmware implementation

Open Firmware - defined by IEEE-1275 and used by Sun Microsystems
(since 1988), IBM, and Apple to initialize hardware and boot Operating
Systems in a largely hardware-independent manner

=== UEFI Forum ===

The UEFI Forum just announced its existence, and it looks like Intel
has convinced the major PC vendors and their rival AMD to adopt EFI as
a replacement for legacy BIOSes.  It looks like we will be seeing EFI
everywhere.

=== Overview of EFI ===

[UEFI]


Q:	Does UEFI completely replace a PC BIOS?
A:	No. While UEFI uses a different interface for boot services and
runtime services, some platform firmware must perform the functions
BIOS uses for system configuration (a.k.a. Power On Self Test or POST)
and Setup. UEFI does not specify how POST & Setup are implemented.
 	
Q:	How is UEFI implemented on a computer system?
A:	UEFI is an interface. It can be implemented on top of a traditional
BIOS (in which case it supplants the traditional INT entry points into
BIOS) or on top of non-BIOS implementations.


[Singh]


In a representative EFI system, a thin Pre-EFI Initialization Layer
(PEI) might do most of the POST-related work that is traditionally
done by the BIOS POST. This includes things like chipset
initialization, memory initialization, bus enumeration, etc. EFI
prepares a Driver Execution Environment (DXE) to provide generic
platform functions that EFI drivers may use. The drivers themselves
provide specific platform capabilities and customizations.


...


Andrew Fish invented EFI at his desk in the late 1990s, calling it
Intel Boot Initiative (IBI) at that time. He offered his 26 page
unsolicited white paper to his management. The paper was meant to be a
response to major operating system and hardware companies rejecting
legacy BIOS as the firmware for enterprise class Itanium® Processor
Platforms.

Andrew says:

"At that time, two firmware solutions were put on the table as
replacements for BIOS architectures for the Itanium: Alpha Reference
Console (ARC) and Open Firmware. It turned out that nobody really
owned the inellectual property to ARC, and in any case, it did not
have enough extensible properties to make it practical for a
horizontal industry. At this point, Open Firmware became the
frontrunner as Apple and Sun both used it. However, Open Firmware was
not without its own technical challenges. The PC had started down a
path of using the Advanced Configuration and Power Interface (ACPI) as
its runtime namespace to describe the platform to the operating
system. As I liked to say at the time, the only thing worse than one
namespace is keeping two namespaces in sync. The other problem was the
lack of third party support for Open Firmware. We invited the
FirmWorks guys to come visit us at Dupont (WA), and we had a great
talk. Given we had just gone through an exercise of inventing a
firmware base from scratch, I think we were uniquely qualified to
appreciate what Open Firmware had been able to achieve. Unfortunately,
it became clear that the infrastructure to support a transition to
Open Firmware did not exist. Given the namespace issue with Open
Firmware and the lack of industry enabling infrastructure, we decided
to go on and make EFI a reality."

"EFI is an interface specification and it really is more about how to
write an operating system loader and an Option ROM than it is about
how to make a BIOS that works. The Intel® Platform Innovation
Framework for EFI (Framework for short) is Intel's next generation
firmware architecture from the ground up. The core chunks of this code
are available under an Open Source license at www.TianoCore.org. Tiano
was the developer code name while Framework was the marketing name."

"To sum up, EFI is an industry interface specification that defines
how OS loaders and PCI Option ROMs work. The Framework defines a new
modular architecture that allows an entire firmware base to be
constructed in a modular fashion. The Framework has a nice property in
that it allows binary modules to work together in the boot process.
This allows the code from each vendor to have an arbitrary license
type. Intel® was interested in EFI from making a standard Itanium
platform (as well as IA-32 platforms of the future) to drive adoption
and enable a horizontal industry to make compatible platforms. The
Framework is more about silicon enabling, so it drills down to a much
lower level of how things work."


Fish says that PCs had already started down the path of ACPI and that
the Open Firmware namespace was incompatible.  Evidently when ACPI was
developed, the already existent Open Firmware specification/namespace
was ignored.

[Intel]

1992 APM 1.0
1993 APM 1.1, APM Energy Star
1994
1995 PCI Mobile Design Guide 1.1, PCI 2.1
1996 APM 1.2
1997 ACPI 1.0, PCI PM 1.0
1998 PCI 2.2
1999 ACPI 1.0b
2000 ACPI 2.0

                               Figure 2.1 PC Power Management
Specification Timeline



=== Linus Torvalds comments on EFI ===

Linus Torvalds.  [Brown]


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. The fact that Intel forgot about that with ia-64
is not an excuse to make _more_ mistakes.


=== Intel's Reply to Linus ===

Mark Doran of Intel.  [Brown]


The trouble with the "architectural hardware" argument proved to be
that PCI is already well established and there is a vibrant industry
churning out innovative PCI cards on a regular basis. The idea of a
single interface definition for all cards of each of the network,
storage or video classes is viewed as simply too limiting and the
argument was made to us that to force such a model would be to stifle
innovation in peripherals. So effectively the feedback we got on
"architectural hardware" was therefore along the lines of "good idea
but not practical..."

...

As a practical matter carrying multiple instruction set versions of
the same code gets expensive in FLASH memory terms. Consider an EFI
compiled driver for IA-32 as the index, size: one unit. With code size
expansion, an Itanium compiled driver is going to be three to four
times that size. Total ROM container requirement: one unit for the
legacy ROM image plus one for an EFI IA-32 driver plus three to four
units for an Itanium compiled driver image; to make the card "just
work" when you plug it into a variety of systems is starting to
require a lot of FLASH on the card. More than the IHVs were willing to
countenance in most cases for cost reasons.

EFI Byte Code was born of this challenge. Its goals are pretty
straightforward: architecture neutral image, small foot print in the
add-in card ROM container and of course small footprint in the
motherboard which will have to carry an interpreter. We also insisted
that the C source for a driver should be the same regardless of
whether you build it for a native machine instruction set or EBC.

...

You may ask why we didn't just use an existing definition as opposed
to making a new one. We did actually spend quite a bit of time on that
very question. Most alternatives would have significantly swelled the
ROM container size requirement or the motherboard support overhead
requirement or had licensing, IP or other impediments to deployment
into the wider industry that we had no practical means to resolve.
With specific reference to why we chose not to use the IA-32
instruction set for this purpose, it was all about the size of an
interpreter for that instruction set. To provide compatibility 100%
for the universe of real mode option ROM binaries out there would
require a comprehensive treatment of a very rich instruction set
architecture. We could see no practical way to persuade OEMs building
systems using processors other than IA-32 to carry along that much
interpreter code in their motherboard ROM.

...

... EBC requires a small interpreter with no libraries (roughly 18k
uncompressed total on IA-32 for example) and the average add-in card
ROM image size is 1.5 units relative to native IA-32 code. And keep in
mind that using byte code for this purpose is in widespread, long time
use on other CPU architectures so we felt the technique in general was
viable based on industry experience with it. Yes, it's a compromise
but the best balance point we have been able find to date.

...

There is nothing about the definition of the EFI spec or the driver
model associated that prevents vendors from making add-in card drivers
and presenting them in Open Source form to the community. In fact
we've specifically included the ability to "late bind" a driver into a
system that speaks EFI. In practice that late binding means that code
that uses EFI services and that is GPL code can be used on systems
that also include EFI code that is not open source.

The decision on whether to make any given driver Open Source or not
therefore lies with the creator of that code. In the case of ROM
content for an add-in card that will usually be the IHV that makes the
card.

...

The patent license grant is thus in some sense a double coverage
approach...you don't really need a patent license grant since there
aren't any patents that read but to reinforce that you don't need to
worry about patents we give you the grant anyway. This helped make
some corporate entities more comfortable about implementing support
for EFI.


=== Comparing EBC to x86 bytecode ===

However, the EBC interpreter isn't that much smaller than an x86
emulator.  Add in the fact that x86 bytecode generation is much more
common and proven, and it looks like EBC isn't as big a win as Intel
believes.

[Lo]


In this paper we present our preliminary results on FreeVGA, an x86
emulator based on x86emu that can be used as such a compatibility
layer. We will show how we have successfully used FreeVGA to
initialize VGA cards from both ATI and Nvidia on a Tyan S2885
platform.

...

Integrating FreeVGA into LinuxBIOS had virtually no impact on the size
of the resulting ROM image. The compressed ROM image only increased by
16KB, but because the final ROM image is padded to the nearest power
of 2, this increase was absorbed into the existing unused space. The
runtime size of the uncompressed image was only increased by 40KB.


=== LinuxBIOS ===

Since EFI doesn't deal with POST or setup, it could actually sit on
top of something like LinuxBIOS.  In fact, the OpenBIOS project is
already planning on putting their Open Firmware on top of LinuxBIOS.
Certainly, if LinuxBIOS can use an x86 emulator, it can use a Forth or
EBC interpreter.

Interestingly, EFI might be a good way to have more vendors use
LinuxBIOS in their products.  How much can vendors differentiate
themselves in POST and Setup?  Probably not much.  They will want to
differentiate themselves in what they put on top of the abstraction
layer.  If that is the case, then it would be in everyone's best
interest to adopt LinuxBIOS for the boring, unprofitable POST and
Setup for cost sharing reasons.

The romcc compiler developed for the LinuxBIOS project is another good
reason to use it because it reduces the amount of assembly code needed
to initialize a machine.

[Minnich]


In 2002, Eric Biederman of Linux NetworX developed a compiler called
romcc. romcc is a simple optimizing C compiler-one file, 25,043 lines
of code-that uses only registers, not memory. The compiler can use
extended register sets such as MMX, SSI or 3DNOW. romcc allowed us to
junk almost all of the assembly code in LinuxBIOS, so that even the
earliest code, run with no working DRAM, can be written in C.

romcc is used only for early, pre-memory code. For code that runs
after memory comes up, we use GCC.


=== References ===

Brown, Zack Kernel Traffic #231 For 10 Sep 2003.
http://web.archive.org/web/20030926022111/http://www.kerneltraffic.org/kernel-traffic/kt20030910_231.html#7

Intel.  Power Management History and Motivation.
http://www.intel.com/intelpress/samples/ppm_chapter.pdf

Lo, Li-Ta; Watson, Gregory R.; Minnich, Ronald G.  FreeVGA:
Architecture Independent Video Graphics Initialization for LinuxBIOS.
http://www.linuxbios.org/data/vgabios/

Minnich, Ronald G.  Porting LinuxBIOS to the AMD SC520.
http://www.linuxjournal.com/article/8120

Singh, Amit.  More Power to Firmware.
http://kernelthread.com/publications/firmware/

UEFI.  About UEFI.  http://www.uefi.org/about.asp

-- 
Andrew Shewmaker