Wow, I take the week of CES off and looks what happens … everybody is talking about UEFI. My Twitter account exploded with articles on UEFI from around the world (thank you Google Translate, since I can’t read French, German, Japanese, Chinese or Indonesian).


The big focus seems to be on the cool graphical interfaces companies like Asus and MSI are adding to UEFI on their desktop platforms. And I admit, they’re pretty cool … the BIOS setup menu has been pretty much a text interface since the era when top-loading VCRs were considered “technology”.


But I think it’s important to understand how UEFI is related to those graphical pre-boot interfaces. After all, the industry has had high-resolution graphics controllers for a long time. Why does UEFI suddenly unleash new user interfaces? Does UEFI actually require users to move from keyboard to mouse?

The GUI isn’t New-ey

Uncomfortable rhymes aside, the graphics capabilities of UEFI aren’t a new thing. Companies like AMI, MSI and Asus have been previewing GUI pre-boot interfaces for several years. Here’s a demo video of the Asus interface from 2009

BIOS providers like AMI have been showing graphical interfaces and development libraries back when UEFI was just “EFI” … you know you’ve worked in technology too long when you refer to “the good old days” as sometime back in 2004. Adding GUI in pre-boot comes from some major improvements in how UEFI handles graphics output versus a 16-bit BIOS.

Understanding GOP

Once effect of UEFI is replacing legacy BIOS interrupt calls, which depend on 16-bit x86 compatibility, with protocols. The traditional VESA modes used by the BIOS to define a display adapter’s supported modes rely on software interrupts, so they had to be replaced. The result is the UEFI Graphics Output Protocol (GOP), which replaces a complex set of modes with a simple video buffer.


The VESA BIOS Extensions (VBE) define a large table of graphics modes, but a developer can never assume that a specific mode is supported. This makes it very hard for a developer to make an interface that works across different graphics cards. Yes, they can write an interface to a common resolution (800x600 for example) but there are several different modes that can be used to support that resolution, assuming it’s supported at all using VBE (remember, these modes are optional).


GOP just defines a buffer for a particular resolution and color depth. This makes it easier to support a new resolution, or have the display scale to a different resolution. There are also common resolutions in use (example: Microsoft Windows requires 1024x768 and 800x600 for GOP in their bootloader, Intel EPOG supports 800x600 in GOP). This simplicity in implementation makes GUI development easier for the BIOS and pre-boot applications, such as the AMI Provisioning environment.

The GUI isn’t Mandatory

For folks in the embedded market, a GUI pre-boot interface isn’t always seen as a necessary feature. In fact, it’s often seen as undesirable for headless systems or deeply embedded platforms. For a system with no local display, an interface like this doesn’t make much sense.



So good news for embedded customers … UEFI doesn’t require a graphical pre-boot interface. UEFI has been on platforms for years, and vast majority ship with an interface that looks and acts like the “legacy BIOS” text interface. This allows the base firmware to get upgrades without affecting compatibility with console redirection tools designed for headless management. As an added bonus, tech support doesn’t have to learn a new interface.


Even if you want to take advantage of graphics in pre-boot, UEFI has a solution for console redirection. Thanks to a “console splitter” driver, user output can be processed differently depending on the physical interface. Users see a colorful interface in a graphical frame on the monitor, a user connected to the same computer gets VT-100/ANSI 80x25 text via serial port or Serial over LAN (SoL). This allows “headless” console interfaces to work even if a graphical option is used for BIOS setup.


So Why Now?

If you ignore “tablet madness”, CES 2011 made UEFI look like a really big deal. Of course, UEFI has been shipping into the PC market for years, but it’s never been … well, sexy. When 3TB drives started shipping last year, UEFI suddenly became important because of the need for GPT to overcome MBR partition limitations. When boot speed was the focus at the end of 2010, UEFI got a little more attention.


CES 2011 was a good show of new product releases that started developing with UEFI in 2009 and 2010. Since firmware is hard for some people to visualize, graphical BIOS setup is an easy way to show “under the hood” innovation to the press. Never mind the fact that the GUI isn’t mandatory, or that it’s only one way UEFI improves platform firmware. The emergence of graphics under UEFI just goes to show the universal rule of technology …


… everybody loves a good tradeshow demo


Brian Richardson
Senior Technical Marketing Engineer
American Megatrends, Inc.


American Megatrends, Inc. (AMI) is an Affiliate member of the Intel® Embedded Alliance.


Got a question about BIOS or UEFI? … it’s time to Ask a BIOS Guy! Find Brian on Twitter (@askabiosguy) or leave your question in the comments. Your BIOS question may be featured in an upcoming ‘Ask a BIOS Guy’ article.