What Is TSL?

Explains TSL in UEFI: when the boot loader runs, still uses Boot Services, and prepares for ExitBootServices.

October 28, 2025 Updated June 19, 2026 3 min read

Key idea

TSL, short for Transient System Load, is the period where the operating system boot loader is running, but firmware has not fully handed control to the OS yet.

In the UEFI flow, TSL comes after BDS. BDS selects a boot option, loads the boot loader with LoadImage(), and starts it with StartImage(). From the firmware side, the system enters TSL once the boot loader begins execution.

Where TSL sits in the boot flow

A simple view is:

Reset Vector -> SEC -> PEI -> DXE -> BDS -> TSL -> ExitBootServices -> OS Runtime

TSL is not a standalone firmware phase like PEI or DXE. It is the window where the boot loader still uses UEFI services to prepare the kernel, memory map, initrd, ACPI table pointers, and other OS handoff data before calling ExitBootServices().

What the boot loader can still use

During TSL, the boot loader can still call Boot Services.

Common examples include:

GetMemoryMap()
AllocatePages()
AllocatePool()
LocateProtocol()
HandleProtocol()
LoadImage()
StartImage()
ExitBootServices()

That is why some boot bugs only appear when moving from the boot loader to the kernel, even though DXE and BDS looked normal.

Common confusion

TSL does not mean the OS is fully running. The kernel may already be loaded into memory, but firmware Boot Services still exist until ExitBootServices() succeeds.

TSL should also not be confused with BDS. BDS is firmware choosing the boot target. TSL is the boot loader preparing the OS.

Link to the memory map

A key job in TSL is obtaining the final memory map.

The boot loader usually calls GetMemoryMap(), receives a MapKey, then passes that same MapKey to ExitBootServices().

If allocation, logging, file I/O, or a protocol call changes the memory map between those two calls, ExitBootServices() may return EFI_INVALID_PARAMETER.

What to check when debugging

If the machine loads the boot loader but never reaches the kernel, split the failure by these checkpoints:

Boot#### selected?
Device Path connected?
LoadImage() success?
StartImage() success?
Boot loader got memory map?
ExitBootServices() success?
Kernel entry reached?

The first checkpoint without a log usually defines the search area.

Practical bug example

A boot loader adds debug output after calling GetMemoryMap(). That log path allocates another buffer, which invalidates the old MapKey.

The result is ExitBootServices() failure, but the bug disappears when the debug log is removed. This is a classic TSL debugging trap.

Source-reading checklist

When reading source around TSL, check:

- Where does the boot loader get the memory map?
- Is there any allocation after GetMemoryMap()?
- Does ExitBootServices() retry correctly?
- Are LoadImage() and StartImage() logged separately?
- What memory types hold ACPI pointers, initrd, and kernel command line?
- Is any Boot Services API used after ExitBootServices()?

Conclusion

TSL is the transition area between firmware boot policy and OS runtime. The boot loader can still use UEFI Boot Services, but its goal is to prepare the final handoff, call ExitBootServices(), and jump into the kernel. For difficult boot bugs, TSL is where memory map handling, MapKey, LoadImage(), StartImage(), and kernel handoff should be checked carefully.

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.

Đọc blog Xem notes khác