-
Notifications
You must be signed in to change notification settings - Fork 0
UEFI PI_FAQ
More information: UEFI-and-PI-Wiki | PI Boot Flow | PI
Frequently asked Questions about UEFI/PI
Build questions
Depex FAQ questions
GPT FAQ questions
GUID FAQ questions
HII questions
PEI questions
Shell questions
UEFI application questions
The Implementation may seem like it is revolutionary since it is now in “C” instead of Assembly but once the structure of UEFI is understood it is then easier to see how UEFI is doing some of the same work as Legacy BIOS. In fact, the UEFI implementations are done with software design structures in mind.
Two other notes on this:
- UEFI / PI accounts for legacy BIOS through the CSM
- UEFI was originally a layer built on top of legacy bios giving the interfaces for UEFI option ROMs and UEFI Drivers.
Currently there is support for the Intel X86 Family (IA32 and X64) as well as the Intel® Itanium® Processor Family (IPF). Other companies are supporting the ARM processor
Currently over 50% maybe somewhere above 70% as of 2010
Yes, the UEFI SCT User Guide has a section (5.3) on how to add test cases to the SCT. The SCT releases can be downloaded from http://uefi.org
The UEFI and PI specifications define many useful protocols available to be consumed by developers. If you are writing a driver there may be other protocols that your diver will produce. In general protocols are function calls with a well defined interface from either the UEFI or PI specifications.
Boot services are available only until ExitBootServices() is invoked. Whereas Runtime services are available during boot and after ExitBootServices().
Runtime services are intended to provide additional support to the OS after the pre-boot environment is no longer relevant. SMM code on Intel Processors is considered Runtime code, by its very nature(it is not feasible to remove SMM code from SMM space one established. Ergo SMM code will remain resident after ExitBootServices().
The SMM runtime services are similar to the DXE foundation but SMM libraries would only contain SMM code.
SMM code on Intel Processors is considered Runtime code, by its very nature(it is not feasible to remove SMM code from SMM space one established. Ergo SMM code will remain resident after ExitBootServices().
There are no tools to help convert a Legacy Option ROM sources or binaries to a UEFI complaint driver. Once a UEFI complaint driver is designed and implemented, it may be cross compiled to EBC. There are some compatibility issues that the UEFI driver writer must be aware of in order to implement a UEFI driver is C that is compatible with native mode compilers as well as the EBC compiler. Chapter 19 of the EFI Driver Writers Guide at http://developer.intel.com/technology/efi/dg.htm describes the porting considerations when using the EBC compiler.
Yes, per the PI Spec the UEFI / PI firmware goes through the following phases:
- Sec – Security phase – Set up Temp memory
- PEI – Pre-EFI – Initialize Memory
- DXE – Driver Execution – Dispatch list of UEFI / DXE drivers
- BDS – Boot Device Selection –Run Setup
- TSL- Transient System Load – Run EFI Shell
- Runtime boot to the OS – Execute the OS loader
No, PI stands for Platform Initialization and the original Intel® Platform Innovation Firmware for UEFI Specification it evolved into the Platform Initialization (PI) Specification. PI describes the boot execution phases to encompass UEFI supported protocols and services.
There are UEFI defines services and there are PI Services. Do any of these services overlap and are there services?
The PI services are a super set of services so that the UEFI Services are all part of PI services. In addition there are some PEI services specific to PEI since PEI is not executing out of memory.
UEFI events are constructs that are used to provide communication between UEFI modules.
Timer events are asynchronous. All other event types are synchronous.
UEFI Events are managed through UEFI Services. UEFI Events can be created and destroyed and are either in the waiting state or the signaled state. An UEFI image can do any of the following:
- Create an event.
- Destroy an event.
- Check to see if an event is in the signaled state.
- Wait for an event to be in the signaled state.
- Request that an event be moved from the waiting state to the signaled state.
Every event will have a Task Priority Level (TPL) associated with it. The TPL levels are
- TPL_APPLICATION
- TPL_CALLBACK
- TPL_NOTIFY
- TPL_HIGH_LEVEL
Instead, UEFI supports polled drivers. The most common use of events by an UEFI driver is the use of timer events that allows drivers to poll a device periodically. So any device I/O is done through polling.
Discovery, yes but typically a UEFI Platform will only program these if it is going to boot a legacy OS. This resource information is however, discovered during PEI and DXE. It would later handshake to the OS through the CSM. Much of this is done at the platform level through the ACPI data structures.
How does UEFI know which is the boot device, so it can enumerate it? What if there is no user intervention?
The Boot devices are determined by the UEFI boot manager. The UEFI boot manager is a firmware policy engine that can be configured by modifying architecturally defined global NVRAM variables. The first boot device, is typically set by OEM, is in the UEFI NVRAM Variable BootOrder
No, C++ has a larger footprint, and the UEFI environment does not support constructors and destructors. The “C” code can be used to do similar C++ things by writing specific algorithms in C. There is No C++ support. However, you can use C++ code as long as there are no global objects—do not use new .
For Intel X86 Processors early in the SEC phase the MTRRs are set up to define the stack just under 4G but in cache. The processor is then set to “No Eviction Mode”. Then the Stack pointer (SP) is set to a location in this memory.
This allow the Cache to be used for Data accesses, as if there were RAM at those addresses. The cache is not “flushed” (no eviction). When RAM is available, the cache can be evicted into the physical RAM space assigned for cache, thus providing a ‘seamless’ context change of CAR to RAM mode.
On Intel Itanium® Processor Family (IPF) Servers with Firmware interface table FIT – a table at an architected location pointing to pal & sal components is it similar?
FIT on IPF is architectural. It is described in the public SDM for IPF. Describes the location of PAL/SAL. It is not related to NEM.
The PI PEI core foundation already has a mechanism for handling multiple FVs. Multiple FVs is platform specific and would be described in a platform’s FDF file.
A platform specific PEIM has to declare the location of additional FVs for them to be known to the PEI Core. Once they are declared to the PEI Core, the PEI Core can dispatch PEIMs from them. The only FV that is known to the PEI Core when it is started is the Boot Firmware Volume (BFV). The BFV contains SEC and the PEI Core and one or more PEIMs.
Yes, this is maybe a platform policy and it would be platform policy of the mechanism for using the FVs for redundancy. That mechanism is not scoped within the PI spec.
Just 64bit address space . . .
TSEG would be platform specific and this information is passed in some HOB, EFI_SMRAM_HOB_DESCRIPTOR_BLOCK.
The method is really Implementation dependant, but in Intel architectures it models an 8254 timer API
Yes.
SOR Stands for Schedule On Request. If the SOR opcode is present in a DXE driver’s dependency expression, then the DXE driver is placed in the “Unrequested” state. If the SOR opcode is not present in the DXE driver’s dependency expression, then the DXE driver is placed in the “Dependent” state
When SOR is present, the module will not be executed until another driver specifically requests that driver to be run. This is done through the DXE Service called Schedule(). See PI 1.2 DXE CIC Section 7.3
It depends on NMI is mapped in the platform. In the PC environment, the NMI is part of the standard hardware interrupts of the processor. In fact, the support hardware of a PC can actually disable the NMI source through the chipset (so much for “non-Maskable Interrupt”). It was the need for a truly non-Maskable firmware managed interrupt that brought about the SMI system.
SMM Drivers are dispatched by the SMM Core during the DXE Phase. So additional SMI handlers can be registered in the DXE Phase. Late in the DXE Phase, when no more SMM drivers can be dispatched, SMRAM will be locked down (as recommended practice). Once SMRAM is locked down, no additional SMM Drivers may be dispatched, so not additional SMI handlers can be registered. For example, an SMM Driver that registers an SMI handler cannot be loaded from the EFI Shell or be added as a DriverOption in the UEFI Boot Manager.
No, in the UEFI spec.
- FV Recovery
- Ftw Spare Space
- Ftw Working Space
- Event log
- Microcode
- Variable Region
- FV Main
Flash device FD –> FV -> FFS -> EFI Files. Multiple EFI Sections are combined into a Firmware file (FFS) which consists of zero or more EFI sections. Each FFS consists of a FFS header plus the data One or more FFS files are combined into a Firmware Volume (FV.) One or more FV would be listed as part of the Flash Device
The flash layout is defined in the .FDF file for the platform
The BDS phase is part of the PI spec. and it is responsible for implementing the platform boot policy. However, the BDS phase System firmware that is compliant with the PI specification must implement the boot policy specified in the Boot Manager chapter (chapter 3) of the UEFI 2.x specification
Currently Win 7 still requires CSM for blue screen and Win 7 installations. Microsoft has indicated that there will be a fix in Win7 sp2
FV contained inside one or more flash devices.
The EFI_BLOCK_IO_PROTOCOL abstracts mass storage devices to allow code running in the UEFI boot services environment to access them without specific knowledge of the type of device or controller that manages the device. Functions are defined to read and write data at a block level from mass storage devices as well as to manage such devices in the EFI boot services environment. To contrast, the EFI_DISK_IO_PROTOCOL is used to abstract the block accesses of the Block I/O protocol to a more general offset-length protocol. The firmware is responsible for adding a EFI_DISK_IO_PROTOCOL to any Block I/O interface that appears in the system that does not already have a Disk I/O protocol. File systems and other disk access code utilize the Disk I/O protocol
Disk I/O provides byte level access to a disk.
Within the boot execution phase the UEFI firmware will assign a handle as each image is loaded. If something changes in the configurations then that may cause a different handle number to be assigned to the same driver. However, it is likely to be the same on each boot if nothing changes from boot to boot.
UEFI and OS need to be in the same mode—32 bit or 64 bit
Yes, Join the Sourceforge and sign up for the developer for EDK II. https://sourceforge.net/projects/edk2/develop and subscribe to the mailing lists. Get involved with the UEFI Forum at http://www.uefi.org
There are new tools for EDK II. The PI Specification for firmware Volumes (FV) and FFS is different than the Framework .9 Specification FV and FFS. EDK II is using the PI Spec FV and FFS. The old tools can only work on EDK I that use the Framework .9 Spec. VolInfo is a utility which displays the contents of a firmware volume residing in a file for informational purposes. Command line in Basetools/Bin/Win32
Is there a mechanism to sign components and is there a tool to determine which components are signed?
There is a mechanism in EDK II that is utilizing the encapsulation section in the PI spec. The Encapsulation Section for a FV can be used for different things such as compression, signing and for encryption. The support in the build tools for EDK II is PI 1.2 Spec. so if signing is needed then the Build tools for EDK II will work Single FFS with a signed section Example – in EDK II – Tiano compress and LZA compression – There are GUIDs in the FDF file You can define a new GUID for a new encapsulation type. Encode/ Decode operations. When the platform needs to decode there will be a library to perform the decode.
There are no hardware interrupts in EFI. All that exists is a timer.
Basically you use the CreateEvent() boot service to make a timer event, and then you do a SetTime() boot service call to program the period and type of the event. You can pass a Notify function and context pointer that will be passed to your Notify function when you do the CreateEvent().