As time goes on, though, these reasons for having a CSM will all fade.
In any of these cases, the presence of a CSM makes it easier to install an OS using a bit depth that doesn't match the EFI.įor all of these reasons, having a CSM on your computer is desirable. Normally, this is a problem when installing a 32-bit OS on a system with a 64-bit EFI but a few machines (mostly some very early Intel-based Macs and some modern tablets) have 64-bit CPUs but 32-bit EFIs. The drawback to this setup is that it becomes more difficult to install an OS whose bit depth doesn't match that of the firmware. EFI, on the other hand, is designed to work in the CPU's native bit depth, so a 64-bit computer has a 64-bit EFI, with no switching of bit depth required.
Note that this advantage of a CSM can be important even if you boot your OSes in EFI mode the firmware itself relies on the CSM to display boot-time messages, including the menus created by your boot manager.īIOS-mode boots of modern OSes involve switching the bit depth from the 16-bit code used by the BIOS to the 32- or 64-bit depth used by the OS. To work in native EFI mode, a plug-in card that requires firmware must provide EFI-compatible firmware. Thus, a CSM can be an important feature for certain emergency maintenance tasks.Īnother advantage of the CSM is that it interfaces with the firmware on most plug-in cards that provide firmware, such as most video cards. Also, some emergency tools (especially older ones) can boot in BIOS mode but not in EFI mode. In this context, an "older OS" might include certain BSDs, DOS, Windows XP, OS/2, BeOS, and many other obscure OSes. If you happen to want to boot an older OS, though, BIOS compatibility becomes desirable.
Without a CSM, a modern EFI-based computer is cut off from all BIOS-based OSes, with the exception of OSes that also provide EFI compatibility, such as Windows 7 and later and most modern Linux distributions.Īll but very old versions of Linux can boot using EFI-based boot loaders such as GRUB 2, so BIOS compatibility isn't a compelling feature for a Linux-only computer.
Most OSes released for x86 and x86-64 computers since the mid-1980s assume that the computer has a conventional BIOS similar to the one developed by IBM for its original IBM PC line. In other cases, the user interface is deceptive the selected boot mode is more of a suggestion than a command. In some cases this user interface design is accurate the EFI might create strict one-mode boot pathways. Note, however, that some EFIs' user interfaces present EFI/UEFI and BIOS/CSM/legacy options as if they were mutually exclusive. In fact, as described in more detail shortly, enabling the CSM does not guarantee a BIOS-mode boot. (The sidebar to the right describes an exception to this rule.) When the CSM is enabled, the EFI is still working. It's the CSM (aka "legacy mode") that may be optionally enabled. Some people refer to "enabling EFI support," but that's exactly backwards-on most EFI-based computers, EFI is the native mode. Related to this is the way the CSM interacts with the EFI. An EFI is a fundamentally new type of firmware, though, and if you think of it in BIOS terms, you're likely to apply a lot of BIOS assumptions to EFI that are flat-out wrong. Many people (even manufacturers) refer to EFIs as "BIOSes," but this nomenclature encourages thinking of EFIs in BIOS terms, as if an EFI were a simple add-on to a BIOS. I strongly recommend avoiding such firmware if at all possible.īefore delving into the main points of this page, I'd like to address some common misconceptions. My one experience with such a system, a Gigabyte Hybrid EFI, left me wishing I'd never encountered it. Such implementations generally lack CSMs per se and instead use the BIOS itself for BIOS-mode booting. Note: A partial exception to the rule of EFIs being fundamentally different from BIOSes is some early EFIs for x86-64 computers, which were built atop a conventional BIOS.