Bootloader

Last updated
GNU GRUB, a popular open source bootloader GRUB v2.12 screenshot, Fedora 41.png
GNU GRUB, a popular open source bootloader
Windows Boot Manager Windows Boot Manager with Windows 7,Vista and XP.png
Windows Boot Manager

A bootloader, also spelled as boot loader [1] [2] or called bootstrap loader, is a computer program that is responsible for booting a computer and booting an operating system. If it also provides an interactive menu with multiple boot choices then it's often called a boot manager. [2]

Contents

When a computer is turned off, its software‍—‌including operating systems, application code, and data‍—‌remains stored on non-volatile memory. When the computer is powered on, it typically does not have an operating system or its loader in random-access memory (RAM). The computer first executes a relatively small program stored in the boot ROM, which is read-only memory (ROM, and later EEPROM, NOR flash) along with some needed data, to initialize hardware devices such as CPU, motherboard, memory, storage and other I/O devices, to access the nonvolatile device (usually block device, e.g., NAND flash) or devices from which the operating system programs and data can be loaded into RAM.

Some earlier computer systems, upon receiving a boot signal from a human operator or a peripheral device, may load a very small number of fixed instructions into memory at a specific location, initialize at least one CPU, and then point the CPU to the instructions and start their execution. These instructions typically start an input operation from some peripheral device (which may be switch-selectable by the operator). Other systems may send hardware commands directly to peripheral devices or I/O controllers that cause an extremely simple input operation (such as "read sector zero of the system device into memory starting at location 1000") to be carried out, effectively loading a small number of boot loader instructions into memory; a completion signal from the I/O device may then be used to start execution of the instructions by the CPU.

Smaller computers often use less flexible but more automatic boot loader mechanisms to ensure that the computer starts quickly and with a predetermined software configuration. In many desktop computers, for example, the bootstrapping process begins with the CPU executing software contained in ROM (for example, the BIOS of an IBM PC or an IBM PC compatible) at a predefined address (some CPUs, including the Intel x86 series, are designed to execute this software after reset without outside help). This software contains rudimentary functionality to search for devices eligible to participate in booting, and load a small program from a special section (most commonly the boot sector) of the most promising device, typically starting at a fixed entry point such as the start of the sector.

First-stage boot loader

Examples of first-stage bootloaders include BIOS, UEFI, coreboot, Libreboot, and Das U-Boot. It initialize hardware devices such as CPU, motherboard, memory, storage and other I/O devices.

Second-stage boot loader

Second-stage boot loaders, such as GNU GRUB, rEFInd, BOOTMGR, Syslinux, and NTLDR, are not themselves operating systems, but are able to load an operating system properly and transfer execution to it; the operating system subsequently initializes itself and may load extra device drivers.

Second-stage implementations can include interactive user interfaces, allowing boot option selection and parameter modification. They handle kernel loading, including processing of initrd/initramfs images, and can pass boot parameters to the kernel. Many implement modular designs supporting loadable modules for additional functionality. These choices can include different operating systems (for dual or multi-booting from different partitions or drives), different versions of the same operating system (in case a new version has unexpected problems), different operating system loading options (e.g., booting into a rescue or safe mode), and some standalone programs that can function without an operating system, such as memory testers (e.g., memtest86+), a basic shell (as in GNU GRUB), or even games (see List of PC booter games). [3] Some boot loaders can also load other boot loaders; for example, GRUB loads BOOTMGR instead of loading Windows directly. Usually, a default choice is preselected with a time delay during which a user can press a key to change the choice; after this delay, the default choice is automatically run so normal booting can occur without interaction. They may also handle compression, cryptographic verification, and chain-loading of other bootloaders. The boot process can be considered complete when the computer is ready to interact with the user, or the operating system is capable of running system programs or application programs.

IBM-compatible personal computers

Legacy BIOS

In x86 computers, after the BIOS executes Power-On Self Test, then a first-stage bootloader is a compact 512-byte program that resides in the master boot record (MBR) is executed. Running in 16-bit real mode at address 0x7C00, it locates the second-stage bootloader. Its primary challenge lies in accomplishing these tasks within strict size constraints while handling potential hardware failures. The bootloader must navigate disk structures, often implementing FAT file system support, and manage the delicate transition from the BIOS startup state to a stable environment for the next boot stage.

First-stage MBR boot loaders may face peculiar constraints, especially in size; for instance, on the earlier IBM PC and compatibles, a boot sector should typically work with 510 bytes of code (or less) and in only 32 KiB [4] [5] (later relaxed to 64 KiB [6] ) of system memory and only use instructions supported by the original 8088/8086 processors. The first stage of PC boot loaders (FSBL, first-stage boot loader) located on fixed disks and removable drives must fit into the first 446bytes of the master boot record in order to leave room for the default 64-bytepartition table with four partition entries and the two-byte boot signature, which the BIOS requires for a proper boot loader — or even less, when additional features like more than four partition entries (up to 16 with 16 bytes each), a disk signature (6 bytes), a disk timestamp (6 bytes), an Advanced Active Partition (18 bytes) or special multi-boot loaders have to be supported as well in some environments.

In floppy and superfloppy volume boot records, up to 59 bytes are occupied for the extended BIOS parameter block (EBPB) on FAT12 and FAT16 volumes since DOS 4.0, whereas the FAT32 EBPB introduced with DOS 7.1 requires even 87 bytes, leaving only 423 bytes for the boot loader when assuming a sector size of 512 bytes. Microsoft boot sectors, therefore, traditionally imposed certain restrictions on the boot process. For example, the boot file had to be located at a fixed position in the root directory of the file system and stored within consecutive sectors, [7] [8] conditions taken care of by the SYS command and slightly relaxed in later versions of DOS. [8] [nb 1] The boot loader was then able to load the first three sectors of the file into memory, which happened to contain another embedded boot loader able to load the remainder of the file into memory. [8] When Microsoft added logical block addressing (LBA) and FAT32 support, they switched to a boot loader reaching over two physical sectors, using 386 instructions for size reasons. At the same time, other vendors managed to squeeze much more functionality into a single boot sector without relaxing the original constraints on only minimal available memory (32 KiB) and processor support (8088/8086). [nb 2] For example, DR-DOS boot sectors are able to locate the boot file in the FAT12, FAT16 and FAT32 file systems, and load it into memory as a whole via CHS or LBA, even if the file is not stored in a fixed location and in consecutive sectors. [9] [4] [10] [11] [12] [nb 3] [nb 2]

In x86 computers, second-stage bootloaders, such as PBR, operate without the strict 512-byte limitation of their first-stage counterparts. They execute in a more sophisticated environment, typically ranging from 8KB to several megabytes in size. This expanded space allows implementation of complex features such as filesystem support, runtime configuration, and bootloader menu interfaces. The second-stage boot loader does not need drivers for its own operation, but may instead use generic storage access methods provided by system firmware such as the BIOS, though typically with restricted hardware functionality and lower performance. [13]

In x86 computers, third-stage bootloaders are include IO.SYS, NTLDR, BOOTMGR and GRUB.

UEFI

UEFI (except for CSM boot) does not rely on boot sectors, it loads next-stage bootloader (such as BOOTMGR and GRUB2) from EFI System Partition directly.

Embedded and multi-stage boot loaders

Many embedded systems must boot immediately. For example, waiting a minute for a digital television or a GPS navigation device to start is generally unacceptable. Therefore, such devices have software systems in ROM or flash memory so the device can begin functioning immediately; little or no loading is necessary, because the loading can be precomputed and stored on the ROM when the device is made.

Large and complex systems may have boot procedures that proceed in multiple phases until finally the operating system and other programs are loaded and ready to execute. Because operating systems are designed as if they never start or stop, a boot loader might load the operating system, configure itself as a mere process within that system, and then irrevocably transfer control to the operating system. The boot loader then terminates normally as any other process would.

More preciously, a bootloader is used to boot an operating system. Early devices, such as TVs and DVD players in 2000s, may not offer the operating system and may not offer the bootloader, but they usually offer the proprietary firmware.

Network booting

Most computers are also capable of booting over a computer network. In this scenario, the operating system is stored on the disk of a server, and certain parts of it are transferred to the client using a simple protocol such as the Trivial File Transfer Protocol (TFTP). After these parts have been transferred, the operating system takes over the control of the booting process.

As with the second-stage boot loader, network booting begins by using generic network access methods provided by the network interface's boot ROM, which typically contains a Preboot Execution Environment (PXE) image. No drivers are required, but the system functionality is limited until the operating system kernel and drivers are transferred and started. As a result, once the ROM-based booting has completed it is entirely possible to network boot into an operating system that itself does not have the ability to use the network interface.

See also

Notes

  1. ↑ The PC DOS 5.0 manual incorrectly states that the system files no longer need to be contiguous. However, for the boot process to work the system files still need to occupy the first two directory entries and the first three sectors of IBMBIO.COM still need to be stored contiguously. SYS continues to take care of these requirements.
  2. 1 2 As an example, while the extended functionality of DR-DOS MBRs and boot sectors compared to their MS-DOS/PC DOS counterparts could still be achieved utilizing conventional code optimization techniques up to 7.05, for the addition of LBA, FAT32 and LOADER support the 7.07 sectors had to resort to self-modifying code, opcode-level programming, controlled utilization of side effects, multi-level data/code overlapping and algorithmic folding techniques to squeeze everything into a single physical sector, as it was a requirement for backward- and cross-compatibility with other operating systems in multi-boot and chain load scenarios.
  3. ↑ There is one exception to the rule that DR-DOS VBRs will load the whole IBMBIO.COM file into memory: If the IBMBIO.COM file is larger than some 29 KB, trying to load the whole file into memory would result in the boot loader to overwrite the stack and relocated disk parameter table (DPT/FDPB). Therefore, a DR-DOS 7.07 VBR would only load the first 29 KB of the file into memory, relying on another loader embedded into the first part of IBMBIO.COM to check for this condition and load the remainder of the file into memory by itself if necessary. This does not cause compatibility problems, as IBMBIO.COM's size never exceeded this limit in previous versions without this loader. Combined with a dual entry structure this also allows the system to be loaded by a PC DOS VBR, which would load only the first three sectors of the file into memory.

Related Research Articles

<span class="mw-page-title-main">BIOS</span> Firmware for hardware initialization and OS runtime services

In computing, BIOS is a type of firmware used to provide runtime services for operating systems and programs and to perform hardware initialization during the booting process. The firmware comes pre-installed on the computer's motherboard.

<span class="mw-page-title-main">Booting</span> Process of starting a computer

In computing, booting is the process of starting a computer as initiated via hardware such as a physical button on the computer or by a software command. After it is switched on, a computer's central processing unit (CPU) has no software in its main memory, so some process must load software into memory before it can be executed. This may be done by hardware or firmware in the CPU, or by a separate processor in the computer system. On some systems a power-on reset (POR) does not initiate booting and the operator must initiate booting after POR completes. IBM uses the term Initial Program Load (IPL) on some product lines.

File Allocation Table (FAT) is a file system developed for personal computers and was the default file system for the MS-DOS and Windows 9x operating systems. Originally developed in 1977 for use on floppy disks, it was adapted for use on hard disks and other devices. The increase in disk drive capacity over time drove modifications to the design that resulted in versions: FAT12, FAT16, FAT32, and exFAT. FAT was replaced with NTFS as the default file system on Microsoft operating systems starting with Windows XP. Nevertheless, FAT continues to be commonly used on relatively small capacity solid-state storage technologies such as SD card, MultiMediaCard (MMC) and eMMC because of its compatibility and ease of implementation.

<span class="mw-page-title-main">Boot sector</span> Sector of a persistent data storage device

A boot sector is the sector of a persistent data storage device which contains machine code to be loaded into random-access memory (RAM) and then executed by a computer system's built-in firmware.

In computer science, self-modifying code is code that alters its own instructions while it is executing – usually to reduce the instruction path length and improve performance or simply to reduce otherwise repetitively similar code, thus simplifying maintenance. The term is usually only applied to code where the self-modification is intentional, not in situations where code accidentally modifies itself due to an error such as a buffer overflow.

<span class="mw-page-title-main">GNU GRUB</span> Boot loader package

GNU GRUB is a boot loader package from the GNU Project. GRUB is the reference implementation of the Free Software Foundation's Multiboot Specification, which provides a user the choice to boot one of multiple operating systems installed on a computer or select a specific kernel configuration available on a particular operating system's partitions.

NTLDR is the boot loader for all releases of Windows NT operating system from 1993 with the release of Windows NT 3.1 up until Windows XP and Windows Server 2003. From Windows Vista onwards it was replaced by the BOOTMGR bootloader. NTLDR is typically run from the primary storage device, but it can also run from portable storage devices such as a CD-ROM, USB flash drive, or floppy disk. NTLDR can also load a non NT-based operating system given the appropriate boot sector in a file.

A boot disk is a removable digital data storage medium from which a computer can load and run (boot) an operating system or utility program. The computer must have a built-in program which will load and execute a program from a boot disk meeting certain standards.

CONFIG.SYS is the primary configuration file for the DOS and OS/2 operating systems. It is a special ASCII text file that contains user-accessible setup or configuration directives evaluated by the operating system's DOS BIOS during boot. CONFIG.SYS was introduced with DOS 2.0.

<span class="mw-page-title-main">IBMBIO.COM</span> System file (DOS BIOS) in PC DOS and DR-DOS

IBMBIO.COM is a system file in many DOS operating systems. It contains the system initialization code and all built-in device drivers. It also loads the DOS kernel (IBMDOS.COM) and optional pre-loadable system components, displays boot menus, processes configuration files and launches the shell.

This article details versions of MS-DOS, IBM PC DOS, and at least partially compatible disk operating systems. It does not include the many other operating systems called "DOS" which are unrelated to IBM PC compatibles.

In computer science, execute in place (XIP) is a method of executing programs directly from long-term storage rather than copying it into RAM. It is an extension of using shared memory to reduce the total amount of memory required.

A disk compression software utility increases the amount of information that can be stored on a hard disk drive of given size. Unlike a file compression utility, which compresses only specified files—and which requires the user to designate the files to be compressed—an on-the-fly disk compression utility works automatically through resident software without the user needing to be aware of its existence. On-the-fly disk compression is therefore also known as transparent, real-time or online disk compression.

<span class="mw-page-title-main">Das U-Boot</span> Open-source, primary boot the devices operating system kernel

Das U-Boot is an open-source boot loader used in embedded devices to perform various low-level hardware initialization tasks and boot the device's operating system kernel. It is available for a number of computer architectures, including M68000, ARM, Blackfin, MicroBlaze, AArch64, MIPS, Nios II, SuperH, PPC, RISC-V, LoongArch and x86.

A volume boot record (VBR) is a type of boot sector introduced by the IBM Personal Computer. It may be found on a partitioned data storage device, such as a hard disk, or an unpartitioned device, such as a floppy disk, and contains machine code for bootstrapping programs stored in other parts of the device. On non-partitioned storage devices, it is the first sector of the device. On partitioned devices, it is the first sector of an individual partition on the device, with the first sector of the entire device being a Master Boot Record (MBR) containing the partition table.

The Linux booting process involves multiple stages and is in many ways similar to the BSD and other Unix-style boot processes, from which it derives. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components, including system startup, bootloader execution, loading and startup of a Linux kernel image, and execution of various startup scripts and daemons. Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process.

<span class="mw-page-title-main">SpartaDOS X</span> Disk operating system

SpartaDOS X is a disk operating system for the Atari 8-bit computers that closely resembles MS-DOS. It was developed and sold by ICD in 1987-1993, and many years later picked up by the third-party community SpartaDOS X Upgrade Project, which still maintains the software.

<span class="mw-page-title-main">DOS</span> Family of IBM PC-compatible operating systems

DOS is a family of disk-based operating systems for IBM PC compatible computers. The DOS family primarily consists of IBM PC DOS and a rebranded version, Microsoft's MS-DOS, both of which were introduced in 1981. Later compatible systems from other manufacturers include DR-DOS (1988), ROM-DOS (1989), PTS-DOS (1993), and FreeDOS (1994). MS-DOS dominated the IBM PC compatible market between 1981 and 1995.

A master boot record (MBR) is a type of boot sector in the first block of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond. The concept of MBRs was publicly introduced in 1983 with PC DOS 2.0.

The FAT file system is a file system used on MS-DOS and Windows 9x family of operating systems. It continues to be used on mobile devices and embedded systems, and thus is a well-suited file system for data exchange between computers and devices of almost any type and age from 1981 through to the present.

References

  1. ↑ "GNU GRUB - GNU Project - Free Software Foundation (FSF)". www.gnu.org. Retrieved 27 September 2021.
  2. 1 2 "systemd-boot". www.freedesktop.org. Retrieved 27 September 2021.
  3. ↑ "Tint". coreboot. Retrieved 20 November 2010.
  4. 1 2 Paul, Matthias R. (2 October 1997) [29 September 1997]. "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM - README.TXT and BOOT.TXT - A short description of how OpenDOS is booted". Archived from the original on 4 October 2003. Retrieved 29 March 2009.
  5. ↑ Sakamoto, Masahiko (13 May 2010). "Why BIOS loads MBR into 7C00h in x86?". glamenv-septzen.net. Retrieved 22 August 2012.
  6. ↑ Compaq computer corporation; Phoenix technologies ltd; Intel corporation (11 January 1996). "BIOS boot specification 1.01" (PDF). Retrieved 21 December 2017.
  7. ↑ Zbikowski, Mark; Allen, Paul; Ballmer, Steve; Borman, Reuben; Borman, Rob; Butler, John; Carroll, Chuck; Chamberlain, Mark; Chell, David; Colee, Mike; Courtney, Mike; Dryfoos, Mike; Duncan, Rachel; Eckhardt, Kurt; Evans, Eric; Farmer, Rick; Gates, Bill; Geary, Michael; Griffin, Bob; Hogarth, Doug; Johnson, James W.; Kermaani, Kaamel; King, Adrian; Koch, Reed; Landowski, James; Larson, Chris; Lennon, Thomas; Lipkie, Dan; McDonald, Marc; McKinney, Bruce; Martin, Pascal; Mathers, Estelle; Matthews, Bob; Melin, David; Mergentime, Charles; Nevin, Randy; Newell, Dan; Newell, Tani; Norris, David; O'Leary, Mike; O'Rear, Bob; Olsson, Mike; Osterman, Larry; Ostling, Ridge; Pai, Sunil; Paterson, Tim; Perez, Gary; Peters, Chris; Petzold, Charles; Pollock, John; Reynolds, Aaron; Rubin, Darryl; Ryan, Ralph; Schulmeisters, Karl; Shah, Rajen; Shaw, Barry; Short, Anthony; Slivka, Ben; Smirl, Jon; Stillmaker, Betty; Stoddard, John; Tillman, Dennis; Whitten, Greg; Yount, Natalie; Zeck, Steve (1988). "Technical advisors". The MS-DOS Encyclopedia: versions 1.0 through 3.2. By Duncan, Ray; Bostwick, Steve; Burgoyne, Keith; Byers, Robert A.; Hogan, Thom; Kyle, Jim; Letwin, Gordon; Petzold, Charles; Rabinowitz, Chip; Tomlin, Jim; Wilton, Richard; Wolverton, Van; Wong, William; Woodcock, JoAnne (Completely reworked ed.). Redmond, Washington, USA: Microsoft Press. ISBN   1-55615-049-0. LCCN   87-21452. OCLC   16581341. (xix+1570 pages; 26 cm) (NB. This edition was published in 1988 after extensive rework of the withdrawn 1986 first edition by a different team of authors. )
  8. 1 2 3 Chappell, Geoff (January 1994). "Chapter 2: The system footprint". In Schulman, Andrew; Pedersen, Amorette (eds.). DOS Internals. The Andrew Schulman programming series (1st printing, 1st ed.). Addison-Wesley. ISBN   978-0-201-60835-9. (xxvi+738+iv pages, 3.5"-floppy ) Errata:
  9. ↑ Rosch, Winn L. (12 February 1991). "DR DOS 5.0 - The better operating system?". PC Magazine . Vol. 10, no. 3. pp. 241–246, 257, 264, 266. Archived from the original on 25 July 2019. Retrieved 26 July 2019. […] SYS has been improved under DR DOS 5.0 so you don't have to worry about leaving the first cluster free on a disk that you want to make bootable. The DR DOS system files can be located anywhere on the disk, so any disk with enough free space can be set to boot your system. […] (NB. The source attributes this to the SYS utility while in fact this is a feature of the advanced bootstrap loader in the boot sector. SYS just plants this sector onto the disk.)
  10. ↑ Paul, Matthias R. (17 January 2001). "FAT32 in DR-DOS". opendos@delorie. Archived from the original on 6 October 2017. Retrieved 6 October 2017. […] The DR-DOS boot sector […] searches for the IBMBIO.COM (DRBIOS.SYS) file and then loads the *whole* file into memory before it passes control to it. […]
  11. ↑ Paul, Matthias R. (20 February 2002). "Can't copy". opendos@delorie. Archived from the original on 6 October 2017. Retrieved 9 October 2017. […] The DR-DOS boot sector loads the whole IBMBIO.COM file into memory before it executes it. It does not care at all about the IBMDOS.COM file, which is loaded by IBMBIO.COM. […] The DR-DOS boot sector […] will find the […] kernel files as long as they are logically stored in the root directory. Their physical location on the disk, and if they are fragmented or not, is don't care for the DR-DOS boot sector. Hence, you can just copy the kernel files to the disk (even with a simply COPY ), and as soon as the boot sector is a DR-DOS sector, it will find and load them. Of course, it is difficult to put all this into just 512 bytes, the size of a single sector, but this is a major convenience improvement if you have to set up a DR-DOS system, and it is also the key for the DR-DOS multi-OS LOADER utility to work. The MS-DOS kernel files must reside on specific locations, but the DR-DOS files can be anywhere, so you don't have to physically swap them around each time you boot the other OS. Also, it allows to upgrade a DR-DOS system simply by copying the kernel files over the old ones, no need for SYS , no difficult setup procedures as required for MS-DOS/PC DOS. You can even have multiple DR-DOS kernel files under different file names stored on the same drive, and LOADER will switch between them according to the file names listed in the BOOT.LST file. […]
  12. ↑ Paul, Matthias R. (14 August 2017) [7 August 2017]. "The continuing saga of Windows 3.1 in enhanced mode on OmniBook 300". MoHPC - the museum of HP calculators. Archived from the original on 6 October 2017. Retrieved 6 October 2017. […] the DR-DOS FDISK does not only partition a disk, but can also format the freshly created volumes and initialize their boot sectors in one go, so there's no risk to accidentally mess up the wrong volume and no need for FORMAT /S or SYS . Afterwards, you could just copy over the remaining DR-DOS files, including the system files. It is important to know that, in contrast to MS-DOS/PC DOS, DR-DOS has "smart" boot sectors which will actually "mount" the file-system to search for and load the system files in the root directory instead of expecting them to be placed at a certain location. Physically, the system files can be located anywhere and also can be fragmented. […]
  13. ↑ "Chapter 6 - Troubleshooting startup and disk problems". Windows NT server resource kit. Microsoft. Archived from the original on 15 May 2007.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.