2.1 Design and implementation of UEFI drivers
The following lists the basic steps a driver writer should follow when designing and implementing a UEFI driver. Note that this document assumes UEFI driver model drivers are being developed.
Determine the category of UEFI driver to be developed. The different categories are listed in Table 2, below, and are described in more detail in Chapter 6 of this document.
Note: UEFI Drivers that follow the UEFI Driver Model are recommended because they enable faster platform boot times.
Make sure the driver supports the unload service. This feature is strongly recommended for all drivers. Section 7.6 describes the unload service.
Make sure the UEFI driver supports both the Component Name protocol and the Component Name2 protocol. It is strongly recommended that all drivers support both protocols.
Is the UEFI driver going to include configuration settings that the user can change? If so, the driver must support HII functionality. Note that the HII functionality replaces the Driver Configuration Protocol, which is now obsolete. See Table 2.
The UEFI driver must produce the Driver Diagnostics Protocols if the driver is going to support testing See Chapter 13.
If the UEFI driver is a bus driver for a bus type that supports storage of UEFI drivers with the child devices, the Bus Specific Driver Override Protocol must be implemented by the bus driver. See Chapter 17 of this guide.
A UEFI driver might not need to call an Exit Boot Service event. However, if the UEFI driver is going to require an Exit Boot Services event, then the driver must create an event of type Exit Boot Services. When the driver initializes, it creates the event, and when Exit Boot Services happens, the system calls the function that the driver produces. See Chapter 7.
For runtime drivers, make sure the driver defines an event of type Set Virtual Address Map. This allows the driver to know where the memory map is located once the OS takes control. See Chapter 7.
Identify the I/O-related protocols the driver needs to consume. Based on the list of consumed protocols and the criteria for these protocol interfaces, determine how many instances of the Driver Binding Protocol need to be produced. For example, a console driver might have multiple binding protocols to allow for input from multiple devices. See Chapter 9.
Identify all I/O-related protocols that the driver binding model must produce. Once the I/O-related protocols are known, make sure the driver creates a function with a single entry point for each protocol.
Implement the driver's entry point. See Chapter 7.
Design the private context data structure. See Chapter 8.
Implement all the services listed in the supported section of the Driver Binding Protocol. See Chapter 9. See Table 3.
Table 2-Classes of UEFI drivers to develop
| Class of Driver | See sections |
|---|---|
| Device driver | 6.1 |
| Bus driver that can produce one or all child handles | 6.2.6 |
Bus driver that produces all child handles in the first call to Start() |
6.2.7 |
Bus driver that produces at most one child handle in Start() |
6.2.8 |
Bus driver that produces no child handles in Start() |
6.2.9 |
| Bus driver that produces child handles with multiple parent controllers | 6.2.4 |
| Hybrid driver that can produce one or all child handles | 6.3 and 6.2.6 |
Hybrid driver that produces all child handles in the first call to Start() |
6.3 and 6.2.7 |
Hybrid driver that produces at most one child handle in Start() |
6.3 and 6.2.8 |
Hybrid driver that produces no child handles in Start() |
6.3 and 6.2.9 |
| Hybrid driver that produces child handles with multiple parent controllers | 6.3 and 6.2.4 |
| Service driver | 6.4 and 7.9 |
| Root bridge driver | 6.5 and 7.10 |
| Initializing driver | 6.6 and 7.8 |
Table 3-Protocols produced by various devices
| Device | Produces these I/O protocols |
|---|---|
| USB peripherals | USB I/O protocol |
| PCI adapter | PCI I/O protocol |
| Console devices | Simple input protocol Simple pointer protocol Graphics output protocol Block I/O protocol |
| SCSI, SCSI RAID, and Fiber Channel | Extended SCSI pass thru protocol Block I/O protocol |
| NIC (network interface controller) | The protocols produced by the NIC depends on the specific NIC: Universal network driver interface (UNDI) protocol Network interface identifier protocol Managed network protocol (MNP) Simple network protocol (SNP) |
Note: The device path protocol is a data structure protocol, not a function call with a callable entry point. It is the UEFI driver's job to append the path of the devices it is controlling to the data structure. In other words, as part of producing the I/O protocol for each device, the driver builds the device path for that device.