SetupDesignGuide.pdf - Firmware Encoding Index

Setup Design Guide
DRAFT
Human Interface Infrastructure
Database
Consists of IFR/String/Font
Which has been submitted by varying EFI drivers
EFI Driver
VFR Sample
text text = CPU_STRING,
text = DERIVED_CPU_FREQUENCY,
flags = DYNAMIC,
key = CPU_FREQUENCY_KEY;
This sample shows an example of the programming language used in the EFI Setup
infrastructure. In this case, a DYNAMIC flag signifies that when this code is exported to
the database a callback will be done for this operation to fill in the second text entry.
The behavior and operands will vary based on which type of op-code is thus flagged.
String Tokens – Prior to Callback
ENG
CPU_STRING
“CPU Frequency”
DERIVED_CPU_FREQUENCY “”
SPA
CPU_STRING
“Frecuencia del CPU”
DERIVED_CPU_FREQUENCY “”
String Tokens – After Callback
ENG
CPU_STRING
DERIVED_CPU_FREQUENCY
SPA
CPU_STRING
DERIVED_CPU_FREQUENCY
“CPU Frequency”
“2.2 Ghz”
“Frecuencia del CPU”
“2.2 Ghz”
2.6.2 Multiple Iteration Hardware Interaction
An EFI driver that uses the EFI setup infrastructure will typically carry both IFR and string data. In
some cases, not all the information that is needed is included at build time. For example, a user might
need to add a boot option and to do this they need to select the file from a file system. In this case, the
information is obviously not available at build time, so the information has to be retrieved.
Unlike the previous section which had hardware interaction completed prior to the user ever having
seen any data, this example requires hardware interaction at the user level. In the example of searching
for a file, the driver will have the op-code labeled with a DYNAMIC and INTERACTIVE flag. When
the data is exported to the EFI configuration driver, it calls back to the driver to get the additional data.
21