Introduction to Slim Bootloader

Slim Bootloader (SBL) is an open-source boot firmware built from the ground up for Intel x86 systems. Designed to be small, fast, and secure, SBL offers a modular approach that's particularly appealing for embedded developers working on Intel platforms. (hey, no snickering, yes, "Intel-based embedded platforms" is a thing 😀)  It initializes hardware components upon power-on and then launches a payload—such as U-Boot, an OS Loader, or even a custom module—to boot an OS. Its multi-stage design leverages Intel's Firmware Support Package (FSP) to handle chipset and silicon initialization.

Key highlights:

• Open-Source: Hosted on GitHub, encouraging community contributions
• Modular: Separates hardware init from OS booting via payloads
• Optimized for Intel: Supports processors like Meteor Lake, Arrow Lake, Elkhart Lake, etc.

Features and Advantages:

SBL is engineered with these core principles in mind:

• Small and Fast: Minimal footprint reduces boot times and resource usage
• Secure: Supports cryptographic keys for signing and verification, plus features like firmware updates with integrity checks.  The Intel security features we've come to know and love are supported:  Boot Guard, the ACM, Intel TXT, etc.
• Extensible and Configurable: Uses YAML-based config files for platform configuration, and can integrate custom payloads
• Multiple OS Support: Boots Linux, Windows, or others via payloads
• Firmware Update: Built-in mechanisms for over-the-air or local FW updates

Compared to bulkier options like full UEFI implementations, SBL's lean design is ideal for IoT, edge computing, and real-time (Intel-based) systems.

Architecture and Boot Flow

SBL follows a multi-stage architecture:

Stage	Description
Stage 1A	Pre-memory initialization
Stage 1B	Initialize main memory
Stage 2	Post memory initialization: initialize CPU, I/O controllers, devices etc.
Payload	Load, verify, and launch OS images; or perform firmware update

• Stage 1A: Handles the reset vector, early board init, and calls FSP-T for temporary RAM init (Cache-As-RAM); transitions to protected mode and loads Stage 1B
• Stage 1B: Focuses on memory init via FSP-M, loads/verifies config data, shadows the stage, switches to RAM stack, and loads Stage 2
• Stage 2: Performs silicon init with FSP-S, post-silicon board init, PCI enumeration, ACPI setup, loads/verifies the payload, builds Hand-Off Blocks (HOBs), and jumps to the payload
• Payload: Parses HOBs for platform info, loads/verifies the OS kernel, and jumps to it; payloads can include U-Boot for further flexibility

Graphically:

Configuration

One of the most important design goals of SBL is ease of platform and board customization. All platform configuration settings including memory, silicon, GPIO, OS boot policy, security settings, etc. are declared in a custom format using YAML syntax in a file, CfgDataDef.yaml.  SBL includes a graphical configuration editor tool, ConfigEditor.py, to aid in customizing SBL images.  (neat!)

Board-specific customization can be further defined by .DLT, or "delta" files describing board-specific changes (deltas) from a default set of settings.

Payloads

The goal of the SBL payload stage is to boot a target OS. There are several options:

OsLoader (Built-in)

A versatile linux loader implementation that boots Linux, ELF, UEFI-PI FV, or PE executables. It also supports launching OSes compliant with the MultiBoot specification.

Firmware Update Payload (Built-in)

A special purpose payload to update full boot flash in a secure and fault-tolerant flow.

UEFI Payload (External)

A EDK II based payload implementation to boot Windows. It provides Secure Boot, SMM, and UEFI runtime services.

Custom Payload

SBL supports launching customized payloads that provide user-defined functionality.

Build and Run

To try this out—let's get the source, build it, and run it inside QEMU, the popular emulator.  SBL has dedicated support for QEMU; here are the build steps I followed using Ubuntu 24.04.1 LTS inside Windows Services for Linux (WSL):

1. git clone git@github.com:slimbootloader/slimbootloader.git --recursive
2. sudo apt install -y build-essential python3 uuid-dev openssl gcc-multilib qemu-system git iasl nasm
3. sudo apt install python-is-python3
4. export SBL_KEY_DIR=/home/wdl/sbl_keys/
5. python BootloaderCorePkg/Tools/GenerateKeys.py -k $SBL_KEY_DIR
6. python BuildLoader.py build qemu

Yes, I did have to generate the keys in order to complete the build.

Yes, I did have to install "python-is-python3" to get the build to complete successfully.

Next, to run the SBL image in QEMU:

qemu-system-x86_64 -machine q35 -nographic -serial mon:stdio -pflash SlimBootloader.bin

QEMU started up and I got the debug output on my console: (abbreviated below)

============= Intel Slim Bootloader STAGE1A =============
SBID: SB_QEMU
ISVN: 001
IVER: 002.000.001.001.42262
SVER: F5D93AC58E9C15ED
FDBG: BLD(D IA32) FSP(R)
FSPV: ID($QEMFSP$) REV(00001000)
CPUV: ID(60FB1) UCODE(0)
Loader global data @ 0x00001CC0
Run  STAGE1A @ 0x00070000
Load STAGE1B @ 0x0003E000
HASH verification for usage (0x00000001) with Hash Alg (0x2): Success

============= Intel Slim Bootloader STAGE1B =============
Host Bridge Device ID:0x29C0
Board ID:0x1 - Loading QEMU!
...
Loader global data @ 0x03EBFD00
Load page table from memory @ 0x03EBD000
Switch to memory stack @ 0x03EFFF00
Stage1 stack: 0x2000 (0x1104 used)
Stage1 heap: 0xE000 (0x1FA0 used, 0x31F4 max used)
Call FspTempRamExit ... Success
Memory FSP @ 0x03F00000
Memory TOP @ 0x03700000
Loading Component FLMP:SG02
HASH verification for usage (0x00000002) with Hash Alg (0x2): Success
Loaded STAGE2 @ 0x03E21000

============= Intel Slim Bootloader STAGE2 =============
Unmapping Stage
Board GPIO Init
Get base platform GPIO table from board ID 0
Programming 7 GPIO entries
...
Payload entry: 0x03CA4080
Jump to payload
Payload startup
ACPI PmTimer Base: 0x408
PCI Express  Base: 0xE0000000
====================Os Loader====================

Shell Interface

SBL comes with a built-in shell interface for diagnosis and debugging purposes. It allows one to examine platform state (e.g., dump memory content, PCI configuration registers, etc.), change boot configuration and troubleshoot before launching an OS, analogous to the UEFI shell.  Developers can also add their own shell commands for unit testing.  The default set of commands is:

I played around with all the commands, and they work as you might expect.  I won't reproduce that for you here, but you get the idea—play around with the shell yourself, it's fun!

Conclusion

I hope this article piqued your interest in Slim Bootloader.  Of course, there is much more to dive into, so here are some resources if you'd like to investigate further:

For more details, check out the official Slim Bootloader project page: https://slimbootloader.github.io/index.html

Slim Bootloader on GitHub:  https://github.com/slimbootloader/slimbootloader

Slim Bootloader over at U-Boot:  https://docs.u-boot.org/en/latest/board/intel/slimbootloader.html#