Booting
周墨一
From Wikipedia, the free encyclopedia
In computing, booting (booting up) is a bootstrapping process that starts operating systems when the user turns on a computer system. A boot sequence is the initial set of operations that the computer performs when it is switched on. The bootloader typically loads the main operating system for the computer.
Boot loader
Computing systems powered by the central processor (or a set of processors) can only execute code found in the operating memory, also known as systems memory, that may be implemented in several technologies covered by the general types of: Read-Only Memory or ROM, and Random Access Memory or RAM. Modern operating systems and application program code and data are stored on nonvolatile or persistent local or remote peripheral memories or mass storage devices. Typical examples of such persistent storage devices are: hard disk, CD, USB flash drive, and Floppy drive. When a computer is first powered on, it must initially rely only on the code and data stored in nonvolatile portion of the systems memory map, such as ROM, NVRAM or CMOS RAM. Persistent code and data residing in the systems memory map represent the bare minimum needed to access peripheral persistent devices and load into the systems memory all of the missing parts of the operating system. Truly speaking at power-on time the computing system does not have an operating system in memory. Among many things, the computer's hardware alone (processor and systems memory) cannot perform many complex systems actions of which loading program files from the disk based file systems is one of the most important tasks.
The program that starts the "chain reaction" which ends with the entire operating system being loaded is known as bootstrap loader. Early computer designers creatively imagined that before being ready to "run" a computer program, a small initiating program called a bootstrap loader, bootstrap or boot loader had to run first. This program's only job is to load other software for the operating system to start. Often, multiple-stage boot loaders are used, in which several small programs of increasing complexity sequentially summon one after the other, until the last of them loads the operating system. The name bootstrap loader comes from the image of one pulling oneself up by one's boot straps.
Early computers (such as the PDP-1 through PDP-8 and early models of the PDP-11) had a row of toggle switches on the front panel to allow the operator to manually enter the binary boot instructions into memory before transferring control to the CPU. The boot loader would then read the operating system in from an outside storage medium such as paper tape, punched card, or a disk drive.
Pseudo-assembly code for the bootloader might be as simple as the following eight instructions:
0: set the P register to 8
1: check paper tape reader ready
2: if not ready, jump to 1
3: read a byte from paper tape reader to accumulator
4: if end of tape, jump to 8
5: store accumulator to address in P register
6: increment the P register
7: jump to 1
A related example is based on a loader for a 1970's Nicolet Instrument Corporation minicomputer. Note that the bytes of the second-stage loader are read from paper tape in reverse order.
0: set the P register to 106
1: check paper tape reader ready
2: if not ready, jump to 1
3: read a byte from paper tape reader to accumulator
4: store accumulator to address in P register
5: decrement the P register
6: jump to 1
The length of the second stage loader is such that the final byte overwrites location 6. After the instruction in location 5 executes, location 6 starts the second stage loader executing. The second stage loader then waits for the much longer tape containing the operating system to be placed in the tape reader. The difference between the boot loader and second stage loader is the addition of checking code to trap paper tape read errors, a frequent occurrence with the hardware of the time, which in this case was an ASR-33 teletype.
Some 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 bootload 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 bootload 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) at a predefined address (the CPU is designed to execute this software after reset without outside help)[citation needed]. 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. It is usually possible to configure the BIOS so that only a certain device can be booted from and/or to give priority to some devices over others (a CD or DVD drive is usually given priority over a hard disk, for instance).
Boot loaders may face peculiar constraints, especially in size; for instance, on the IBM PC and compatibles, the first stage of boot loaders located on hard drives must fit into the first 446 bytes of the Master Boot Record, in order to leave room for the 64-byte partition table and the 2-byte 0xAA55 'signature', which the BIOS requires for a proper boot loader.
Some operating systems, most notably pre-1995 Macintosh systems from Apple, are so closely interwoven with their hardware that it is impossible to natively boot an operating system other than the standard one. This is the opposite extreme of the bootload using switches mentioned above; it is highly inflexible but relatively error-proof and foolproof as long as all hardware is working normally. A common solution in such situations is to design a bootloader that works as a program belonging to the standard OS that hijacks the system and loads the alternative OS. This technique was used by Apple for its A/UX Unix implementation and copied by various freeware operating systems and BeOS Personal Edition 5.
Second-stage boot loader
The small program is most often not itself an operating system, but only a second-stage boot loader, such as GRUB, LILO or NTLDR. It will then be able to load the operating system properly, and finally transfer execution to it. The system will initialize itself, and may load device drivers and other programs that are needed for the normal operation of the OS.
Many bootloaders (like GRUB, Bootmgr, LILO, and NTLDR) can be configured to give the user multiple booting choices. These choices can include different operating systems (for dual or multi-booting from different partitions or drives), different kernel versions of the same operating system (e.g., when a newer Linux kernel is installed, this gives one the option of using a known good kernel if problems arise), different kernel options (e.g., booting into a rescue or safe mode) or some standalone program that can function without an operating system, such as memory testers (e.g., memtest86+) or even games. Usually a default choice is preselected with a time delay during which you can press a key to change the choice, after which the default choice is automatically run, so normal booting can occur without interaction.
The boot process is considered complete when the computer is ready to interact with the user, or the operating system is capable of running ordinary applications. Typical modern PCs boot in about one minute (of which about 15 seconds are taken by a power-on self test (POST) and a preliminary boot loader, and the rest by loading the operating system); whereas, large servers may take several minutes to boot and start all their services.
Many embedded systems must boot immediately. For example, waiting a minute for a digital television or sat-nav to start is generally unacceptable. Therefore such devices have their complete operating system in ROM or flash memory so the device can begin functioning immediately. For these types of embedded system little or no loading is necessary, since 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, each phase loading a more complex version of itself, until finally the actual operating system is loaded and ready to execute. Because most operating systems are designed as if they never start or stop, bootload processes sometimes construct a near-snapshot of a running operating system, configure themselves as a mere process within that operating system, and then irrevocably transfer control into the operating system; the bootload process then terminates normally as any other process would, and the operating system need not have any awareness of the bootload.
Flash boot loader
Embedded systems especially in automotive applications rely heavily on Flash Bootloaders to ensure that the ECU (Electronic Control Unit) is programmable either in production or in service. A Flash Bootloader resides in Flash memory, and is always the first application to run after a reset. The Flash bootloader decides whether an application is ready and thereby either stays in the ECU or jumps to the application to start execution. The benefit of having a Flash Bootloader on an ECU is mainly to allow erasing and programming new applications on a single ECU in case of application updates, a recall, or changing a configuration by downloading new calibration files. The most popular Flash Bootloaders are CAN based, i.e. use the Control Area Network protocol to download data to an ECU. These bootloaders use a Diagnostics protocol to communicate and download to an ECU.
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. After these parts have been transferred, the operating system then takes over control of the booting process.
Boot devices
The boot device is the device from which the operating system is loaded. A modern PC BIOS supports booting from various devices, typically a local hard disk drive (or one of several partitions on such a disk), an optical disc drive, a USB device (flash drive, hard disk drive, optical disc drive, etc.), or a network interface card (using PXE). Older, less common bootable devices include floppy disk drives, SCSI devices, Zip drives, and LS-120 drives.
Typically, the BIOS will allow the user to configure a boot order. If the boot order is set to "firstly, the DVD drive; secondly, the hard disk drive", then the BIOS will try to boot from the DVD drive, and if this fails (e.g. because there is no DVD in the drive), it will try to boot from the local hard drive.
For example, on a PC with Windows XP installed on the hard drive, the user could set the boot order to that given above, and then insert a Knoppix Live CD in order to try out Linux without having to install an operating system onto their hard drive. This is an example of dual booting - the user choosing which operating system to start after the computer has performed its Power On Self Test. In this example of dual booting, the user chooses by inserting or removing the CD from the computer, but it is more common to choose which operating system to boot by selecting from a menu using the computer keyboard. (Typically, the boot loader which presents the menu will select a default option if the user does nothing for a configured time period, e.g. 30 seconds. This facilitates unattended rebooting into a default environment.)
Boot sequence on standard PC (IBM-PC compatible)
Upon starting, a personal computer's x86 CPU runs the instruction located at the memory location F000:FFF0 (on 286s and 386SXs, the base of the code segment is actually 0xFF0000 and on 386s it is 0xFFFF0000) of the BIOS. This memory location is close to the end of system memory. It contains a jump instruction that transfers execution to the location of the BIOS start-up program. This program runs a power-on self test (POST) to check that devices the computer will rely on are functioning; it also initializes these devices. Then, the BIOS goes through a preconfigured list of non-volatile storage devices ("boot device sequence") until it finds one that is bootable. A bootable device is one such that it can be read from and the last two bytes of the first sector contain the word 0xAA55. On IBM PCs and derivatives made by IBM, if it finds no such device, control is transferred to IBM Cassette BASIC. On other IBM PC compatibles, an error message is generated and the boot process stops.
Once BIOS has found a bootable device, BIOS loads the bootsector to hexadecimal Sector:Offset address 0000:7C00 and transfers execution to the boot sector. In the case of a hard drive, this is referred to as the master boot record (MBR) and is often not operating system specific. The conventional MBR code checks the MBR's partition table for an active partition(the one with active flag set)[1]. If one is found, the MBR code loads that partition's boot sector and executes it. The boot sector is often operating system specific, however in most operating systems its main function is to load and execute the operating system kernel, which continues startup. If there is no active partition or the active partition's boot sector is invalid, the MBR may load a secondary boot loader and pass control to it and this secondary boot loader will select a partition (often via user input) and load its boot sector, which usually loads the corresponding operating system kernel.
Newer systems that have EFI-compliant firmware can boot from that to either MBR or GPT drives. Compatibility with x86 operating systems, such as 32-bit Windows XP and Vista, require “legacy BIOS” interfaces to operate, which is handled through a compatibility support module (CSM). The CSM includes a 16-bit binary (CSM16) supplied by BIOS vendors, like American Megatrends (AMI) and Insyde Software[2] or Apple Inc. which offers it as a firmware update for Intel Macintosh computers.
Other kinds of boot sequence
Some other processors have other kinds of boot modes; most digital signal processors have the following boot modes:
Serial mode boot
Parallel mode boot
HPI boot
Initial Program Load
In IBM mainframe systems, the boot process is known as IPL (Initial Program Load). The term was coined by IBM for the design of the System/360 and continues to be used in those environments today[3]. In systems that share the System/360 heritage—and in some that have been inspired by it, including smaller systems such as the IBM 1130—IPL is a hardware function, not a program run on the system itself. In its basic form, an IPL is initiated by the computer operator by selecting the (three digit) device address using rotary switches on the computer console, followed by pressing the 'IPL' button. This starts a tiny (typically 24 byte) program entirely implemented in hardware, consisting merely of a few channel command words initiating a read operation from the designated device. Usually this is a disk drive, but exactly the same procedure is also used to boot from other devices, such as tape drives, or even card readers, in a device-independent manner, allowing e.g. the installation of an operating system on a pristine computer from a magnetic distribution tape. Of course, the disk, tape or card deck must contain a special program to load the actual operating system into memory, a multi-stage procedure similar to most booting procedures (see elsewhere in this article).
The System/360 IPL function reads 24 bytes from an operator-specified or pre-configured device into memory starting at location zero. The second and third groups of eight bytes are treated as Channel Command Words (CCWs) to continue loading the startup program. When the I/O channel commands are complete, the first group of eight bytes is then loaded into the Program Status Word (PSW) register and the startup program begins execution at the designated location.[3]
A noteworthy variation of this is found on the Burroughs B1700 where there is neither a bootstrap ROM nor a hardwired IPL operation. Instead, after the system is reset it reads and executes opcodes sequentially from a tape drive mounted on the front panel, this sets up a boot loader in RAM which is then executed. However, since this makes few assumptions about the system it can equally well be used to load diagnostic (Maintenance Test Routine) tapes which display an intelligible code on the front panel even in cases of gross CPU failure.
Hard reboot
A hard reboot (also known as a cold reboot, cold boot or cold start) is when power to a computer is cycled (turned off and then on) or a special reset signal to the processor is triggered (from a front panel switch of some sort). This restarts the computer without first performing any shut-down procedure. (With many operating systems, especially those using disk caches, after a hard reboot the filesystem may be in an "unclean" state, and an automatic scan of on-disk filesystem structures will be done before normal operation can begin.) It may be caused by power failure, be done by accident, or be done deliberately as a last resort to forcibly retrieve the system from instances such as a critical error or virus-inflicted DoS attack.
Soft reboot
A soft reboot (also known as a warm reboot) is restarting a computer under software control, without removing power or (directly) triggering a reset line. It usually, though not always, refers to an orderly shutdown and restarting of the machine.
The Control-Alt-Delete key combination on the original IBM PC was designed to allow a soft reboot for a quicker and more convenient (and, some argue, less stressful on system components) restart than powering the computer completely down then back up.[citation needed]
The Linux kernel has optional support for the kexec system call, which shuts down the currently running kernel and executes another one. The entire process is done independent of the system firmware. Note that the kernel being executed does not have to be a Linux kernel.
Most Nintendo Game Boy games feature a soft reset feature when the A, B, Start, and Select buttons are pressed together. This was carried over to the Nintendo DS, with the sequence L, R, Start, and Select. Many Nintendo GameCube games have a similar feature, with the sequence Start, B, A, and X.
Random reboot
Random reboot is a non-technical term referring to an unintended (and often undesired) reboot for which the cause is not immediately evident to the user. Such reboots may occur due to a multitude of software and hardware problems, such as triple faults.
As Windows XP/Vista has an option to skip its Blue Screen of Death (Blue Screens of Death in Windows XP/Vista offer no option of pressing any key and seeing if the computer continues functioning) and immediately restarts the computer in the event of a fatal error, users can be mistaken in thinking a Windows XP/Vista computer suffers from random rebooting.
Errors
In Windows, when an error occurs in the boot process, a Blue Screen of Death or a Black Screen of Death may occur. On Unix and Unix-like operating systems, like Linux, a fatal error in the boot process may cause a kernel panic.
History
The computer word boot is short for 'bootstrap' (short for 'bootstrap load'). The term bootstrap began as a metaphor derived from pull straps sewed onto the backs of leather boots with which a person could pull on their boots without outside help. In computers in the 1950s, pressing a bootstrap button caused a hardwired program to read a bootstrap program from a punched card and then execute the loaded boot program which loaded a larger system of programs from punched cards into memory, without further help from the human operator. [4][5] In a computing context, that word has been used since at least 1958[6].
The GE 645 (c. 1965) had a 'BOOT' button[7] – it could be that the contraction started as a way to label the button with fewer letters than the full word.
The Multics operating system (c. 1967) had a boot command.[8][9] Multics documents also refer to 'boot tapes', but it is hard to determine exactly when that term was first used.
In the Unix operating system, the earliest reference for 'boot' is probably in The Unix Programmer's Manual, first edition 1971.11.03[10].
See also
Boot disk, Live CD, Live USB
Boot sector
Comparison of boot loaders
Extensible Firmware Interface (EFI)
Linux startup process
Microreboot
Network booting
RedBoot open source boot loader for embedded systems
Windows NT Startup Process
Windows Vista startup process
References
How Computers Boot Up
Pratical bootloader tutorial for ATmega microcontrollers
How GRUB fits into the hardisk layout on a PC
Booting with Grub at OSDEV Community
A tutorial on dualbooting/multibooting with Windows NTLDR and Linux LILO/GRUB
Booting From Scratch
Matthew Vea. "x86 BootStrap Programming Tutorial".
FreeBSD
Nathan Boeger and Mana Tominaga. "Bootstrapping FreeBSD".
Linux
Roberto Alsina. "The Linux boot process unveiled".
Greg O'Keefe. "From power up to Linux bash prompt HOWTO".
Mac OS X
Amit Singh. "Mac OS X Boot Process".
Windows
Jonathan de Boyne Pollard (1996). "The DOS and DOS/Windows boot processes".
"Multi-booting, running different versions of Windows on your PC".
"Windows Mobile 5.0 Soft Reset".
"Pocket PC devices hard reset and soft reset".
In computing, booting (booting up) is a bootstrapping process that starts operating systems when the user turns on a computer system. A boot sequence is the initial set of operations that the computer performs when it is switched on. The bootloader typically loads the main operating system for the computer.
Boot loader
Computing systems powered by the central processor (or a set of processors) can only execute code found in the operating memory, also known as systems memory, that may be implemented in several technologies covered by the general types of: Read-Only Memory or ROM, and Random Access Memory or RAM. Modern operating systems and application program code and data are stored on nonvolatile or persistent local or remote peripheral memories or mass storage devices. Typical examples of such persistent storage devices are: hard disk, CD, USB flash drive, and Floppy drive. When a computer is first powered on, it must initially rely only on the code and data stored in nonvolatile portion of the systems memory map, such as ROM, NVRAM or CMOS RAM. Persistent code and data residing in the systems memory map represent the bare minimum needed to access peripheral persistent devices and load into the systems memory all of the missing parts of the operating system. Truly speaking at power-on time the computing system does not have an operating system in memory. Among many things, the computer's hardware alone (processor and systems memory) cannot perform many complex systems actions of which loading program files from the disk based file systems is one of the most important tasks.
The program that starts the "chain reaction" which ends with the entire operating system being loaded is known as bootstrap loader. Early computer designers creatively imagined that before being ready to "run" a computer program, a small initiating program called a bootstrap loader, bootstrap or boot loader had to run first. This program's only job is to load other software for the operating system to start. Often, multiple-stage boot loaders are used, in which several small programs of increasing complexity sequentially summon one after the other, until the last of them loads the operating system. The name bootstrap loader comes from the image of one pulling oneself up by one's boot straps.
Early computers (such as the PDP-1 through PDP-8 and early models of the PDP-11) had a row of toggle switches on the front panel to allow the operator to manually enter the binary boot instructions into memory before transferring control to the CPU. The boot loader would then read the operating system in from an outside storage medium such as paper tape, punched card, or a disk drive.
Pseudo-assembly code for the bootloader might be as simple as the following eight instructions:
0: set the P register to 8
1: check paper tape reader ready
2: if not ready, jump to 1
3: read a byte from paper tape reader to accumulator
4: if end of tape, jump to 8
5: store accumulator to address in P register
6: increment the P register
7: jump to 1
A related example is based on a loader for a 1970's Nicolet Instrument Corporation minicomputer. Note that the bytes of the second-stage loader are read from paper tape in reverse order.
0: set the P register to 106
1: check paper tape reader ready
2: if not ready, jump to 1
3: read a byte from paper tape reader to accumulator
4: store accumulator to address in P register
5: decrement the P register
6: jump to 1
The length of the second stage loader is such that the final byte overwrites location 6. After the instruction in location 5 executes, location 6 starts the second stage loader executing. The second stage loader then waits for the much longer tape containing the operating system to be placed in the tape reader. The difference between the boot loader and second stage loader is the addition of checking code to trap paper tape read errors, a frequent occurrence with the hardware of the time, which in this case was an ASR-33 teletype.
Some 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 bootload 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 bootload 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) at a predefined address (the CPU is designed to execute this software after reset without outside help)[citation needed]. 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. It is usually possible to configure the BIOS so that only a certain device can be booted from and/or to give priority to some devices over others (a CD or DVD drive is usually given priority over a hard disk, for instance).
Boot loaders may face peculiar constraints, especially in size; for instance, on the IBM PC and compatibles, the first stage of boot loaders located on hard drives must fit into the first 446 bytes of the Master Boot Record, in order to leave room for the 64-byte partition table and the 2-byte 0xAA55 'signature', which the BIOS requires for a proper boot loader.
Some operating systems, most notably pre-1995 Macintosh systems from Apple, are so closely interwoven with their hardware that it is impossible to natively boot an operating system other than the standard one. This is the opposite extreme of the bootload using switches mentioned above; it is highly inflexible but relatively error-proof and foolproof as long as all hardware is working normally. A common solution in such situations is to design a bootloader that works as a program belonging to the standard OS that hijacks the system and loads the alternative OS. This technique was used by Apple for its A/UX Unix implementation and copied by various freeware operating systems and BeOS Personal Edition 5.
Second-stage boot loader
The small program is most often not itself an operating system, but only a second-stage boot loader, such as GRUB, LILO or NTLDR. It will then be able to load the operating system properly, and finally transfer execution to it. The system will initialize itself, and may load device drivers and other programs that are needed for the normal operation of the OS.
Many bootloaders (like GRUB, Bootmgr, LILO, and NTLDR) can be configured to give the user multiple booting choices. These choices can include different operating systems (for dual or multi-booting from different partitions or drives), different kernel versions of the same operating system (e.g., when a newer Linux kernel is installed, this gives one the option of using a known good kernel if problems arise), different kernel options (e.g., booting into a rescue or safe mode) or some standalone program that can function without an operating system, such as memory testers (e.g., memtest86+) or even games. Usually a default choice is preselected with a time delay during which you can press a key to change the choice, after which the default choice is automatically run, so normal booting can occur without interaction.
The boot process is considered complete when the computer is ready to interact with the user, or the operating system is capable of running ordinary applications. Typical modern PCs boot in about one minute (of which about 15 seconds are taken by a power-on self test (POST) and a preliminary boot loader, and the rest by loading the operating system); whereas, large servers may take several minutes to boot and start all their services.
Many embedded systems must boot immediately. For example, waiting a minute for a digital television or sat-nav to start is generally unacceptable. Therefore such devices have their complete operating system in ROM or flash memory so the device can begin functioning immediately. For these types of embedded system little or no loading is necessary, since 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, each phase loading a more complex version of itself, until finally the actual operating system is loaded and ready to execute. Because most operating systems are designed as if they never start or stop, bootload processes sometimes construct a near-snapshot of a running operating system, configure themselves as a mere process within that operating system, and then irrevocably transfer control into the operating system; the bootload process then terminates normally as any other process would, and the operating system need not have any awareness of the bootload.
Flash boot loader
Embedded systems especially in automotive applications rely heavily on Flash Bootloaders to ensure that the ECU (Electronic Control Unit) is programmable either in production or in service. A Flash Bootloader resides in Flash memory, and is always the first application to run after a reset. The Flash bootloader decides whether an application is ready and thereby either stays in the ECU or jumps to the application to start execution. The benefit of having a Flash Bootloader on an ECU is mainly to allow erasing and programming new applications on a single ECU in case of application updates, a recall, or changing a configuration by downloading new calibration files. The most popular Flash Bootloaders are CAN based, i.e. use the Control Area Network protocol to download data to an ECU. These bootloaders use a Diagnostics protocol to communicate and download to an ECU.
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. After these parts have been transferred, the operating system then takes over control of the booting process.
Boot devices
The boot device is the device from which the operating system is loaded. A modern PC BIOS supports booting from various devices, typically a local hard disk drive (or one of several partitions on such a disk), an optical disc drive, a USB device (flash drive, hard disk drive, optical disc drive, etc.), or a network interface card (using PXE). Older, less common bootable devices include floppy disk drives, SCSI devices, Zip drives, and LS-120 drives.
Typically, the BIOS will allow the user to configure a boot order. If the boot order is set to "firstly, the DVD drive; secondly, the hard disk drive", then the BIOS will try to boot from the DVD drive, and if this fails (e.g. because there is no DVD in the drive), it will try to boot from the local hard drive.
For example, on a PC with Windows XP installed on the hard drive, the user could set the boot order to that given above, and then insert a Knoppix Live CD in order to try out Linux without having to install an operating system onto their hard drive. This is an example of dual booting - the user choosing which operating system to start after the computer has performed its Power On Self Test. In this example of dual booting, the user chooses by inserting or removing the CD from the computer, but it is more common to choose which operating system to boot by selecting from a menu using the computer keyboard. (Typically, the boot loader which presents the menu will select a default option if the user does nothing for a configured time period, e.g. 30 seconds. This facilitates unattended rebooting into a default environment.)
Boot sequence on standard PC (IBM-PC compatible)
Upon starting, a personal computer's x86 CPU runs the instruction located at the memory location F000:FFF0 (on 286s and 386SXs, the base of the code segment is actually 0xFF0000 and on 386s it is 0xFFFF0000) of the BIOS. This memory location is close to the end of system memory. It contains a jump instruction that transfers execution to the location of the BIOS start-up program. This program runs a power-on self test (POST) to check that devices the computer will rely on are functioning; it also initializes these devices. Then, the BIOS goes through a preconfigured list of non-volatile storage devices ("boot device sequence") until it finds one that is bootable. A bootable device is one such that it can be read from and the last two bytes of the first sector contain the word 0xAA55. On IBM PCs and derivatives made by IBM, if it finds no such device, control is transferred to IBM Cassette BASIC. On other IBM PC compatibles, an error message is generated and the boot process stops.
Once BIOS has found a bootable device, BIOS loads the bootsector to hexadecimal Sector:Offset address 0000:7C00 and transfers execution to the boot sector. In the case of a hard drive, this is referred to as the master boot record (MBR) and is often not operating system specific. The conventional MBR code checks the MBR's partition table for an active partition(the one with active flag set)[1]. If one is found, the MBR code loads that partition's boot sector and executes it. The boot sector is often operating system specific, however in most operating systems its main function is to load and execute the operating system kernel, which continues startup. If there is no active partition or the active partition's boot sector is invalid, the MBR may load a secondary boot loader and pass control to it and this secondary boot loader will select a partition (often via user input) and load its boot sector, which usually loads the corresponding operating system kernel.
Newer systems that have EFI-compliant firmware can boot from that to either MBR or GPT drives. Compatibility with x86 operating systems, such as 32-bit Windows XP and Vista, require “legacy BIOS” interfaces to operate, which is handled through a compatibility support module (CSM). The CSM includes a 16-bit binary (CSM16) supplied by BIOS vendors, like American Megatrends (AMI) and Insyde Software[2] or Apple Inc. which offers it as a firmware update for Intel Macintosh computers.
Other kinds of boot sequence
Some other processors have other kinds of boot modes; most digital signal processors have the following boot modes:
Serial mode boot
Parallel mode boot
HPI boot
Initial Program Load
In IBM mainframe systems, the boot process is known as IPL (Initial Program Load). The term was coined by IBM for the design of the System/360 and continues to be used in those environments today[3]. In systems that share the System/360 heritage—and in some that have been inspired by it, including smaller systems such as the IBM 1130—IPL is a hardware function, not a program run on the system itself. In its basic form, an IPL is initiated by the computer operator by selecting the (three digit) device address using rotary switches on the computer console, followed by pressing the 'IPL' button. This starts a tiny (typically 24 byte) program entirely implemented in hardware, consisting merely of a few channel command words initiating a read operation from the designated device. Usually this is a disk drive, but exactly the same procedure is also used to boot from other devices, such as tape drives, or even card readers, in a device-independent manner, allowing e.g. the installation of an operating system on a pristine computer from a magnetic distribution tape. Of course, the disk, tape or card deck must contain a special program to load the actual operating system into memory, a multi-stage procedure similar to most booting procedures (see elsewhere in this article).
The System/360 IPL function reads 24 bytes from an operator-specified or pre-configured device into memory starting at location zero. The second and third groups of eight bytes are treated as Channel Command Words (CCWs) to continue loading the startup program. When the I/O channel commands are complete, the first group of eight bytes is then loaded into the Program Status Word (PSW) register and the startup program begins execution at the designated location.[3]
A noteworthy variation of this is found on the Burroughs B1700 where there is neither a bootstrap ROM nor a hardwired IPL operation. Instead, after the system is reset it reads and executes opcodes sequentially from a tape drive mounted on the front panel, this sets up a boot loader in RAM which is then executed. However, since this makes few assumptions about the system it can equally well be used to load diagnostic (Maintenance Test Routine) tapes which display an intelligible code on the front panel even in cases of gross CPU failure.
Hard reboot
A hard reboot (also known as a cold reboot, cold boot or cold start) is when power to a computer is cycled (turned off and then on) or a special reset signal to the processor is triggered (from a front panel switch of some sort). This restarts the computer without first performing any shut-down procedure. (With many operating systems, especially those using disk caches, after a hard reboot the filesystem may be in an "unclean" state, and an automatic scan of on-disk filesystem structures will be done before normal operation can begin.) It may be caused by power failure, be done by accident, or be done deliberately as a last resort to forcibly retrieve the system from instances such as a critical error or virus-inflicted DoS attack.
Soft reboot
A soft reboot (also known as a warm reboot) is restarting a computer under software control, without removing power or (directly) triggering a reset line. It usually, though not always, refers to an orderly shutdown and restarting of the machine.
The Control-Alt-Delete key combination on the original IBM PC was designed to allow a soft reboot for a quicker and more convenient (and, some argue, less stressful on system components) restart than powering the computer completely down then back up.[citation needed]
The Linux kernel has optional support for the kexec system call, which shuts down the currently running kernel and executes another one. The entire process is done independent of the system firmware. Note that the kernel being executed does not have to be a Linux kernel.
Most Nintendo Game Boy games feature a soft reset feature when the A, B, Start, and Select buttons are pressed together. This was carried over to the Nintendo DS, with the sequence L, R, Start, and Select. Many Nintendo GameCube games have a similar feature, with the sequence Start, B, A, and X.
Random reboot
Random reboot is a non-technical term referring to an unintended (and often undesired) reboot for which the cause is not immediately evident to the user. Such reboots may occur due to a multitude of software and hardware problems, such as triple faults.
As Windows XP/Vista has an option to skip its Blue Screen of Death (Blue Screens of Death in Windows XP/Vista offer no option of pressing any key and seeing if the computer continues functioning) and immediately restarts the computer in the event of a fatal error, users can be mistaken in thinking a Windows XP/Vista computer suffers from random rebooting.
Errors
In Windows, when an error occurs in the boot process, a Blue Screen of Death or a Black Screen of Death may occur. On Unix and Unix-like operating systems, like Linux, a fatal error in the boot process may cause a kernel panic.
History
The computer word boot is short for 'bootstrap' (short for 'bootstrap load'). The term bootstrap began as a metaphor derived from pull straps sewed onto the backs of leather boots with which a person could pull on their boots without outside help. In computers in the 1950s, pressing a bootstrap button caused a hardwired program to read a bootstrap program from a punched card and then execute the loaded boot program which loaded a larger system of programs from punched cards into memory, without further help from the human operator. [4][5] In a computing context, that word has been used since at least 1958[6].
The GE 645 (c. 1965) had a 'BOOT' button[7] – it could be that the contraction started as a way to label the button with fewer letters than the full word.
The Multics operating system (c. 1967) had a boot command.[8][9] Multics documents also refer to 'boot tapes', but it is hard to determine exactly when that term was first used.
In the Unix operating system, the earliest reference for 'boot' is probably in The Unix Programmer's Manual, first edition 1971.11.03[10].
See also
Boot disk, Live CD, Live USB
Boot sector
Comparison of boot loaders
Extensible Firmware Interface (EFI)
Linux startup process
Microreboot
Network booting
RedBoot open source boot loader for embedded systems
Windows NT Startup Process
Windows Vista startup process
References
- Note that the active partition is not required to be primary. However, the boot sector code may require it to be such to work properly.
- "Intel Platform Innovation Framework for EFI". Intel. Retrieved on 2008-01-07.
- September 2005) z/Architecture Principles of Operation (PDF), IBM, Chapter 17. Retrieved on 2007-04-14.
- Bensoussan, A. (1967-06-30). "BC.4.01 System Initialization and Bootload", Multics System Programmer's Manual.
- Dunten, S. D.; T. H. Van Vleck (1968-05-03). "BV.1.01 BOS Bootload: boot", Multics System Programmer's Manual.
- Thompson, Ken; Dennis Ritchie (1971-11-03). The Unix Programmer's Manual, 1st edition. Retrieved on 2008-01-07..
How Computers Boot Up
Pratical bootloader tutorial for ATmega microcontrollers
How GRUB fits into the hardisk layout on a PC
Booting with Grub at OSDEV Community
A tutorial on dualbooting/multibooting with Windows NTLDR and Linux LILO/GRUB
Booting From Scratch
Matthew Vea. "x86 BootStrap Programming Tutorial".
FreeBSD
Nathan Boeger and Mana Tominaga. "Bootstrapping FreeBSD".
Linux
Roberto Alsina. "The Linux boot process unveiled".
Greg O'Keefe. "From power up to Linux bash prompt HOWTO".
Mac OS X
Amit Singh. "Mac OS X Boot Process".
Windows
Jonathan de Boyne Pollard (1996). "The DOS and DOS/Windows boot processes".
"Multi-booting, running different versions of Windows on your PC".
"Windows Mobile 5.0 Soft Reset".
"Pocket PC devices hard reset and soft reset".
类似资料：