Customizing UEFI BDS Phase Boot Splash Logos

This article provides an overview of how system integrators and Original Equipment Manufacturers (OEMs) replace the standard firmware logo with a custom boot splash during the UEFI Boot Device Selection (BDS) phase. It covers the firmware architecture responsible for rendering graphics, image format constraints, integration methods via source code or vendor binaries, and the handoff mechanism to the operating system using ACPI tables.

During the UEFI boot sequence, the Boot Device Selection (BDS) architectural phase executes after the Driver Execution Environment (DXE) initializes platform hardware. The BDS phase is responsible for connecting consoles, locating boot targets, and rendering the platform splash screen via the Graphics Output Protocol (GOP). System integrators customize this visual experience using three primary approaches: source tree integration, Independent BIOS Vendor (IBV) utility modification, and ACPI table population for operating system continuity.

Image Format and Constraints

Regardless of the integration method, the UEFI specification and display drivers impose strict limitations on the splash image:

  • File Format: Typically an uncompressed 24-bit or 32-bit Windows Bitmap (.bmp). Run-length encoded (RLE) or compressed bitmaps are generally unsupported by standard UEFI GOP decoders.
  • Dimensions: Images are constrained by the native resolution of the platform's target panel or standard fallback resolutions (such as 1024x768 or 1920x1080).
  • Color Depth and Padding: Bitmaps must adhere strictly to 4-byte boundary row padding to prevent visual artifacts or memory misalignment during blitting operations.

Method 1: Source-Level Customization (EDK II)

Integrators compiling firmware directly from an open-source EDK II base or an OEM code repository modify the image asset within the platform's package space:

  1. Locate the Asset: The default logo resides within the platform's module package, historically at MdeModulePkg/Logo/Logo.bmp or within a vendor-specific directory like PlatformPkg/Logo/.
  2. Firmware File System (FFS) Definition: The logo is declared in the package description file (.dec) and component description file (.inf) as a raw binary asset within a Firmware Volume (FV).
  3. BDS Blit Execution: The BDS driver—specifically within the PlatformBootManagerLib or BdsDxe—calls EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() to transfer the decoded pixel buffer directly to the display frame buffer. Modifying the C code allows integrators to specify precise horizontal and vertical offsets to center the logo.

Method 2: Post-Build Binary Injection (IBV Tooling)

When working with compiled firmware binaries supplied by IBVs such as AMI (Aptio), Insyde (InsydeH2O), or Phoenix (SecureCore), integrators use proprietary binary modification utilities rather than rebuilding from source:

  1. AMI ChangeLogo: Integrators open the target .ROM or .CAP file in the utility. The tool scans the Firmware Volume for the specific GUID assigned to the splash logo FFS file (such as the default AMI splash GUID). The user imports the new bitmap, and the tool replaces the raw data section while automatically recalculating checksums.
  2. Insyde H2OLogo: Similar to AMI’s solution, this tool allows integrators to inject multiple resolutions of a splash screen to support different display aspect ratios.
  3. Firmware Integrity: If the target platform enforces Intel Boot Guard or AMD Hardware Validated Boot, any post-build modification to an existing binary must be re-signed using the OEM’s private key to ensure the Root of Trust remains unbroken.

Method 3: Seamless OS Handoff via the ACPI BGRT

Displaying the logo during the BDS phase is only the first half of the process; modern platforms require a seamless transition into the operating system loader. This is governed by the Boot Graphics Resource Table (BGRT) defined in the ACPI specification.

During the BDS phase, the firmware driver:

  1. Allocates a runtime memory buffer of type EfiBootServicesData or EfiACPIReclaimMemory.
  2. Copies the uncompressed in-memory bitmap into this buffer.
  3. Populates the ACPI BGRT structure with the memory address, image orientation, and X/Y screen coordinates.
  4. Publishes the BGRT into the system's ACPI table array.

When an operating system such as Windows or Linux boots, its boot loader reads the BGRT, verifies the memory address, and keeps the BDS splash logo static on the screen while superimposing its own loading animation. If the BDS phase fails to configure the GOP correctly or passes an invalid memory pointer in the BGRT, the operating system discards the boot splash and defaults to a standard fallback display.