Debug Support for Unified EFI Bootloader
Supported UEFI versions
The Unified Extensible Firmware Interface (UEFI) is the successor to the traditional PC BIOS. It manages the reset and startup of the system plus the selection and booting of an OS. In contrast to the standard BIOS, UEFI is capable of dynamically loading and starting drivers. Those drivers then do not need to be installed into the OS; they're instantly available after booting.
UEFI runs through several different phases while booting the system:
Lauterbach's extension to TRACE32 supports the debugging of UEFI BIOS implementations through all phases with special windows, functions and prepared scripts. TRACE32 is aware of multicore environments allowing UEFI debugging even on SMP systems. As all of these features are based on the symbol information, there's no need for special debugging software or drivers on the target system.
Debugging from Reset Vector
TRACE32 is a JTAG-based debugging tool and, as such, allows the user to start debugging their chip right from the reset vector. It is possible to walk through the very first steps of the start-up to detect FLASH problems or faulty reset behavior and then enter the security phase.
Security Phase (SEC)
Within the Security phase the microcode table can be examined to ensure correct loading and to check all verifying processes. After the Security phase completed successfully, the Pre-EFI Initialization phase starts.
Debugging SEC (here: the code for x86 microcode update)
List of all available microcodes
Pre-EFI Initialization Phase (PEI)
With TRACE32 the PEI core and all loaded PEI modules can be debugged. The debugger provides several additional displays. Firmware volumes known to the system can be viewed and each can be viewed in more detail. Moreover, the dependencies of each module can be checked within a volume. The generated Hand-Off Blocks (HOBs) can also be displayed. TRACE32 provides special functionality for debugging the PEI modules. First, a window shows all PEI modules with their addresses and development files. Any PEI module can be specified and TRACE32 will wait for it to be loaded and will catch this module right on it's entry point.
Display of firmware volumes
Detailed view of a firmware volume
Display of Hand-Off Blocks
List of Pre-EFI Initialization phase modules
Driver Execution Environment (DXE)
After switching from the Pre-EFI Initialization phase into the Driver Execution Environment phase similar features are available for the DXE core and DXE drivers. In addition to the HOB and firmware volume displays already available from the PEI phase TRACE32 displays the DXE configuration table. DXE drivers are loaded and started dynamically. A special window shows all drivers that were already loaded into the system. For debugging a driver, after specifying a driver name, the debugger waits for the driver to be loaded and started; giving developers the ability to debug it from the entry point in the same way as for PEI modules.
DXE configuration table
List of all loaded DXE drivers
Boot Device Selection (BDS)
The Driver Execution Environment phase passes control to the Boot Device Selection phase. This part of the BIOS can also be debugged with TRACE32, allowing users to check the device lists, single step through the legacy BIOS calls, watch the user selection of the boot device and walk into handover to the OS.
Operating System Loader
After the Boot Device Selection phase has passed control to the OS loader UEFI has completed. However, debugging may not yet have ended. TRACE32 assists debugging through the OS loader and boot phase, e.g. when initializing and enabling the OS specific MMU. Even after this, the debugger provides special target-OS awarenesses for example on Linux, QNX, Windows CE, etc. The developer is then able to debug the kernel, drivers and applications of those OSes – but this is now beyond the scope of this article.
Using TRACE32 to debug the chip gives developers the ability to debug the UEFI BIOS easily, supporting each of it's phases. Start debugging right from the reset vector and continue debugging even into the OS and it's applications. Now there's a continuous solution without any "debug gaps".
Copyright © 2022 Lauterbach GmbH, Altlaufstr.40, 85635 Höhenkirchen-Siegertsbrunn, Germany
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice. Report Errors
Last generated/modified: 04-Apr-2022