alm

Extremely Simple Firmware Interface

Draft 2, by Alexander Martin and Drew DeVault

Licensed under Creative Commons Attribution-ShareAlike 4.0 International.

The key words must, must not, required, shall, shall not, should, should not, recommended, not recommended, may, and optional in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all bold-face, as shown here.

Abstract

The Extremely Simple Firmware Interface (XSFI) is a standard for a very simple interface between platform boot firmware and operating system bootloaders.

Section 1: Definitions

Boot Firmware: The hardware-specific code responsible for passing control to the operating system after basic hardware initialization.

Boot Program: The non-resident code, 4096 bytes in size, loaded by the Boot Firmware and responsible for loading the rest of the operating system.

Boot Device: A storage device containing a Boot Program at the beginning.

Boot Device List: A list of possible Boot Devices used by the Boot Firmware.

Current Boot Device: The possible Boot Device that the Boot Firmware is currently attempting to boot from.

Boot Tag List: A data structure holding information critical for the boot process.

Boot Tag: An element of the Boot Tag List.

Section 2: Boot procedure

To boot the system, the Boot Firmware shall take the following actions, or functionally equivalent actions:

  1. Collect a list of candidate Boot Devices, the Boot Device List, which may be filtered or ordered according to user preference
  2. Set the Current Boot Device to the first Boot Device on the Boot Device List and skip to step 4.
  3. Advance the Current Boot Device to its successor on the Boot Device List. If none, abort boot and indicate a boot failure.
  4. Attempt to read the first 4096 bytes, composing the Boot Program, from the Current Boot Device. If unsuccessful, return to step 3.
  5. Test if the last two bytes of the Boot Block are the two-byte unsigned integer 0x426c. If not, return to step 3.
  6. Verify that, if present, all requirements specified in the Boot Tag List, as specified in Section 3, are met.
  7. Update the Boot Tags List as specified in Section 3 if any updatable tags are present.
  8. Ensure that all memory is accessible and that maskable interrupts are disabled.
  9. If possible, unmap the Boot Firmware ROM, and any other ROMs that can be safely removed, from the physical address space and replace them with RAM.
  10. Jump to the first byte of the Boot Program.

Section 3: Boot Tag List

The Boot Tag List may be present if permitted by the architecture, and may specify a combination of machine attributes and information required to boot. The Boot Firmware shall ensure that these attributes are met and that the information is provided by updating the contents of the appropriate Boot Tags.

The Boot Tag List shall consist of a series of Boot Tags, each with a header as specified in Table 1.

Table 1: Boot Tag header

Offset (bytes) Size (bytes) Format Meaning
0 1 Unsigned integer Size of tag including header
1 1 Unsigned integer Type of tag

The identifier number of a tag type shall be determined by the annex specifying it. Architecture-specific boot tag types may reuse numbers used in other architectures.

Each Boot Tag shall immediately follow the previous tag, with the first item being at exactly the beginning of the Boot Tag List.

At the end of the Boot Tag List there shall be the following footer:

Table 2: Boot Tag List Footer

Offset (bytes) Size (bytes) Format Meaning
0 2 Native-endianness unsigned integer Size of Boot Tag List or zero
2 2 Native-endianness unsigned integer 0x426c Magic number

Section 4: Annexes

From time to time annexes to this specification will be issued to provide bindings to various architectures and to specify boot tag types. These annexes are available along with this specification.

Vendors must not provide non-standard extensions. All extensions must be published as annexes or amendments to this specification.