Phoenix BIOS Developer Blog

UEFI 2.2 & UEFI Shell 2.0 Go Live!

UEFI 2.2 just went live today, with major updates in the networking & security sections.

UEFI Shell 2.0 also went live, significantly beefing up the shell for pre-OS applications.

Also, UEFI 2.1 got an update to revision 'd' with much needed errata in the HII sections.

Head on over to www.uefi.org/specs to download today.

UEFI PI 1.1 Highlights

The PI specification was created by UEFI to provide the underpinnings to a UEFI implementation. It is not required by the UEFI specification (that is, you can implement UEFI without reference to the PI), but it is useful for those of us who put together platform firmware on a regular basis.

PI 1.0 brought in the basics: how are things organized in the flash, how do pre-UEFI drivers get launched, how are services they produced and consumed and how are the hardware devices required for the UEFI boot/runtime services abstracted. 

PI 1.1 added explicit support for some other items which are mentioned but not standardized in the UEFI specification (PCI host buses, PCI hot plug, SMBIOS) and items which make platforms go, but don't aren't in UEFI (SMM, multi-processor support, S3 resume). 

• PCI Host Bus. PCI root bridges are discussed in section 13.1 of the UEFI 2.1 specification as part of "PCI Host Bus Controllers". But the PCI Bus driver and its interaction with the PCI Hos Bus Controller is outside the scope of that specification (see section 13.3.2.2). The PI 1.1 specification fills in that gap. This portion is very similar to the Framework specifications.
• PCI Hot Plug. Describes how hot plug controllers, including CardBus and ExpressCard, are initialized and supported when booting a UEFI system.  This portion is very similar to the Framework specifications.
• SMBIOS. While UEFI 2.1 described how to discover the SMBIOS table (see section 4.6), but not how it is created. Generally, UEFI drivers and applications are considered to be consumers of the table.  However, one or more PI drivers may install content into the SMBIOS table. This portion is different than the Framework specifications, which used the Data Hub facility instead.
• SMM. PI 1.1 introduces a new core interface specification for System Management Mode (SMM). It describes driver dispatch, event handling, memory allocation and protocol production/consumption for drivers executing in System Management RAM (SMRAM).  While similar in concept to the Framework specifications, it is substantially altered, including SMRAM management, X64 support and SMI source dispatcher architecture.
• Multi-Processor Support. Both DXE and SMM provide support for calling a function executing on a different processor core or thread.
• S3 Resume.  Returning to the operating system after the system has entered an S3 suspend state (memory preserved, hardware state lost) is always tricky. Many devices are restored by the operating system, but many motherboard devices require special attention. PI 1.1 introduces the boot script, which is a list of hardware-level commands to be replayed during a resume from S3. The commands are encoded as opcodes with optional data in the script. This section of the PI 1.1 specification is similar in concept to that found in the Framework specifications, but is altered to support additional operations as well as initialization dependencies.

The PI 1.1 specification brings the Platform Initialization specification a long way towards fully supporting a production UEFI system. There are still a few areas which need to be covered and these are under consideration for the PI 1.2 specification, I am sure.

Tim

UEFI Delivers PI 1.1 Specification

As found here, the PI 1.1 specification has been released, which enables the wider range of silicon support underneath a UEFI 2.1b firmware implementation. We'll focus on what's has changed in subsequent posts. Hmmm...wonder what's on tap for 1.2?

Graffiti in the UEFI 2.1b Specification

I was just informed today that I have become famous, since my name appears on page 1348 of the UEFI 2.1b specification. Errata has been submitted to limit the damage...

The exact text is: "(Rest assured, Tim, this example is not used in the actual syntax.)" This refers to some of the work we are doing with HII configuration response/request strings. Quite comforting, I assure you :-)

Tim

UEFI 2.1b has arrived

Just a quick note to say that the UEFI 2.1b specification (which includes errata through December) is now available at www.uefi.org/specs.

Tim

Microsoft Announces UEFI Support In Vista SP1

According to the list of features in Vista SP1 here, it now supports UEFI! In particular, it notes the ability to boot from UEFI, the ability to network boot from UEFI and the ability to manipulate GPT (Guided Partition Table) partitions with the various partition tools. Here are the particular snippest of interest:

• Adds support for new UEFI (Unified Extensible Firmware Interface) industry standard PC firmware for 64-bit systems with functional parity with legacy BIOS firmware, which allows Windows Vista SP1 to install to GPT format disks, boot and resume from hibernate using UEFI firmware.   
• Adds support for x64 EFI network boot. 
• Adds support for creating a single DVD media that boots on PCs with either BIOS or EFI.

Just to keep this in perspective, this, along with the proposed Longhorn Server 2008 UEFI support and the GRUB support for UEFI, starts the gradual transition process.

Up until now, there have been a few other forces moving things towards UEFI. For example, silicon vendors only providing silicon support in the form of Framework or UEFI Platform Initialization drivers. These drivers essentially require the UEFI environment except for the boot loader. Also, with 2TB+ drives on the horizon, the GPT support will be needed, since the Master Boot Record (MBR) used by current OS loaders tops out at 2TB and no one seems inclined to try and patch it.

But now with widespread OS support for UEFI, the real transition begins. It still takes a while, since many manufacturing lines and support tools still depend on the MBR.

Tim

UEFI PI 1.0 + Errata Available

UEFI has released a version of the PI 1.0 specification, including all approved errata through October 29, 2007.  Go to  http://www.uefi.org/specs/ to download.

IDF Beijing

I was at IDF Beijing last week. Phoenix was a silver sponsor and had a slot on the 2nd day called "The Bridge To UEFI" which described three trends brought about by UEFI and how SecureCore was poised to help folks make the transition. The Beijing Convention Center was packed. One of the ladies organizing the show said there were over 6,550 track attendees and they had to turn some people away from the keynote addresses because it was so crowded. If the show grows anymore next year, that building won't hold it. Maybe the new 2008 Olympic Stadium next door could be used for the keynote?

UEFI was again featured prominently, with a full track on the second day. Presentations by Lenovo and Intel were highlights. Intel focused more on the new specifications themselves and what you could do with them. This marks a shift from previous IDFs and means that enough people in the industry are already convinced about UEFI, so Intel can go back to using UEFI for products rather than convincing people to use UEFI at all. Certainly the number of questions during the sessions was encouraging.

Some people expressed disappointment with my speaking session. The IDF guide stated I would be presenting in Mandarin, but I only used English... Maybe next IDF.

Tim

Apple Presents At UEFI EBC Summit 2007

Back in high school, I studiously avoided taking the Pascal class. At the time, I was a true AppleSoft BASIC and 6502 assembly-language hacker. But one of the items that always fascinated me was that the Apple Pascal compiler.  The compiler didn't generate "real" code. It generated p-code. That p-code was, in fact, a stack-based assembly language, but not for any real CPU. Instead, an interpreter processed the p-code. Which made it hard to do anything useful except write high school computer homework assignments.

Fast forward to 2007, Apple is back presenting (along with me and several Intel folks) about another type of p-code: EBC. EBC (EFI Byte Code) is a pseudo-assembly language which is designed to execute correctly on either 32-bit or 64-bit machines without modification. It is designed to operate seamlessly with other UEFI drivers written, even if they're not in EBC. The goal was that you could take your native UEFI driver and recompile it to work in EBC without modifications.

This sounds great. But have you considered what happens when the size of a struct can change based on the size of VOID *? Your sizeof() operator no longer generates a constant value. Instead, it is more like a function. How do you initialize that structure? You can't do it at build time because the offsets of the members may vary depend on the size of your INT.

So this event got everyone together: motherboard folks, BIOS vendors, plug-in card vendors and compiler writers, in one big room, threw in some pizza, and tried to get everyone to play nice with each other. The two server systems in the room provided sufficient white noise to mask the hubbub of folks talking about compiler issues, driver issues and BIOS issues. It was certainly nice to see a number of high quality 3rd party UEFI drivers in the room.

Dong Wei, the chair of the UEFI Test Working Group, pointed out that our next p-code problem will probably be the user-interface forms language (IFR) in UEFI 2.1. Yet-Another-P-Code. Sounds like the topic for another summit.

Tim

UEFI 2.1 Specification Available

Just recently announced, you can find the UEFI 2.1 specification here. Major updates include a standard user-interface infrastructure and secured global variables (have to mention those since I worked on them).

Tim