SeaBIOS (Hardware initialization and system boot)

SeaBIOS is a free implementation of the classic BIOS, acting as a layer between the computer hardware and the operating system. Simply put, it wakes up the processor, memory, and devices after power-on, then locates the bootloader on the disk to hand over control to it. This is the software foundation necessary to start the machine before entering the OS kernel.

The main application environment for SeaBIOS is virtual machines, particularly the KVM hypervisor and the QEMU emulator, where it serves as the default standard firmware. Additionally, it can be found on real motherboards with coreboot, where SeaBIOS works as a payload module to support legacy boot modes and ensure compatibility with systems that cannot interact with UEFI.

QEMU (Emulator and hardware virtualizer of a computer)KVM (Turns the Linux kernel into a hypervisor)

Typical problems

Despite its stability, users sometimes encounter the firmware’s inability to detect a bootable device, especially when using non-standard disk controllers or VirtIO images without the appropriate drivers. Another class of issues is related to incorrect PCI resource allocation: devices may conflict or fail to receive memory, leading to hangs during the POST stage. Difficulties sometimes arise with hardware passthrough and keyboard operation in graphical consoles.

Principle of operation

SeaBIOS’s operation begins with code execution at a fixed address when the processor exits the reset state. The initial stage is written in assembly and performs critically important tasks: switching to protected mode, configuring caching, and early initialization of the RAM controller to create the stack needed to run C code. The main part of the firmware, implemented in C, immediately proceeds to power-on self-test, sequentially scanning and initializing the PCI bus, allocating I/O and memory resources among the detected expansion cards, and setting up shadow copies of the video BIOS and its own firmware in RAM to speed up access. After that, additional modules are launched to support network boot, the USB stack, and ACPI tables. The culmination of the process is the boot stage: SeaBIOS iterates through a list of priority devices, attempting to read the first sector from each drive. Upon finding a valid master boot record, it is copied into memory at address 0x7C00, after which the processor is switched back to real mode and control is irrevocably transferred to the operating system bootloader.

SeaBIOS functionality

  1. x86 addressing and execution modes. SeaBIOS supports several memory models that evolved along with the x86 architecture. These include 16-bit real mode, 16-bit protected mode, 32-bit segmented mode, and 32-bit flat mode. Each of these modes requires unique call handling and memory access from the firmware.
  2. 16-bit real mode handling. In this mode, the CPU executes 16-bit instructions by default. SeaBIOS can only address the first megabyte of memory, but this range is fully accessible. BIOS calls are typically initiated through software interrupt instructions int x, and hardware interrupt handling also occurs in this execution context.
  3. 16-bit protected mode support. CPU execution is similar to real mode in terms of instruction width, but segment registers here index descriptor tables. Direct access to physical segment addresses is difficult or impossible. The PCI BIOS, APM BIOS, and PNP BIOS specifications describe documented entry points for this mode.
  4. Legacy call handling in protected mode. Old code may attempt to call standard real-mode entry points while in 16-bit protected mode. The PCI BIOS specification explicitly requires that the legacy int 1a entry point support such calls for its needs. Calls to other legacy entry points in protected mode are not standardized, and SeaBIOS does not support them.
  5. Operation in 32-bit segmented mode. The processor executes 32-bit instructions, but segment registers can have non-zero base offsets and limits. This mode inherits the limitations of 16-bit protected mode, but the key difference is the default instruction width. The code must support relocation, as virtual addresses can vary.
  6. Organization of 32-bit flat mode. This is the mode where the base offset of all segment registers is zero, providing access to the entire 4-gigabyte address space. Although this mode is most convenient for modern compilers, the specifications do not require its mandatory support by the BIOS. SeaBIOS uses it internally for the POST and BOOT phases.
  7. BIOS memory allocation and relocation strategy. During the initialization process, SeaBIOS implements a shadow copying mechanism. Functions like make_bios_writable_intel copy the BIOS image into RAM at lower addresses to speed up access. Interaction with QEMU requires careful placement of code that works with memory layout during the boot phase.
  8. Entry point and symbol marking. To ensure critical initialization code is placed in the area copied by the emulator, the VISIBLE32FLAT marking is used. This tells the linker scripts to place the function, such as handle_post, in the last 128 kilobytes of the BIOS image, which QEMU maps into low memory (the 0xe0000-0xfffff range).
  9. Power-on subsystem initialization (POST). The main initialization phase is launched through handle_post. At this stage, the serial port is configured for debugging, write access to the BIOS area at address 0xf0000 is ensured, hardware is probed, and preparations are made for relocating the main code. Control is then passed to dopost for further startup.
  10. Memory detection and management. The ram_probe function scans for available RAM. Based on the obtained data, malloc_setup initializes SeaBIOS’s internal memory allocator. Custom memory management is necessary for allocating buffers during boot before control is handed over to the operating system.
  11. ACPI table generation structure. SeaBIOS is responsible for creating Advanced Configuration and Power Interface tables. This includes RSDP, RSDT/XSDT for linking pointers, the fixed FADT table with power management data, and the DSDT table containing AML code for device configuration. The pointers between tables are updated dynamically by the firmware.
  12. Interaction with QEMU via the fw_cfg interface. Data exchange with the virtual environment is carried out through the fw_cfg port. This interface allows QEMU to override the standard tables created by SeaBIOS or provide additional SSDTs to describe hot-pluggable devices. Priority is always given to data from the emulator.
  13. Option ROM handling and loading. SeaBIOS implements a two-pass expansion ROM scanning algorithm. On the first pass, option initialization vectors (INIT) are called. On the second pass, boot connection vectors (BCV/BEV) are identified and registered, which are then used to select a boot device and transfer control to it.
  14. PMM specification support. When executing Post Memory Manager (PMM) services, SeaBIOS switches to 32-bit mode. According to the specification, upon returning to real mode, the firmware must restore 16-bit big real mode with segment limits set to 4 gigabytes. This ensures compatibility with clients like iPXE.
  15. PCI configuration and resource allocation. During the PCI bus initialization process, the firmware scans devices and assigns BAR register addresses. In addition to resources, SeaBIOS implements support for 16-bit and 32-bit PCI BIOS entry points for accessing configuration space from operating systems or bootloaders.
  16. Address translation and high memory. To enable access to upper memory from modes with limitations, SeaBIOS implements buffer relocation mechanisms. The BIOS image, larger than 128 KB, is fully mapped at high addresses (0xfff00000) and partially projected into lower memory through internal copying mechanisms. This ensures code availability.
  17. Internal execution architecture. Managing transitions between processor modes is critically important. Switching between 16-bit and 32-bit code requires correct handling of stack frames and segment selectors. For this, SeaBIOS uses wrapper-adapters that ensure call context preservation when handling software interrupts.
  18. Software interrupt handling. The interrupt vector table (IVT) in real mode is filled with pointers to SeaBIOS handlers. Handlers for disk services (int 13h), video (int 10h), and system functions (int 15h) analyze incoming parameters and translate requests into low-level operations with virtual hardware.
  19. Boot device selection algorithm. During the BOOT stage, the firmware iterates through registered BCV and BEV vectors according to the set priority. An attempt to boot from each device is made by reading the Master Boot Record (MBR) or volume boot sector, checking the 0xAA55 signature, and transferring control to address 0x7C00 if successful.

Comparisons

  • SeaBIOS vs Legacy BIOS (AwardBIOS/AMIBIOS). Unlike proprietary implementations, SeaBIOS is modern, actively maintained open-source software, written mainly in C. Although their interaction interface is the same, SeaBIOS does not contain legacy code from the 80s, and its architecture is easier to audit, making it the preferred lightweight solution for virtualization and embedded x86 systems.
  • SeaBIOS vs UEFI (TianoCore/EDK II). The key difference lies in ideology: SeaBIOS focuses on minimalism, security through simplification, and the absence of non-volatile state (NVRAM). UEFI, with its multi-million-line codebase, supports Secure Boot but creates a significantly larger attack surface. SeaBIOS can serve as a Compatibility Support Module (CSM) for UEFI, enabling the booting of legacy operating systems where native support is absent.
  • SeaBIOS vs OpenBIOS. The main difference lies in the target platforms. SeaBIOS implements the BIOS standard for the x86 architecture and serves as the successor to the classic PC BIOS in emulators. In turn, OpenBIOS targets compliance with the IEEE 1275 (Open Firmware) standard and is used in the emulation of PowerPC and SPARC architecture processors.
  • SeaBIOS vs SLOF. Both are lightweight developments but oriented towards different ecosystems. SLOF implements the Open Firmware specification for IBM POWER hardware and is used in the virtualization of the pSeries platform in QEMU. SeaBIOS, meanwhile, is the de facto standard for the x86 architecture in QEMU/KVM, not supporting the Forth-like control constructs of Open Firmware.
  • SeaBIOS vs U-Boot (as payload). SeaBIOS provides a classic PC interface and boots the OS via BIOS calls, while U-Boot, widely used in embedded ARM systems, has been adapted to work with coreboot on x86 primarily for booting Linux and BSD systems without emulating the IBM PC legacy.

OS and driver support

SeaBIOS implements standard BIOS call interfaces (such as INT 13h for disk operations and INT 10h for video), ensuring compatibility with a wide range of operating systems, including Linux, Windows, and DOS; support for modern hardware is achieved through built-in drivers for AHCI controllers, NVMe drives, and a USB stack with UHCI, OHCI, and EHCI modes, allowing OS booting from various disk types without the need to inject specific drivers into the guest system.

Security

Unlike modern UEFI implementations, SeaBIOS does not implement code verification mechanisms such as Secure Boot and deliberately does not block access to BIOS memory areas from bootloader or kernel code, as its security paradigm uses System Management Mode (SMM) exclusively for reliably saving and restoring the full processor state during mode switching, rather than for protecting encryption keys or configuration; this means that in environments without additional hypervisor control, potentially malicious code with kernel privileges (ring 0) can modify executable firmware sections.

Logging

The diagnostic subsystem of SeaBIOS is built on the use of the C function dprintf(), which allows detailed tracing of all boot stages: from PCI device initialization to transferring control to the bootloader; debug message output is implemented through several independent channels — redirection to a serial port when the CONFIG_DEBUG_SERIAL option is enabled, writing to a special QEMU debug port (isa-debugcon), or saving to a coreboot buffer (cbmem), with the level of detail flexibly configured via the CONFIG_DEBUG_LEVEL parameter up to level 8 without the risk of communication channel overflow.

Limitations

Being a classic Legacy BIOS implementation, SeaBIOS is fundamentally limited by the 16-bit execution mode in the initial boot stages and dependence on outdated addressing standards, which prevents it from serving as a full UEFI replacement on physical machines without Compatibility Support Module (CSM) support from the motherboard, and also imposes limitations on booting from drives larger than 2 TB without sector translation; furthermore, its VGA emulation via seavgabios provides only basic register-level compatibility and does not support hardware acceleration of modern GPUs.

VGA (Emulation of legacy VGA register interface)

History and development

The project was founded by Kevin O’Connor in 2008 based on the open BIOS from the Bochs emulator, with the goal of creating a native and easily extensible embedded solution for x86-compatible platforms, written primarily in C using the GNU build system; key development milestones include: version 1.6.3 with AHCI and Xen support, version 1.7.0 with an integrated VGA BIOS, version 1.8.0 with SD card and USB 3.0 support, as well as the constant expansion of compatibility as a coreboot payload and as the standard BIOS for QEMU/KVM hypervisors.

Latest publications