Existing boot methods glossary

Boot on embedded systems is undergoing standarisation. This glossary brings together information on various initiatives.



Embedded Base Boot Requiements EBBR is a boot and runtime firmware services specification for embedded boards. It defines the boot process so that one kernel image works on multiple boards.

The platform firmware must be UEFI-compatible, with some features omitted (the full list appears in the EBBR specification). For example, graphical console, PCI or USB are not required. On the other hand, it requires a console device.

The hardware description is defined by the platform firmware and exposed to the bootloader and the operating system using ACPI or Devicetree (flattened Devicetree Blob, DTB), but not both.

Secure boot is optional and, if present, should be conform with UEFI Secure Boot.

UEFI runtime provides service before and after the boot services. However, the services available at runtime are restricted. Also, devices of the platform are controlled by the firmware, or the OS, but not both at the same time (except of devices explicitly providing concurrent access).

Firmware update is mandatory, either in-band (firmware updates itself), or out-of-band (by a BMC or hypervisor). Firmware storage should be separate from the OS storage (physical device, or a logical unit). If they need to be stored on the same device, firmware must be placed in a way that does not cause conflicts with OS partitioning, and the operations of the OS should not interfere with the firmware files. If firmware does not have a dedicated access to the storage, it needs to proxy the accesses to the OS.

The example implementations of EBBR are U-Boot with Linux or Tianocore/EDK2 with Linux.

EBBR is designed for platforms that could not support SBSA/SBBR specifications for server-level devices.

1 Like