"GRUB" redirects here. For other uses, see grub (disambiguation).

GNU GRUB

GRUB in text mode

Developer(s) GNU Project
Stable release 1.98 (March 6, 2010; 9 months ago) [+/−]

Development status active

Written in Assembly, C[1]
Platform IA-32, x86-64, PowerPC
Type Bootloader
License GNU GPL 3+[1]
Website http://www.gnu.org/software/grub/

GNU GRUB (short for GNU GRand Unified Bootloader) is a boot loader package from
the GNU Project. GRUB is the reference implementation of the 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.

GNU GRUB was developed from a package called the Grand Unified Bootloader (a
play on grand unified theory[citation needed]). It is predominantly used for Unix-like systems.
The GNU operating system uses GNU GRUB as its boot loader, as do most Linux
distributions. The Solaris Operating System has used GRUB as its boot loader on x86
systems starting with the Solaris 10 1/06 release.

Contents
[hide]

• 1 History
• 2 Features
• 3 Boot process
o 3.1 GRUB version 1
o 3.2 GRUB version 2
o 3.3 GRUB has loaded
• 4 Installation
• 5 Development
 o 5.1 Variants
• 6 GRUB configuration tools
• 7 Utilities
• 8 See also
• 9 Notes
• 10 References

• 11 External links

[edit] History
GRUB was initially developed by Erich Boleyn as part of work on booting the operating
system GNU Hurd developed by the Free Software Foundation.[2] In 1999, Gordon
Matzigkeit and Yoshinori K. Okuji made GRUB an official software package of the
GNU Project and opened the development process to the public.[2]

[edit] Features
GRUB is dynamically configurable. It loads its configuration at startup, allowing boot-
time changes such as selecting different kernels or initial RAM disks. To this end,
GRUB provides a simple, bash-like, command line interface which lets users write new
boot sequences on the fly in addition to the normal menu lists.

GRUB is highly portable. It supports multiple executable formats, and is geometry

translation independent. GRUB supports all commonly used Unix file systems, VFAT
and NTFS used by Windows, as well as Logical Block Address (LBA) mode. GRUB
allows users to view the contents of files on any supported file system.

GRUB can be used with a variety of different user interfaces. Most Linux distributions
take advantage of GRUB's support for a graphical interface to provide a customized boot
menu with a background image, and occasionally mouse support.[citation needed] GRUB's text
interface can be set to use a serial link to provide a remote terminal boot loader access.

GRUB can download operating system images from a network, and thus can support
diskless systems. GRUB supports automatic decompression of OS images prior to
booting from them.

GRUB uses a scrollable screen for operating system boot selection. This means 150 or
more boot choices can be easily controlled by GRUB by adding them to the "menu.lst"
configuration file. The arrow keys are used to select which operating system to boot.

Although Multiboot compliant, GRUB supports non-multiboot operating systems via

chain loading. GRUB uses the same two to three lines of command sequences to boot
any DOS, Windows, Linux, BSD or Solaris system, making it very easy to work with.
The chain loaders for the supported Unix like OS's are built into GRUB.

In addition to the normal menu interface GRUB can provide a bash-like terminal
command prompt that provides a rich set of commands to allow a user view or alter any
part of the boot process. With these tools it is possible, without prior knowledge of what
is installed on a computer, to use GRUB from an external device such as a floppy disk,
USB device or a CD-ROM to boot up an installed operating system.

A GRUB installation for any supported OS can be installed from any of the usual Unix-
like operating systems as well as using specific GRUB implementations for DOS and
Windows.
[edit] Boot process
When a computer is turned on, the computer's BIOS finds the primary bootable device
(usually the computer's hard disk) and loads the initial bootstrap program from the
master boot record (MBR), the first 512 bytes of the hard disk, then transfers control to
this code.

[edit] GRUB version 1

The MBR usually contains GRUB stage 1, but can contain another bootloader which can
chain boot GRUB stage 1 from another boot sector such as a partition's Volume boot
record. Given the small size of a boot sector, Stage 1 can do little more than load the next
stage of GRUB by loading a few disk sectors from a fixed location near the start of the
disk (within 1024 cylinders).

Stage 1 can load Stage 2 directly, but it's normally set up to load Stage 1.5. GRUB Stage
1.5 is located in the first 30 kilobytes of hard disk immediately following the MBR and
before the first partition. If this space is not available (Unusual partition table, special
disk drivers, GPT or LVM disk) the install of Stage 1.5 will fail. Stage 1.5 can contain
any drivers needed and so easily loads Stage 2. Stage 2 will then load the default
configuration file and any other modules needed.

[edit] GRUB version 2

This is very similar to Grub version 1, boot.img is stored in the MBR or Volume boot
record like Stage 1, however, it can load one sector from any LBA48 address. This loads
the first sector of core.img (generated from diskboot.img) which is then used to load the
rest of the generated core.img file. The core.img file will normally be stored in the same
location as Stage 1.5 with the same problems, however, it can be moved to a file system
or bare partition with fewer problems than moving or omitting Stage 1.5.

Once loaded the core.img file will then load the default configuration file and any other
modules needed.

[edit] GRUB has loaded

Once GRUB has loaded, it presents an interface where the user can select which
operating system to boot. This normally takes the form of a graphical menu. If this is not
available, or the user wishes direct control, GRUB has its own command prompt. The
user can then manually specify the boot parameters. GRUB can be set to automatically
load a specified kernel after a user defined timeout.

Once boot options have been selected, GRUB loads the selected kernel into memory and
passes control to the kernel. Alternatively, GRUB can pass control of the boot process to
another loader, using chain loading. This is the method used to load operating systems
such as Windows, that do not support the Multiboot standard. In this case, copies of the
other system's boot programs have been saved by GRUB. Instead of a kernel, the other
system is loaded as though it had been started from the MBR. This could be another boot
manager, such as the Microsoft boot menu, allowing further selection of non-Multiboot
operating systems.

[edit] Installation
A key feature of GRUB is that it can be installed without being attached to an operating
system. However, it needs a copy of a Linux image for such an installation. Working as a
stand alone system it is virtually a mini system in its own right and able to boot all the
installed major operating systems by chain loading, as described above.

Unlike LILO, there is no need to reinstall GRUB to the MBR or a partition after changes
to the configuration file.

In Linux, the "grub-install" command is used to install stage1 to either the MBR or a
partition. GRUB's configuration file, stage2 (usually), and other files must be in a usable
partition. If these files or the partition become unavailable, stage1 will drop the user to
the command line interface. As result, after deleting ubuntu form your computer, with
windows as second OS installed, the windows booting process will fail. Grub will launch
command line with message "grub error:unknown partition". To fix that user should boot
from windows installation disk, then boot the command line through “Windows repair”
and make bootrec changes. (bootrec/bootfix; bootrec/bootmbr). The issue is still under
discussion on ubuntu forums.

The name and disk location of the GRUB configuration file varies from system to
system. For example, in openSUSE and (for GRUB legacy) in Debian GNU/Linux the
file is stored in /boot/grub/menu.lst while Fedora, Gentoo Linux, and (for GRUB 2)
Debian uses /boot/grub/grub.conf. Fedora also provides a symbolic link from
/etc/grub.conf to /boot/grub/grub.conf for FHS compatibility reasons.

GRUB can be installed on removable media such as an optical drive (bios access, and el-
torito), floppy disk or USB flash drive in order to bring up a system which may not have
or cannot boot from a hard disk.

[edit] Development
The most commonly used version of GRUB is referred to as "GRUB Legacy". This
version is still receiving bug fixes, but no new features are being added. The GRUB
developers have switched their focus to GRUB 2,[3] a complete rewrite with goals
including making GNU GRUB cleaner, more robust, more portable and more powerful.
GRUB 2 started under the name PUPA. PUPA was supported by the Information-
technology Promotion Agency (IPA) in Japan. PUPA was integrated into GRUB 2
development around 2002, when GRUB version 0.9x was renamed GRUB Legacy.

Some of the goals of the project include support for non-x86 platforms,
internationalization/localization, non-ASCII characters, dynamic modules, memory
management, a scripting mini-language, migrating platform specific (x86) code to
platform specific modules, and an object-oriented framework. Ubuntu adopted GRUB 2
as its default boot loader on its 9.10 version.[4]

[edit] Variants

Since GRUB Legacy is still the most widely used version among end users, but official
development is being done on a different version, several other projects maintain their
own enhancements (forks) to the GRUB Legacy code. These include Super Grub Disk
(new commands include "setgrubdevice" and "usbshift") and GRUB4DOS.
GRUB4DOS is a universal boot loader that can boot off DOS/LINUX, or via Windows
boot manager/syslinux/lilo, or from MBR/CD. It also has builtin BIOS disk emulation,
ATAPI CDROM driver, etc.[5] It has enhanced several commands, including "find --set-
root", "map --hook", and "cdrom").[6]

OpenSolaris includes a modified GRUB Legacy which supports disklabels, automatic

64-bit kernel selection, and booting from ZFS (with compression and multiple boot
environments).[7][8] Syllable OS project made a modified version of GRUB to load the
system from its AtheOS File System.[9]

[edit] GRUB configuration tools

StartUp-Manager, a program used to configure GRUB

The setup tools in use by various distributions often include modules to set up GRUB:
for example, so do YaST2 on SUSE/openSUSE distributions and Anaconda on
Fedora/RHEL distributions. StartUp-Manager is a graphical configuration editor for
Debian distributions of GRUB.

[edit] Utilities
GRUB Utilities is a collection of multi-platform utilities for GRUB Legacy, GRUB2 and
GRUB for DOS.[10]

[edit] See also

Free software portal

Computer Science portal

• Comparison of boot loaders

• NTLDR

In computing, booting (also known as "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 power is switched on. The boot
loader typically loads the main operating system for the computer.

Contents
[hide]

• 1 History
• 2 Boot loader
o 2.1 Common primary boot loaders
 o 2.2 Second-stage boot loader
o 2.3 Network booting
• 3 Boot devices (IBM PC)
• 4 Boot sequence on standard PC (IBM-PC compatible)
o 4.1 Power On Self Test (POST)
• 5 Other kinds of boot sequences
o 5.1 Initial Program Load
• 6 Rebooting
o 6.1 Hard reboot
o 6.2 Soft reboot
o 6.3 Random reboot
o 6.4 Rebooting automatically
o 6.5 Errors
• 7 Quick boot
• 8 See also
• 9 References

• 10 Further reading

[edit] History
The computer word boot is short for "bootstrap" (itself short for "bootstrap load"). The
term bootstrap derives from the idiom pull oneself up by one's bootstraps.[1] The term
refers to the fact that a computer cannot run without first loading software but must be
running before any software can be loaded, which seems as impossible as to "pull
yourself up by your own bootstraps."[2]

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.[3][4] The term "boot" has been used in this sense
since at least 1958.[5]

The CDC 6600 (c. 1964) had a dead start panel with 144 toggle switches; the dead start
switch entered 12 words from the toggle switches to the memory of peripheral
processor (PP) 0 and initiated the load sequence. PP 0 loaded the necessary code into its
own memory and then initialized the other PP's.

The GE 645 (c. 1965) had a "BOOT" button.[6] It is possible that the contraction from
"bootstrap" to "boot" was motivated by an inclination to label the button with fewer,
larger characters, or the contraction may follow the familiar habit of contracting words to
make them easier to say, and to create insider jargon.

Some machines, like the Atari ST microcomputer, were "instant-on" with the operating
system executing from a ROM. Retrieval of the OS from secondary or tertiary store was
thus eliminated as one of the characteristic operations for bootstrapping. To
accommodate system customization for loading accessories and other support software
automatically, as part of the boot process, the Atari's floppy drive was read for the
additional components. There was a timeout delay, allowing time to manually insert a
floppy, as the system searched for the extra components, which could be avoided by
inserting a blank disk.

The Multics operating system (c. 1967) had a boot command.[7][8] 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.[9]

The bootstrap concept was used in the IBM 701 computer (1952–1956) which had a
"load button" ["load" button?] which initiated reading of the first 36-bit word from a
punched card in a card reader, or from a magnetic tape unit, or magnetic drum unit
(predecessor of the magnetic hard disk drive). The left 18-bit half-word was then
executed as an instruction which read additional words into memory.[10]

[edit] Boot loader

A computer's central processor can only execute program code found in Read-Only
Memory (ROM), Random Access Memory (RAM) or an operator's console. Modern
operating systems and application program code and data are stored on nonvolatile data
storage devices, such as hard disk drives, CD, DVD, flash memory cards (like an SD
card), USB flash drive, and floppy disk. When a computer is first powered on, it does not
have an operating system in ROM or RAM. The computer must initially execute a small
program stored in ROM along with the bare minimum of data needed to access the
nonvolatile devices from which the operating system programs and data are loaded into
RAM.

The small program that starts this sequence of loading into RAM, is known as a
bootstrap loader, bootstrap or boot loader. This small boot loader program's only job is
to load other data and programs which are then executed from RAM. Often, multiple-
stage boot loaders are used, during which several programs of increasing complexity
sequentially load one after the other in a process of chain loading.

Early computers (such as the IBM 650, DEC PDP-1 through PDP-8 and early models of
the PDP-11) had a row of dials or toggle switches on the front panel to allow the operator
to manually enter the boot instructions into memory before transferring control to the
CPU, or to directly pass an instruction to the CPU. The boot loader would then read in
either the second-stage boot loader (called Binary Loader of paper tape with checksum),
or the operating system 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:

1. Set the P register to 8

2. Check paper tape reader ready
3. If not ready, jump to 1
4. Read a byte from paper tape reader to accumulator
5. If end of tape, jump to 8
6. Store accumulator to address in P register
7. Increment the P register
8. 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.

1. Set the P register to 106

2. Check paper tape reader ready
3. If not ready, jump to 1
4. Read a byte from paper tape reader to accumulator
5. Store accumulator to address in P register
 6. Decrement the P register
7. 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 (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.

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 (or 440 bytes if Windows NT or above has to be supported because
NT put 6 byte disk-signature starting from offset 440) 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.

The Atari ST also had its operating system in ROM but, by inserting the Spectre GCR
cartridge with the Macintosh system ROM in the game slot and turning the Atari on, it
could "natively boot" the Macintosh operating system rather than Atari's own TOS
system. The Atari ST hardware was designed so the cartridge slot could provide native
program execution for gaming purposes as a holdover from Atari's legacy making
electronic games.

[edit] Common primary boot loaders

 • BIOS
• EFI
• OpenBIOS
• OpenBoot
• SLOF

[edit] 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, BOOTMGR, Syslinux, LILO or NTLDR. It will then be
able to load the operating system properly, and finally transfer execution to it. The
operating system will initialize itself, and may load device drivers that are needed for the
normal operation of the OS. After that it starts loading normal system programs.

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 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) or some
standalone program that can function without an operating system, such as memory
testers (e.g., memtest86+) or even games (see List of PC Booter games).[11] 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 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. Typical modern personal computers 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 and other software. Time spent after the
operating system loading can be considerably shortened by bringing the system with all
cores at once, as with coreboot[12] in as little as 3 seconds,[13] 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 software 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 operating system
and other software are loaded and ready to execute. Because operating systems are
designed as if they never start or stop, bootload processes sometimes load the operating
system, configure themselves as a mere process within that system, and then irrevocably
transfer control to the operating system. The bootload process then terminates normally
as any other process would, and the user need not have any awareness of the bootload.

[edit] Network booting

Main article: 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.

[edit] Boot devices (IBM PC)

• see also: System partition and boot partition

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.), a flash memory card such as an SD card in a multi-
media card slot, 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 GNU/Linux Live CD in order to try
out Linux without having to install an operating system onto the 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 F11 or ESC)

[edit] Boot sequence on standard PC (IBM-PC

compatible)
Upon starting, a personal computer's x86 CPU runs the instruction located at the memory
location CS:IP F000:FFF0 of the BIOS, which is located at the 0xFFFF0 linear address.
This memory location is close to the end of the 1MB of system memory accessible in
real mode. It typically 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
and initialize required devices. The BIOS goes through a pre-configured list of non-
volatile storage devices ("boot device sequence") until it finds one that is bootable. A
bootable device is defined as one that can be read from, and the last two bytes of the first
sector contain the word 0xAA55 (also known as the boot signature).

A hex dump of FreeBSD's boot0 MBR

Once the BIOS has found a bootable device it loads the boot sector to hexadecimal
Segment:Offset address 0000:7C00 or 07C0:0000 (maps to the same ultimate address)
and transfers execution to the boot code. In the case of a hard disk, 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 a partition set as bootable
(the one with active flag set).[14] If an active partition is found, the MBR code loads the
boot sector code from that partition 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 which will select a partition (often via user input) and load its boot sector,
which usually loads the corresponding operating system kernel.

Some systems (particularly newer Macintoshes) use Intel's proprietary EFI. Also
coreboot allows a computer to boot without having an over-complicated firmware/BIOS
constantly running in system management mode. The legacy 16-bit BIOS interfaces are
required by certain x86 operating systems, such as Windows. However most boot loaders
have 16-bit support for these legacy BIOS systems.[15][16][17]

AwardBIOS during booting. BIOS is dated to 1997

Most PCs, if a BIOS chip is present, will show a screen detailing the BIOS chip
manufacturer, copyright held by the chip's manufacturer and the ID of the chip at startup.
At the same time, it also shows the amount of computer memory available and other
pieces of information about the computer.

[edit] Power On Self Test (POST)

The computer power-on self-test tests the computer to make sure it meets the necessary
system requirements and that all hardware is working properly before starting the
remainder of the boot process. If the computer passes the POST, the computer may have
a single beep (with some computer BIOS suppliers it may beep twice) as the computer
starts and the computer will continue to start normally.

[edit] Other kinds of boot sequences

Some other processors have other kinds of boot modes:

1) There are alternative techniques for booting CPUs and microcontrollers:

• Some modern CPUs and microcontrollers (for example, TI OMAP) or sometimes

even DSPs may have boot ROM with boot code integrated directly into their
silicon, so such a processor could perform quite a sophisticated boot sequence on
its own and load boot programs from various sources like NAND flash, SD or
MMC card and so on. It is hard to hardwire all the required logic for handling
such devices, so an integrated boot ROM is used instead in such scenarios. Boot
ROM usage enables more flexible boot sequences than hardwired logic could
provide. For example, the boot ROM could try to perform boot from multiple
 boot sources. Also, a boot ROM is often able to load a boot loader or diagnostic
program via serial interfaces like UART, SPI, USB and so on. This feature is
often used for system recovery purposes when for some reasons usual boot
software in non-volatile memory got erased. This technique could also be used
for initial non-volatile memory programming when there is clean non-volatile
memory installed and hence no software available in the system yet.
• It is also possible to take control of a system by using a hardware debug interface
such as JTAG. Such an interface may be used to write the boot loader program
into bootable non-volatile memory (e.g. flash) by instructing the processor core to
perform the necessary actions to program non-volatile memory. Alternatively, the
debug interface may be used to upload some diagnostic or boot code into RAM,
and then to start the processor core and instruct it to execute the uploaded code.
This allows, for example, the recovery of embedded systems where no software
remains on any supported boot device, and where the processor does not have
any integrated boot ROM. JTAG is a standard and popular interface; many CPUs,
microcontrollers and other devices are manufactured with JTAG interfaces (as of
2009).
• Some microcontrollers provide special hardware interfaces which can't be used to
take arbitrary control of a system or directly run code, but instead they allow the
insertion of boot code into bootable non-volatile memory (like flash memory) via
simple protocols. Then at the manufacturing phase, such interfaces are used to
inject boot code (and possibly other code) into non-volatile memory. After
system reset, the microcontroller begins to execute code programmed into its
non-volatile memory, just like usual processors are using ROMs for booting.
Most notably this technique is used by Atmel AVR microcontrollers, and by
others as well. In many cases such interfaces are implemented by hardwired
logic. In other cases such interfaces could be created by software running in
integrated on-chip boot ROM from GPIO pins.

2) Most digital signal processors have the following boot modes:

• Serial mode boot

• Parallel mode boot, such as the host port interface (HPI boot)

It is worthwhile mentioning that in case of DSPs there is often a second microprocessor

or microcontroller present in the system design, and this is responsible for overall system
behavior, interrupt handling, dealing with external events, user interface, etc. while the
DSP is dedicated to signal processing tasks only. In such systems the DSP could be
booted by another processor which is sometimes referred as the host processor (giving
name to a Host Port). Such a processor is also sometimes referred as the master, since it
usually boots first from its own memories and then controls overall system behavior,
including booting of the DSP, and then further controlling the DSP's behavior. An
interesting thing here is that the DSP often lacks its own boot memories and relies on the
host processor to supply the required code instead. The most notable systems with such a
design are cell phones, modems, audio and video players, etc. where a DSP and a
CPU/microcontroller are co-existing.

Many FPGA chips load their configuration from an external serial EEPROM
("configuration ROM") on power-up.

[edit] 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.[18] 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 hexadecimal digit)
device address using rotary switches on the computer console, followed by pressing the
'IPL' button. This reads a tiny program (typically 24-bytes) 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.[18]

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.

[edit] Rebooting
[edit] Hard reboot

A hard reboot (also known as a cold reboot, cold boot or cold start) is when power to a
computer is turned off.[clarification needed (Discuss)] This starts 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 of a system freeze, critical
error or virus-inflicted DoS attack. It can also be used by intruders to access
cryptographic keys from RAM, in which case it is called a cold boot attack.[19] The attack
relies on the data remanence property of DRAM and SRAM to retrieve memory contents
which remain readable in the seconds to minutes after power has been removed.[19]

[edit] 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.[clarification needed
(Discuss)]

The Control-Alt-Delete key combination on the original PC from Sphere 1 was designed
to allow a soft reboot reducing wear on the hardware. This kind of reboot will not usually
reset the hard disks, so that they have time to update their write cache to permanent
storage. Hard disks will also keep their configuration (like C/H/S adjustments, HPA,
DCO, internal passwords...) over these reboots.
The Linux kernel has optional support for the kexec system call, which transfers
execution to a new kernel and skips hardware or firmware reboot. The entire process is
done independent of the system firmware. Note that the kernel being executed does not
have to be a Linux kernel.

[edit] 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 (BSOD) (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.

[edit] Rebooting automatically

Systems may reboot automatically at a scheduled time, after a power failure, or kernel
panic. The method by which this is done varies depending whether the reboot can be
handled in software, or must be handled at the firmware or hardware level.

[edit] 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, such as Linux
and Mac OS X, a fatal error in the boot process may cause a kernel panic.

[edit] Quick boot

Several devices are available that enable the user to "quick-boot" to a usually Linux-
powered OS for various simple tasks such as Internet access (Splashtop, Latitude ON
etc.).[20][21][22][23][24][25][26][27][28]