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.