Early Splash Screen Using U-Boot

## Overview

This talk by D Tucker and Nikil from Texas Instruments covers the implementation of early splash screens in U-Boot, the open-source bootloader for embedded systems. The presentation walks through the boot flow, splash screen framework, and provides practical guidance for adding splash screen support to custom display controllers and panels at both the U-Boot proper and SPL (Secondary Program Loader) stages.

## Key Topics

**Boot Flow and Architecture** A bootloader prepares the environment for the operating system by initializing DDR and peripherals. The boot sequence consists of ROM bootloader (hardcoded firmware), SPL (Secondary Program Loader), U-Boot proper (full-featured bootloader running from DDR), and finally the Linux kernel. Traditionally, splash screens were only supported at the U-Boot proper stage, the third stage in the pipeline.

**Splash Screen Framework** Splash screens are introductory images displayed during device boot, providing branding and user feedback that the device is powering on. The framework requires enumeration of display controller and panel configuration parameters in device tree files, compile-time configuration options (Kconfig), board environment variables (splash file, splash image, splash position, splash source), and driver model abstraction through the video uclass.

**Early Splash Screen Innovation** Early splash screen adds support at the SPL stage, making splash screens appear approximately 2 seconds faster. It also enables Falcon boot mode where U-Boot proper can be skipped entirely, with the splash remaining persistent. The implementation requires calling video reserve and splash display functions manually in board-specific files rather than relying on automatic framework calls.

## Technical Details

**Memory Management** U-Boot's board initialization sequence reserves memory regions for video frame buffer, page tables, and trace buffers. Memory reservation starts from the top of RAM and grows downward. The video reserve function calculates memory needed based on display format and frame buffer size.

**Driver Implementation Steps** 1. Add display controller driver as uclass video with compatible strings, driver macros, and required methods (bind, probe, remove) 2. Add panel driver using uclass panel or the existing simple panel driver 3. Configure device tree nodes with register regions, ports, and panel timing parameters 4. Define build support through Kconfig and Makefile entries 5. Enable splash screen configurations in board defconfig 6. Define splash locations with metadata for storage (raw memory or filesystem) 7. Set environment variables for splash file, image address, position, and source

**Persistent Display and Flicker-Free Transition** To prevent splash screen flicker between SPL and U-Boot proper, the framework uses BLOBs (Binary Large Objects) to store and pass frame buffer information between boot stages. When video reserve is called in U-Boot proper, it checks for existing blob data and reuses the reserved region rather than reinitializing. For Linux kernel transition, the frame buffer region is either reserved statically or dynamically updated in the device tree passed to Linux.

**Testing Approach** Developers can use commands like `dm tree` to view driver status, `board info` to check frame buffer allocation, and `bmp display` to test image rendering after loading images via `fatload`.

## Takeaways

- Early splash screens at SPL stage significantly reduce boot-to-display time - Proper memory mapping understanding is critical to prevent SPL crashes - Driver model provides platform-independent abstraction for display hardware - Device tree configuration enables hardware enumeration without recompilation - BLOBs provide clean data transfer between boot stages - Persistent splash requires coordination between U-Boot stages and Linux kernel to avoid frame buffer conflicts