UEFI Releases New Specifications and Adds ARM to the Board

For anyone who has been working on the UEFI specification, for the past few years, it should be no surprise to hear that UEFI has decided to welcome ARM onto the board of directors. This shows the growth of interest in firmware standards by the non-x86 world and also recognizes ARM's outstanding level of effort to improving the specifications. Dong Wei, who was the vice president of UEFI while at HP, now returns to the same role but now from ARM, where he is the senior director platform architecture. This seems like a smart move on both sides.

This announcement came on the heels of the release of a spate of new spec and test tool revisions. There are a whole bunch of goodies in here, from wifi and BlueTooth to new SMM (now called MM) models (including TrustZone!).

• UEFI Spec v2.7  - http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf 
• PI v1.6 - http://www.uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf 
• ACPI v6.2 - http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf 
• SCT v2.5A - http://www.uefi.org/testtools

There are rumblings about another UEFI plugfest in the works. More on what's changes in the specs and other industry happenings later.

ARM, Servers and the Shrink-Wrap OS

ARM just released the Server Base Boot Requirements document (more info here) which "defines the ARMv8 platform firmware abstractions necessary for OS deployment and boot, HW configuration and management, and power control" for servers that follow their SBSA specification. This is an important step so that OS vendors, like Red Hat and Microsoft, can produce "standard" operating systems distributions that work on any SBBR-compliant system.

What do you need to boot? Well, first of all, the operating system needs to detect all of the undetectable devices on the platform without a lot of poking and probing. That's because the standard OS image can only support a limited number of interrupt controllers, CPU memory management schemes, and high-resolution timers. So its a good idea if everyone can agree on a standard hardware architecture for these devices or, if not, a standard abstraction for how to talk to them. You don't want to use kernel configuration files, because that requires that the OS image is not the "standard" OS image, but rather one which has been modified for a specific SoC or specific board. So SBBR recommends the new ACPI 5.1 specification. People may not remember this, but one of the things that ACPI does (the "Configuration" part of the acronym) is provide a way to describe the hardware resources (memory, I/O, IRQ, DMA, etc.) used by non-enumerable devices and providing an identifier that the OS can use to load a specific device. The ACPI 5.1 specification did a few tweaks to that basic model for new ARM devices, but the same ideas are still valid.

Next, the operating system needs to be able to talk to the boot device long enough for it to be able to get its own drivers loaded. It is a sort of contract where the firmware finds the OS loader, validates it, and then jumps into it. But that OS loader then needs to load other files. Now it can try to put everything into a massive super-loader that can handle every device known to man or woman, or it can ask the firmware to read those files. That's why SBBR recommends UEFI 2.4, because UEFI has a well-defined mechanism for handing off control to OS loaders, loading files and then cleanly handing over control of devices to an OS driver.

How does the OS find out more information about the platform? Manufacturer name? DIMM types? Platform UUID? SBBR recommends the SMBIOS specification, version 2.8.0, published by the DMTF , which "addresses how motherboard and system vendors present management information about their products in a standard format" (see DSP0134).

Finally, ARM CPU cores can be arranged in a bewildering array of topologies, with an amazing variety of power states, can be described by the PSCI interface (from ARM and ACPI). This interface allows the interface to manage the tricky business of manipulating individual cores and managing the dependencies between them.

All of these work together to support the shrink-wrap experience. The goal: one DVD or one OS image can boot the system enough to get to the net and download any other updated or missing pieces. So standards that provide the pieces so that I can get my system to that point based on the information built into the firmware make everyone's job easier.

UEFI Forum releases the ACPI 5.1 Specification

For years, the ACPI specification was developed by what was essentially a 5-way tangle of an IP agreement between Microsoft, Intel, Toshiba, Phoenix and HP. It was a closed group with no simple way for new ideas and direction from outside.

After ACPI 5.0 was released, it became clear that if ACPI were going to have wider industry adoption, it would need to open up to a different sort of development process. At the UEFI board meetings (when I was with Phoenix), I saw most of the same companies and most of the same people as with ACPI. After much discussion between companies with large contingents of lawyers, the UEFI Forum took over management of ACPI and the UEFI board created the ASWG (ACPI Specification Working Group) to manage ACPI's development.

One of the first challenges after this change in management was to clean up the ACPI specification and make it more ARM AArch64 friendly. ACPI 5.0 had already paved the way with the Hardware-Reduced profile, removing many of the assumptions about hardware registers, processor states and bus hierarchies . These had been driven to some extent by Microsoft when Windows RT was on the horizon. For a description of the ACPI-related changes made by Linaro and other ARM partners, see this summary. Linaro has been very active in submitting kernel patch after kernel patch to modify the X86-only flavor of some of the Linux kernel pieces.

Now, with the release of the new ACPI 5.1 specification in a timely fashion, the remaining bits that didn't fit have been cleared away. There is still more work to be done, but at least Linux, ACPI an ARM have a clear path forward, both in terms of technology and open specification governance.

Linux and UEFI: Linaro and LinuxCon

This week I've spent hanging around Linaro Connect 2013 USA, which is dedicated to bringing all of the open-source (and Linux) goodness to the ARM platform. For the 64-bit ARM architecture (AArch64), they have been promoting UEFI for quite a while but Linaro and its members are doing a lot of the really hard work of making sure that is a reality, with engineers dedicated to working from the reset vector up through the Linux kernel and into some server applications, making sure that all the necessary bits are there in open source. There were a lot of sessions this week that deal with the thorny issues of UEFI (secure boot), power management (PSCI) and ACPI (interaction with existing drivers and FDT).  To top it off, this event was co-located with ARM TechCon which doubled the fun, including an interesting keynote by Simon Segars, CEO or ARM.

This follows on the heels of the UEFI Plugfest, which was co-located also, but with LinuxCon in New Orleans. My colleague, Jeff Wheeler from Insyde got to attend, and he found folks interested in the question, "Does it really work?" And the answer was, "Yes, it does" This is the impression I recently found from  Bruno Cornec's blog article "First UEFI PlugFest for Linuxers". Good communication, good testing and, more importantly, UEFI and Linux work together.

The relationship between Linux and UEFI has not always been easy, with conspiracy theories and suspicious kicking of tires. But these two events have shown that they can and do work together, on x86 and ARM.

ACPI Specification Now Managed By UEFI, and Why Anyone Should Care

This article by my UEFI colleagues Dong Wei (HP, VP of UEFI) and Andrew Sloss (ARM, ARM Binding Sub-Team Chair) talks about a large recent development in the firmware world: ACPI is now managed by UEFI. I was a part of the ACPI specification development starting with ACPI 2.0 up through the current ACPI 5.0 specification while I was employed with Phoenix Technologies. That specification seems unusual to me now, in that it was essentially a five-way agreement between Intel, Microsoft, Compaq/HP, Phoenix and Toshiba. But actually, back in the day when it was conceived, it wasn't that unusual, as the BIOS Boot Specification (BBS) or Advanced Power Management (APM) will attest. For every revision of the specification, essentially the 5-way consortium was reborn again, occasionally (such as when Phoenix was added or Compaq was merged with HP) with a change of membership.

Due to the unusual structure and the fact that it was tied in many ways to Microsoft's release schedule and Intel's hardware schedule, releases tended to be big and cumbersome. Adding new members was problematic, since the number of signatures required from legal departments grows exponentially.

On the other hand, UEFI has functioned pretty well since 2005 in taking input, releasing regular errata and specification updates. So with Mark Doran (Intel, UEFI president) assuming the helm of both efforts, it seemed like a good time to push them together. They really address the same target audiences: system firmware providers, OS vendors, OEMs and chip manufacturers, with a smattering of plug-in card and application vendors. It probably helps convince folks like Linaro (working on ARM) and Redhat (working on Linux) to adopt ACPI if more than Intel and Microsoft are represented.

Now the process that is used to gather input, hash out differences and formulate solutions for UEFI can be applied to ACPI with, in my opinion, great effect.

UEFI 2.4 Review, Part 11: Timestamp Protocol

This article is the eleventh in a series looking at the changes introduced in the UEFI 2.4 specification. This time we take a look at the time stamp protocol (EFI_TIMESTAMP_PROTOCOL) in chapter 34.

Timestamp counters are common on various CPU architectures. So common, in fact, that many features have come to rely on them, such as ACPI's Firmware Performance Data Table (FPDT, chapter 5.2.23). On the x86 processors, the RDTSC instruction returns the current value. But, in various incarnations, this value has to be manipulated based on the number of cores, power-state, etc. So how to get a reliable number? Or, for that matter, how does this map on to ARM's generic timer?

I recently ran into this while trying to build the UEFI shell. There were recent changes to add the DP command, which displays the FPDT contents, to the UEFI shell. But this command had a dependency on the TimerLib, which was fixed at build time for a specific hardware implementation. That means that if the shell was run on another system, with a slightly different timer implementation, the DP command would not work or, worse, return the wrong value.

Whenever there is a hardware dependency like this, UEFI likes to abstract the hardware capability behind a protocol. In this case the EFI_TIMESTAMP_PROTOCOL was modeled after the TimerLib. It has two functions: GetTimeStamp() and GetProperties().

GetTimeStamp() simply returns the current time stamp value. There are a few restrictions though: the frequency of the time stamp must remain constant, regardless of power management state and the time stamp value may roll over. This latter is very important, especially for time stamp counters with fewer bits, since they can roll over in a few seconds.

GetProperties() returns the frequency (in Hz) of the time stamp counter, and the maximum value. This allows the caller to convert differences between time stamp counter values into actual time. It also allows for it to check for overflows. This is importance, since some implementations use the ACPI timer instead of an integrated CPU time stamp counter, and some implementations of the ACPI timer are only 24- or 32-bits in size.

With this new protocol, UEFI 2.4 allows utilities to track performance of a system in a way which spans the wide variety of system and CPU architectures supported.