The Simple Boot Flag, it turns out, is a bit of a mystery.  Trying to find information about this flag, and/or its associated specification, is quite challenging!  Perhaps that is why it is easy to find people complaining, both Windows users and Linux users alike, about the Simple Boot Flag changing their machine's boot process in ways they don't like.  My goal in this post is to provide an overview of this technology and a link to the specification.


Microsoft introduced the Simple Boot Flag Specification around 2001, and the latest version is v2.1, from 2005.  The goal of this initiative is to coordinate characteristics of the boot process between BIOS and the OS Loader.  Specifically:
  • Determining when to run diagnostic tests during boot
  • Determining whether to configure hardware resources for devices
For example, in the early days of the PC industry, the hardware was unreliable to the point that it was good practice to run a self-test at every boot.  Modern hardware is much more reliable, and so spending time at boot running self-tests is a waste of time.  Moreover, in the old days BIOS was required to setup hardware resources (e.g. interrupts, MMIO, I/O ports).  Today, modern OSes do this themselves, and so having BIOS spend time sorting out resources, which then get reassigned once the OS loads anyway, makes no sense.  The Simple Boot Flag is the means of communication between BIOS and the OS Loader to make a decision on what needs to be done from boot to boot in terms of diagnostic tests and hardware configuration.

The Simple Boot Flag is a one byte bitfield, implemented as either a CMOS register location or as an NVRAM variable.  Sample implementation:
    UINT8   PnpOs : 1;
    UINT8   Booting : 1;
    UINT8   Diag : 1;
    UINT8   SuppressBootDisplay : 1;
    UINT8   Reserved : 3;
    UINT8   Parity : 1;
The flag provides a mechanism for the operating system to communicate back to the firmware what actions need to be taken on the next boot.  For example:
  • should the BIOS configure the hardware resources for installed devices, or leave it up to the OS?
  • was the previous boot successful?  if not, perhaps diagnostics should be run to fix the issue?
  • should BIOS maintain control of the display, or is it okay for the OS Loader to take control?
The best way to summarize the goal of this flag is to define the bitfield communicated between BIOS and the OS Loader via this table:

BOOT Table

Microsoft also specifies an ACPI table to assist Windows in finding the location of the Simple Boot Flag.  Note that this is Windows-specific, and so you won't find it in the ACPI Specification.  The Linux kernel does not support this table.  For reference:

Downloading the Spec

Trying to find the spec is challenging, mainly because the official Microsoft link is no longer working.  I've put v2.1, which I believe is the latest, here for reference.

Please take a look at this (small) spec for complete information—it's only 6 pages long.

If there's something I missed regarding the Simple Boot Flag, please leave a comment.  Thanks for reading!

Post a Comment

  1. Although Microsoft specified the two methods, CMOS and EFI variable, in their Simple Boot Flag spec, they only implemented CMOS. Windows, even in UEFI mode, sets the Boot register in CMOS rather than the EFI Variable.
    Perhaps this feature would have received broader acceptance if they had added this feature to the industry ACPI spec, and then maybe someone would have found the problem earlier.

  2. Thank you Allen, agree 100%.

  3. Thanks for this article, William, I look forward to more.


Be sure to select an account profile (e.g. Google, OpenID, etc.) before typing your comment!