UEFI HII (Part 2)

This week, we will look at some of the key elements of the Human Interface Infrastructure portion of the UEFI 2.1 and later specifications. UEFI platform firmware provides two key facilities:

1. The HII Database. The database acts a repository for all sorts of configuration and user-interface resources, including forms, fonts, strings, images, animations, and keyboard layouts. The platform and individual drivers can install and remove these resources.
2. The HII Forms Browser. The browser is the platform-provided user interface where the forms are displayed and input from the user is taken in order to update configuration settings.

The platform firmware decides when the user interface should be displayed. This is different from legacy BIOS and UEFI 2.0, where individual option ROMs could put up their own user interface elements, provide their own boot hot keys for entering those utilities and delay the boot in order to display instructions and copyright information. Now, with UEFI 2.1 and beyond, the individual drivers provide user interface information to the platform and the platform presents it to the user.

In most implementations, the decision about when is controlled by the UEFI Boot Manager. The how might be part of the boot manager itself or a separate driver or application. Why? The boot manager is already responsible for hot keys for launching boot options and applications. The boot manager is also responsible for the UEFI driver health support and the UEFI user identification support, both of which can be user-interface intensive and are heavily involved with the boot process.

For drivers, the most important API is the EFI_HII_DATABASE_PROTOCOL. Normally, during driver initialization (if one page manages all driver-supported devices) or during Start(), the driver will install the forms and strings that it will use for configuration, driver health and user identification using NewPackageList().

The next important API for drivers is the EFI_HII_CONFIG_ACCESS_PROTOCOL, which is provided by the driver to handle configuration-related behaviors. This protocol provides three important functions:

1. ExtractConfig(). Return the current configuration settings.
2. RouteConfig() . Change the current configuration settings.
3. Callback(). Handle callbacks while the user is interacting with the forms.

That's it. The driver publishes forms and strings and provides a way to read and write configuration values and handle callbacks from the forms. Of course, there's a lot more in the nitty-gritty details and we'll dig into that soon.

But next, week we will spend a little time on how the resources are put together and delivered to the HII Database and even OS-present applications.

UEFI HII (Part 1)

Starting with version 2.1, the UEFI Specification began to describe a standardized way in which firmware could communicate with a user or application concerning firmware-related settings. Previously, the EFI 1.10 specification had the EFI_DRIVER_CONFIGURATION_PROTOCOL, which provided a means by which driver could take control of the console and throw up their own configuration screens. This mechanism provided a great deal of flexibility. The platform firmware could provide its own instance of this protocol for motherboard components and each of the 3rd party drivers, such as those on plug-in cards, could provide an instance also. A platform firmware application could list out these instances for a user to choose from. But this decentralized approach led to other problems. It meant that:

1. There was no consistent look-and-feel for a platform, since each driver got to pick its own color scheme, its own keyboard commands and its own screen layout.
2. Individual drivers had to make assumptions about the type of input and output devices available. For example, some platforms might have five buttons and a two line 25 character LCD display while others might have BitBlt graphics and input-method editors. 3rd party drivers would have to invest a lot to make their drivers work on a wide range of consoles.
3. There was no means of centralized platform configuration (for provisioning or remote management). For example, if I wanted to save the settings from one platform and use those to configure a brand-new bare-metal platform. How to get ahold of the settings and apply them in a uniform fashion?

In order to address these issues, the UEFI 2.1 specification introduced the Human Interface Infrastructure (HII), which was designed to give the platform firmware centralized control over how input, output and configuration were managed. HII includes everything from fonts, bitmaps, forms to the routing of configuration information between the system and drivers. There were several goals when we created HII. These included:

• Localization. Localization is the process by which a product is adapted to a local market. Most significantly for platform firmware, this includes display languages and input languages.
• Forms. Forms provide the abstraction by which drivers expose the configuration settings to the platform firmware.
• Remote and Off-Line and OS-Present Configuration. The configuration settings for a platform must be exposed in such a way that an implementation could support a variety of alternate ways to configure the platform. For example, remote scripting, remote interactive, semi-interactive (off-line but with forms) or OS application-driven configuration of the platform.
• Provide APIs which would allow drivers, including those on plug-in cards to have full access to the HII resources, including fonts, strings and forms, and be able to contribute additional resources.
• Support a wide-range of display devices.

This led to a fairly sophisicated and flexible infrastructure and a lot of confusion, because in many places the HII specification added abstractions between display, configuration and configuration storage that had never existed before in the firmware world. Next week, we'll look at some of the key design decisions and why they were made.

UEFI Shell: Profiles

Last time, I discussed how the UEFI Shell can come in four basic flavors, called support levels. Level 0 was the most basic, supporting almost all of the API, but none of the scripting language and no user interface. Level 1 added basic scripting. Level 2 added file manipulation scripting. Level 3 added user-interface related scripting. Ok. So now we have a robust shell. But it can't do very much. In a manufacturing environment, it is important that software developers, including those who write provisioning and management scripts for systems, be able to depend on other types of commands, such as those which connect to the network stack or those which provide debug capabilities. If my script depends on these commands being present, how can I detect or even automatically correct such a situation? Enter Shell Command Profiles. A Shell Command Profile is a group of related commands that have a name. Names are made up of numbers, letters and the underscore ('_') character. Profile names that start with a '_' are reserved for usage by 3rd parties. Profile names that start with a letter or number are reserved for use by the UEFI Shell specification. The names of all profiles are stored in the environment variable "profiles" and are separated by the semicolon (';') character. This environment variable is initialized based on (a) the profiles that are built into the shell executable itself and (b) a file named "profiles.txt" that exists in the same directory as the shell executable. A script can determine which profiles are installed by searching this environment variable for the name of a specific profile. For example: if not Profile("Network1") then echo Required script command profile "Network1" not found. exit /b 1 endif The Profile() operator searches the "profiles" environment variable for the one specified and returns 1 if it is found or o if it is not. The UEFI 2.0 Shell Specification supports four standard profiles:

• Driver1. Standard set of driver-related commands. This includes connect, devices, devtree, dh, disconnect, drivers, drvcfg, drvdiag, reconnect and unload.
• Debug1. Standard set of debug commands. This includes the following commands: bcfg, comp, dblk, dmem, dmpstore, edit, eficompress, efidecompress, guid, hexedit, loadpcirom, mem, memmap,mm, mode, pci, sermod, setsize and smbiosview.
• Network1. Standard set of networking-related commands. This includes ifconfig, ipconfig, and ping.
• Install1. Standard set of commands to aid installation. This includes only bcfg.

Shell profiles provide an extensible method for creating standard groups of commands that can be relied up by 3rd party applications. Next Time: The UEFI Shell API.

UEFI Shell: Levels of Support

The UEFI shell comes in four flavors, called levels of support. These "levels" (from 0 to 3) allows for compliant implementations of the shell that range from light-weight, bare-bones to a full-featured versions. At the same time, the user of the shell can determine, at run-time, whether the necessary features are available for it to run correctly. Why offer different levels of support?

1. Size. While the rest of the universe expands storage capacity exponentially, the firmware world still lives with relatively expensive flash devices. Suffice it to say that the types of flash and trends in flash which are driving down the cost for devices such as the iPod are a little slower in dropping the average price of motherboard flash. Flash size can significantly impact the cost of a motherboard. So there is constant pressure to keep the "required" elements of the firmware as small as possible. NOTE: One additional trend is that silicon vendors such as Intel are gobbling up room on the flash devices as well, both with their own firmware modules and with support for on-board micro controllers such as the ME (Management Engine). In some systems, 2/3 of the flash space is consumed by support for these devices. So the shell in the firmware must be small.
2. Video & Keyboard Support. When most of us think of a "shell" we usually think of some sort of command-prompt console at which a user can type in commands, execute scripts, etc. However, in many of the systems, the shell is used primarily for execution of scripts or applications that do not require a console at all.

So the UEFI shell can provide any of 4 standard support levels:

• 0 (Minimal). This is the most basic support. The APIs are fully supported, but there is no support for scripting, aliases or a console. Normal shell applications will execute.
• 1 (Scripting). This level adds support for scripts and the script control commands, but none of the other commands that do anything (such as write text to the screen or manipulate files). This allows scripts to be launched, but all of the script commands must be executables (.efi files) on a mapped drive.
• 2 (Basic). This level adds file script commands, such as rm, ls and mkdir. At this level, there is still no console support. As a result, those commands which would normally output to the console do not do so at this support level. Notice that, up to this point, an application could use the APIs to read and write files, but not execute scripts which used the common file manipulation commands.
• 3 (Interactive). This level adds console input and output, as well as those script commands which depend on the console, such as echo, type and cls.

The support level provided by the UEFI shell can be checked by any script or application by examining the environment variable shellsupport which contains the text "0" for Level 0, "1" for Level 1 and so on. Next week we'll look at how support provided by the shell can further be augmented in a standard way using "profiles". Tim

UEFI Updates Specification Roadmap.

Hey, just noticed that UEFI has officially updated their roadmap here. For me, the big questions revolve around SCT support for ARM, HII and the user identification and security parts of 2.2 and 2.3. These additions are hefty (clocking in at over 300 pages).

UEFI Driver Wish List 2007

Hey, I just posted my wish list for 2007 drivers over at http://blogs.phoenix.com.

Teach What You Know

A really interesting book I picked up a few months ago is called "Teach What You Know" by Steve Trautman. It is designed for technical experts who have to educate their peers while still getting their day job done. Sounds like me, since I am the only one at my office, am the chief architect for my product and the conduit for a lot of knowledge coming from other companies. It covers topics such as e-mail for efficiency (how to really get my attetion NOW or can it wait 24 hours), phone contact and meeting plans designed for efficiency, so that it doesn't take over your whole work schedule. Particularly useful was maintenance plans for different types of people, based on how easily they get stuck. There are separate chapters for remote communication, setting clear goals, explaining the "big picture" and even the basics of office life (air, food & water). For me, this was a great book, but I could only take it in small doses, just because it has a lot to say. The stories are great and certainly felt like home, esp. the story about Microsoft engineers getting a foreign team of engineers dumped on them for training. Tim

UEFI Plug Fest Follow-Up

There was a pretty good turn-out. The Intel site looks like it was set up for this sort of thing...five years ago. There are about 20 individual large cubes with high walls and lockable doors. Not perfectly secure, but enough to deter. The event ended up filling not only those 20 cubes but also overflowing into neighboring areas. There are no bathrooms right nearby. The conference rooms are behind heavy doors. The sign-in process is typical Intel: search your bags, sign-in for a red sticker, wear the sticker everywhere. From there, nobody seemed to mind where you went. AMI and Insyde where there, along with Byosoft (see previous post on China BIOS). Saw Zimmer & Rothman of Beyond BIOS fame. Both the SMST (SMM vs. VM sub-team) and the UTWG had face-to-face and some of us in the PIWG did follow-up regarding security, PCI and SMM face-to-face, although I was generally glued to the ICE most of the time trying to debug hangs. Turns out the hangs were not really hang, just really slow because of cache issues. Can you image 3KB taking 3 minutes to move on a 2GHz processor? Neither can I, but its true when coming from the flash and the flash is uncached :-) Tim

UEFI Test Event

Well, there are no press releases (UEFI is notably stingy on funds), but a big UEFI Test Event is taking place 11-15 December in Dupont, WA. Why Dupont? Well, primarily because Intel has a big facility with lots of open space and they were willing to help foot the bill. And, not to be outdone, AMD kicked in some money and UEFI itself covered the rest. The test group in UEFI is sponsoring this as part of its beta roll-out of the UEFI System Compatibility Tests. I'll be there the entire week. More later.

Beyond BIOS: Book From Intel Press

Just received my copy of Beyond BIOS: Implementing the Unified Extensible Firmware Interface with Intel's Framework. This is written by three of the regular contributors to USWG and PIWG from Intel, Vincent Zimmer (PIWG, Security SubTeam, Network Sub-Team), Mike Rothman (USWG, Configuration Sub-Team) and Bob Hale (Configuration Sub-Team), so I end up talking with them a lot. I haven't read it in detail, but a lot of the content is a recap of the UEFI specification or the Intel Framework Architecture Specification or, in a few cases, the old EFI 1.10 Driver Writer's Guide. The pictures are mostly upgraded ones from those documents, although the ones for the PCI stuff are a lot better than the original docs. More later, after I've had a chance to read more of it. Tim

Another AMI note...

From AMI's press release: "Proven stability, modularity and ease of porting of APTIO® are not compromised and they conform to UEFI and PIWG specifications" Wow! Since there are no PIWG specifications yet (the latest are in draft), I guess that's easy to accomplish. And this is the first time I've seen them claim UEFI 2.0 compliance (since that's the only spec released so far). I'm not even sure EDK 2.0 (Intel's tianocore version) can claim that yet.

AMI Aptio & AMD

Pheww. AMI is sure putting out the press releases. This time, around supporting AMD. http://www.marketwire.com/mw/release_html_b1?release_id=159150. I suppose this is to balance out their other Intel press release (see my other post). Their drop in support is a nice accomplishment, although I can just imagine the level of hacking necessary to get it to work. But it kind of looks bad for AMD. I mean, you would expect that AMD would be out their touting their support for the new standards and, by the way, they can still plug into the old BIOS, too. Instead, they are still locked into supporting the same number of BIOS vendors as before. If I'm a BIOS customer and I get the supposedly Tiano compliant drivers, what's the advantage? I'm still locked into an AMI code base by license. The next bold step will be for AMD to publish their own drivers. Three out of the four commercial code bases support it (Phoenix hasn't announced any support for the Award code base). Still have to worry about the in-house BIOS teams at places like Dell, IBM, HP, tool. But with the PI standard rolling along, there'll be a lot of incentive for folks to move to the standard. And now, purchasing ATI, we'll really get another chip vendor support UEFI... Tim

AMI Aptio & Intel

As represented here: http://www.pressmethod.com/releasestorage/9378.htm, AMI is making the most of its relationship with Intel, and is starting to do training with Intel's participation, in at least Boston and Santa Clara. They claim to have done one already in Tokyo. This is important for Intel because Intel switched to use Aptio on their mobile reference platforms, but very few of their customers use the AMI code base (AMI having not traditionally been strong in this market). Tokyo is a prime example where nearly all of the platform vendors use Phoenix currently.

Chinese UEFI BIOS Redux

I actually went to visit one of the companies which is working on the project: Nanjing Byosoft. This is the one headed by ex-Phoenix employee Kangkang Shen. I went there on the last day of my trip to China. Their focus seems to be on the embedded space and they are in some sort of in-China competition to see who will do the project with the government. They are in a small building in the research park near where Phoenix had its building before. We also toured the sight of their new building, a 10-story building due to be finished next year, all dedicated to BIOS and embedded systems. The other three buildings in that complex are for animaton and game programming.

Chinese UEFI BIOS

According to this official announcement (http://www.mii.gov.cn/art/2005/12/17/art_80_1697.html) the Chinese government has started a "secure" BIOS project, apparently based on UEFI. This (computer generated) translation shows the charter of creating a "New generation of security BIOS research and development and industrial production" is given to "Software Engineering Center - Chinese Academy of Sciences", "China Electronic Technology Group Corporation" and "Chinese System Technology Limited company" A little more digging reveals that (http://www.njswp.com/html/life_detail.php?sid=52): On May 16, a few of Intel's UEFI gurus (Mark Doran, UEFI's secretary, Lu Ju, head of a group which does UEFI development in Shanghai) visited one of these companies Software Engineering Center Chinese Academy of Sciences http://www.sec.ac.cn/, which is located in Nanjing. Coincidently, this is very near the building which used to belong to Phoenix and I've visited several times myself (even staying in the apartments across the street). The fourth gentleman from the right in the picture (Kangkang Shen) is an ex-Phoenix employee who I've worked with several times. The building in the picture isn't the same as Phoenix's but looks like the one next door. Looks like the Chinese government hopes to use UEFI...

AMD & ATI & UEFI

As Reuter's mentioned here: http://biz.yahoo.com/rb/060724/ati.html?.v=7, AMD has announced the purchase of ATI. So, what does this mean for UEFI? Well, AMD is a board member and ATI is a contributor, so it bumps of ATI's ability to influence overall UEFI policy. Hopefully, it means that ATI will also agressively push the PI and UEFI silicon model for its firmware deliveries. It will be interesting to watch how the ATI chipset architects will be represented in the new AMD corporate structure, and thus in the UEFI meetings. Tim

Microsoft & UEFI

According to this report (http://www.vnunet.com/vnunet/news/2156867/microsoft-promises-bios) from WinHEC, Microsoft will begin supporting UEFI officially with the Vista SP1 and Longhorn Server. This is actually consistent with what they said at this year's Intel IDF. However, their previous statements were so careful that many people felt Microsoft was going to pull support entirely (see the other links on the site linked above). Since Microsoft is one of the board members of UEFI, that was pretty embarrassing :-( Microsoft previously stated that they weren't seeing any BIOS vendor support on real platforms for UEFI. It is kind of a chicken-and-egg problem, since if you don't support it in the OS, why would an OEM spend the money speculatively? And if the OEM doesn't build it, the OS won't test it. This is similar to the problems with SMBus battery support in ACPI. Its in the spec but nobody built systems, so the OS never officially supported it. Anyway, this positive comment from Microsoft, combined with Bill Gates mentioning it in his keynote address, should put they nay-sayers away. And if Microsoft decides to only support UEFI for X64 (EMT64/AMD64) on server, that would be great because it gets us away from the EFI32/EFI64 support nightmare (more later, short version is: can't build a BIOS with support for both at the same time) Tim

Insyde, AMD and UEFI

Insyde (as reported here: http://www.tmcnet.com/usubmit/2006/05/22/1658081.htm) put put out a press-release talking about their support of Framework support of AMD processors. They demo'd this at WinHEC running Vista. It wasn't clear whether they actually booted Vista using UEFI or using good ol' INT 19. This is important for Insyde, since they've primarily been living off of PEI/DXE drivers from Intel. Moving silicon support outside the Intel camp shows that their product isn't just tied to Intel. AGESA (mentioned in the article) has been AMD's standard way of delivering code to BIOS vendors in the past. The problem for AMD has been, how to integrate their code as quickly as possible into a new BIOS code base (either one of the BIOS vendors or one of the many customers who purchase source code or have their own BIOS). The answer, to this point, has been encapsulation (the 'E' in AGESA). So what Insyde did was create a PEI-style wrapper and some conventions to handle the call-outs from AMD's code. Seems like a good transition strategy, one which would be obviated if AMD would create their own PEI drivers. Right now, there is still some value for BIOS vendors to create their own code. Many of the silicon vendors haven't switched their own internal support structure to create PEI/DXE modules and at least one major code base (Award, produced by Phoenix) doesn't support PEI currently. If every BIOS code base were to support PEI/DXE, then there is no reason not to produce it in that format. The article contains some technical inaccuracies: I don't think Insyde was really running a UEFI solution in their booth (at least they haven't announced UEFI 2.0 support in the past). They are also playing loose with terminology: UEFI-based PEI and DXE drivers. The UEFI specification does not talk about PEI or DXE. The Platform Initialization Working Group inside of UEFI Incorporated is working on two specifications (PEI & DXE) which have not been released yet, are different in several ways (incompatible ways) from Intel's previous initiatives of the same name, and aren't necessary for the UEFI specification at all.

Apple's Boot Camp

Apple announced here (http://www.apple.com/macosx/bootcamp/) that they can now dual-boot Windows XP and MAC OS. This had previously been done via a hacker patch, but an officially supported one is quite an impressive accomplishment. What isn't clear is where they got their CSM, since XP still uses all of the legacy interrupts to boot, it means they had to stick something on the front of the DXE driver model they got with the Framework. Actually, supporting only XP is a lot easier than a lot of the garbage that BIOS companies have to put up with to support (say) Win98 or WinMe. You may not believe this is an issue until you realize that big PC companies have guaranteed support contracts for Win95 still. What a breath of fresh air it was to finally no longer have to include OS/2 testing in compatibility labs (it was the only OS which didn't support DPMI, which meant we had to use SMIs to switch out of real-mode to protected mode code). Having said that, XP still requires dozens of interfaces, from INT 15, E820, through the extended INT 13 functions, INT 10 and INT 16. A CSM essentially requires an EFI-style executable which can relocate itself into the F000 shadow area to provide the compatibility services. If you want a degree of platform-independence, you can either (a) reverse thunk into flat 32-bit model to call the EFI driver or (b) rewrite all the BIOS support code for each platform. They can either license it from someone, write it themselves or steal it from another product. Did they have a BIOS license in the the PC virtualization stuff? I don't know. Since I haven't seen Phoenix or Insyde or AMI trumpet this, I don't think they bought this from anyone. For now, it is a fun playground for enthusiasts.

Microsoft Vista Not To Support UEFI

According to this article at eWeek (http://www.eweek.com/article2/0,1895,1937668,00.asp), Microsoft's initial release of Vista won't support EFI. I wasnt' actually at the IDF presentation where Andrew Ritz said this, but I was in one of the UEFI meetings running in the Marriott next door to listen to the aftermath discussion. Quite a stir, I guarantee. So the real question becomes: what does this do to the BIOS companies, like Phoenix or AMI or Insyde? On the face of this, the delay by MS also delays the transition to UEFI. But actually, there are two other forces at work within UEFI which are pushing adoption regardless of what MS does. Driver Model Comes To BIOS The first is the Platform Initialization Working Group, which was formed to help standardize silicon enabling in the firmware. Silicon enabling has become one of the costliest portions of the process of getting a standard PC platform out the door. The first specification hasn't been released yet, but it allows silicon providers create "drivers" for BIOS which should plug in to any compliant implementation. Right now, each motherboard silicon vendor has created their own model for delivering code to board providers, generally through one of the BIOS vendors. But, since there has been no standard for silicon-in-BIOS, each vendor has created a method of isolating their code from the BIOS so that they can easily ship updates. But the methods are all different and generally only cover a small amount of the silicon initialization required for booting the system. Also, bug fixes take longer to reach the OEM/ODM because it has to go through an "integration" phase where BIOS vendors take bug fixes, add them to their code, and then turn around and hand it to the OEM/ODM. There is a lot of wasted time and energy here which has nothing to do with value-add for either the BIOS vendor or the OEM. So this delivery model is coming to BIOS and has very little to do with loading an OS Application Portability The other major area where I am seeing interest is UEFI applications. OEMs need to add functionality which is close to the platform which works on different BIOS vendors. OEMs often like to switch between board vendors. Board vendors have often used the accreted libraries of special OEM features on a particular BIOS as a way of preventing the OEMs from switching (because it would cost too much). But if the feature can be implemented in UEFI and UEFI is supported by all vendors, then it makes it easier to switch. It also allows OEMs to keep their features to themselves without sharing with the board manufacturers, since they can just hand them a binary executable and say: put it in the system. Applications like those supported by UEFI are also useful as a way of replacing dependency on DOS. People just aren't writing drivers for DOS anymore. But, because UEFI is tied to the BIOS, there is a good possibility that there will be drivers written for the silicon which supports UEFI. Since UEFI 2.0 now supports TCP/IP explicitly, as well as a large number of other devices, it makes it useful for a lot of manufacturing tasks. BTW, the article has a number of inaccuracies around the topic of the so-called compatibility support module (CSM). Actually, this term comes from the way that Intel's Framework implementation of EFI (http://www.intel.com/technology/framework/) supports the current OS (DOS/WinXP/Linux) boot model. Other implementations (like Phoenix's) have gone the other way and just made EFI yet-another-interface supported by the firmware. You can see some aspects of the Framework at www.tianocore.org although the CSM isn't there.