EDK II UEFI Driver Writer's Guide
Search…
EDK II UEFI Driver Writer's Guide
Introduction
Tables
Figures
Examples
Acknowledgements
1 Introduction
2 UEFI Driver Implementation Checklist
3 Foundation
4 General Driver Design Guidelines
4.1 Common Coding Practices
4.2 Maximize Platform Compatibility
4.2.1 Never Assume all UEFI Drivers are Executed
4.2.2 Eliminate System Memory Assumptions
4.2.3 Use UEFI Memory Allocation Services
4.2.4 Do not make assumptions
4.2.5 Never Directly Access Hardware Resources
4.2.6 Memory ordering
4.2.7 DMA
4.2.8 Supporting Older EFI Specifications and UEFI Specifications
4.2.9 Reduce Poll Frequency
4.2.10 Minimize Time in Notification Functions
4.2.11 Use Proper Task Priority Levels
4.2.12 Design to be re-entrant
4.2.13 Do not use hidden PCI Option ROM Regions
4.2.14 Store Configuration Data with Device
4.2.15 Do not use hard-coded device path nodes
4.2.16 Do not cause errors on shared storage devices
4.2.17 Limit use of Console Services
4.2.18 Offer alternatives to function keys
4.3 Maximize CPU Compatibility
4.4 Optimization Techniques
5 UEFI Services
6 UEFI Driver Categories
7 Driver Entry Point
8 Private Context Data Structures
9 Driver Binding Protocol
10 UEFI Service Binding Protocol
11 UEFI Driver and Controller Names
12 UEFI Driver Configuration
13 UEFI Driver Diagnostics
14 Driver Health Protocol
15 Driver Family Override Protocol
16 Driver Supported EFI Version Protocol
17 Bus-Specific Driver Override Protocol
18 PCI Driver Design Guidelines
19 USB Driver Design Guidelines
20 SCSI Driver Design Guidelines
21 ATA Driver Design Guidelines
22 Text Console Driver Design Guidelines
23 Graphics Driver Design Guidelines
24 Mass Storage Driver Design Guidelines
25 Network Driver Design Guidelines
26 User Credential Driver Design Guidelines
27 Load File Driver Design Guidelines
28 IPF Platform Porting Considerations
29 EFI Byte Code Porting Considerations
30 Building UEFI Drivers
31 Testing and Debugging UEFI Drivers
32 Distributing UEFI Drivers
Appendix A EDK II File Templates
Appendix B EDK II Sample Drivers
Appendix C Glossary
Powered By GitBook
4.2.18 Offer alternatives to function keys
Configuration of drivers should be accomplished via HII and via OS-present interfaces.
There are design considerations when interacting outside of configuration. First, consider using the setup interface as the user interface for a UEFI driver. The user already understands the interface and remote use is already enabled. If the existing high level interfaces cannot be used, then follow the design considerations for using console based services.
UEFI drivers should use the console input services (see Section 22.2 of this guide), and then be aware of alternatives to function keys. This is because the UEFI console may be connected through a serial port. In such cases, it is sensitive to the correct terminal emulator configuration. If the terminal emulator is not correctly configured to match the terminal settings in UEFI (PC ANSI, VT100, VT100+, or VT-UTF8), some of the keys (function keys, arrow keys (page up/down, insert/delete, and backspace), may not work correctly, display colors properly nor render the correct cursor positioning.
Note: To better support users, it is recommended that UEFI configuration protocols and UEFI applications create user interfaces that are not solely dependent on these keys but instead offer alternatives for these keys.
Note: It is important to be aware that the Simple Input Protocol does not support the CTRL or ALT keys because these keys are not available with remote terminals such as terminal emulators and telnet.
The following table shows one possible set of alternate key sequences for function keys, arrow keys, page up/down keys, and the insert/delete keys. Each configuration protocol and application decides if alternate key sequences are supported and which alternate mappings should be used. The table also lists the UEFI scan code from the Simple Input Protocol and the alternate key sequence to use to produce particular scan codes.
Most of these key sequences are directly supported in the EDK II_―_special handling is not required to support these key sequences on a remote terminal. Those labeled as "No" are not directly supported in the EDK II. They are parsed and interpreted by the configuration protocol or application.

Table 14-Alternate key sequences for remote terminals

UEFI scan code
Key sequence
Supported in EDK II?
SCAN_UP
'^'
No
SCAN_DOWN
'v' or 'V'
No
SCAN_RIGHT
'>'
No
SCAN_LEFT
'<'
No
SCAN_HOME
ESC h
Yes
SCAN_END
ESC k
Yes
SCAN_INSERT
ESC +
Yes
SCAN_DELETE
ESC -
Yes
SCAN_PAGE_UP
ESC ?
Yes
SCAN_PAGE_DOWN
ESC /
Yes
SCAN_F1
ESC 1
Yes
SCAN_F2
ESC 2
Yes
SCAN_F3
ESC 3
Yes
SCAN_F4
ESC 4
Yes
SCAN_F5
ESC 5
Yes
SCAN_F6
ESC 6
Yes
SCAN_F7
ESC 7
Yes
SCAN_F8
ESC 8
Yes
SCAN_F9
ESC 9
Yes
Previous
4.2.17 Limit use of Console Services
Next
4.3 Maximize CPU Compatibility
Last modified 2yr ago
Copy link