SetupDesignGuide.pdf - Firmware Encoding Index

Setup Design Guide
DRAFT
6
Setup Driver Considerations
6.1 Pre-boot Operation versus Runtime Operation
Due to the static nature of the data contained in the HII Database and the capacity to update NVRAM
variables, the pre-boot configuration data can be effectively used during O/S runtime. This allows the
same configuration mechanisms to be used in pre-boot as well as in runtime.
Some thought needs to be given when designing the overall requirements associated with a setup
application with regards to the type of data that is needed and it’s hardware interaction requirements.
For additional information about hardware interaction see section 2.6. If some of the questions
associated with a setup environment require a high level of hardware interaction, it might make sense to
design the user interface flow in the VFR such that these types of questions are isolated. The reason for
this is that when this data is exported to a runtime presence, it may not make any sense in that
environment. For instance if there were a page which contained some diagnostic type of interactions
which are not reasonable in a runtime environment the user experience of that page may not be
desirable.
6.2 How to allocate and steer data to NV storage
The file which contains the global data primarily consists of a series of #define values and the definition
of the NV mapping descriptors. This file is intended to be used as an include file both for VFR
purposes as well as a ‘C’ syntax include file for drivers that are built to support the EFI setup
infrastructure.
There NV mapping descriptors take the form of structure declarations in this definition file. Each piece
of data that can be changed in the configuration needs to be saved. For each of these data items, there
will be a structure member.
To support the ability to store data in multiple physical locations, one needs to be able to specify which
data items will reside in which NV storage location. A common scenario would be that a developer
might have the results of many questions reside in the systemboard NVRAM, yet some of the questions
might reside in another NV storage location. To differentiate between which is the system store and
which is the alternate store the VFR_NV_KEY macro is used in the structure definition.
The VFR compiler will read the structure that has the macro with a 0 input as the system store
descriptor. All structures with non-zero macro inputs are going to be considered to be non-system
storage descriptors.
A sample VFR entry which declares a system NV store descriptor might look like the following entry:
nvstorage
handle = NULL,
devicepath = NULL,
key = NvRamMapKey;
A sample VFR entry which declares a non-system NV store descriptor might look like the following
entry:
nvstorage handle = 1,
44