UEFI

Support for UEFI booting will require several different pieces in the installer, the kernel storage stack, and the bootloader. This page documents the various pieces and also serves as a reference for where to get relevant information and tools.

General

In instances of UEFI booting, the operating system must have some way of accessing UEFI services. During the handoff from UEFI, the OS' bootloader is provided with a memory map that includes the handle database to UEFI's runtime services. Any driver or service that wants to use UEFI protocols will need to get access to that database somehow.

Modules

Bootloader

A new bootloader would basically be needed, one that could use UEFI services in order to load the operating system and also hand off the memory map to the OS.

Installer

The installer would need to be updated to install a UEFI bootloader when performing a native UEFI installation.

The installer is currently split into two parts, stage one and stage two. Stage one is located in base/setup/usetup and stage two is located in dll/win32/syssetup. Note that due to hardcoding in the kernel, when usetup is placed in the ISO it is renamed to smss because that is the first thing the kernel loads.

Whether the project will support an MBR boot on UEFI is still under debate.

Features

ACPI

The ACPI tables are currently acquired from the BIOS in the HAL. The portion of code responsible for this would need to be supplemented to support getting the table from UEFI's system configuration table.

Floppy

The BIOS provides a list of connected floppy drivers to the operating system.

This one is a tad complicated. There have been reports that Windows does not properly support motherboard floppy controllers when booting from UEFI. The cause is not definitively known though a couple of pieces of data have emerged, one pointing to an issue with ACPI. See below code for a proposed workaround.

 Method(_FDE, 0)
 {
   Name(FDE, Buffer(){1,0,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,0, 2,0,0,0})
   Return(FDE)
 }
 
 Method(_STA, 0)
 {
   Return(0xF) //Return present and active
 }

Note however that this by itself does not get the drives working, they are only now detected.

Memory

The OS needs to get a memory map of the system. This technically happens at the handoff between UEFI and the OS' bootloader. What this entails on Windows is described in some detail here.

Video

A new video driver is needed when booting from UEFI. The VESA driver relies on the INT 10h BIOS interrupt call which would not exist during a native UEFI boot. The current VESA driver is located in win32ss/drivers/miniport/vbe/. The new video driver would need to rely on UEFI's Graphics Output Protocol.

UEFI Development

To develop against UEFI will require the EDKII source code. The documentation on the Tianocore project outlines exactly how to obtain and build the source code and most of it is sufficiently clear. Note that for all practical purposes you are primarily interested in the library and module headers that give you access to the UEFI API. However, building everything just tends to be easier than trying to put together a standalone UEFI application due to the way EDKII's build system works.

For those interested in actually playing around with a UEFI image itself, the Open Virtual Machine Firmware (also part of Tianocore) provides a platform for use with QEMU. OVMF provides binary images in addition to the source code. Its documentation is a bit more sparse however and there are a few minor irritants.

• Building OVMF requires having an ACPI Source Language compiler, which is separate from the C compiler used for the rest of UEFI. The OVMF documentation links you to two options, Microsoft's or Intel's, but states that you need to configure them to be part of your EDKII build tree without explaining what that means. For all practical purposes, it just means setting the WIN_ASL_BIN_DIR value in the Conf/tools_def.txt file to the path where you downloaded the ASL compiler, whether it be Microsoft's or Intels.
• Starting up OVMF on QEMU actually requires the option -monitor stdio to be passed in, otherwise QEMU just hangs. Whether this is due to OVMF or QEMU is unknown at this point.