In computing, booting starts your computer or computer device until it can be used. This can be started by hardware such as pressing a button, or by software command. Once the power is turned on the computer is relatively stupid, and can only read part of its storage called Read-only memory. There is a small stored program called the firmware. It performs a power-on self-test, and most importantly, lets access other types of memory, such as hard disk and main memory. Firmware loads a larger program into the main memory of the computer and runs it. In general the destination computer, but also in the smart phone, tablet, optional boot manager run. It lets users choose which operating system to run, and set more complex parameters for it. The firmware or boot manager then loads the boot loader into memory and runs it. This software can put the operating system kernel like Windows or Linux into the main memory of the computer, and run it. After that, the kernel runs what is called user space software, a well-known graphical user interface that lets users log in to a computer or run multiple other applications. The whole process can take a few seconds to a tenth of a second on a modern general purpose computer.
Restarting the computer is also called a "hard" reboot, for example, once the power to the CPU is switched from active to active, or "soft", where power is not clipped. On some systems, soft boot can optionally remove RAM to zero. Both hard and soft booting can be started by hardware such as pressing a button, or by software commands. Booting is complete when the operating system runtime, usually the operating system and some applications, is reached.
The process of restoring the computer from hibernation or sleep does not involve booting. At a minimum, some embedded systems do not require a real boot sequence to start functioning and when turned on it can easily run operational programs stored in ROM. All computing systems are state machines, and rebooting may be the only method to return to a predefined zero state of an unintentional and locked state.
In addition to loading a stand-alone operating system or utility, the boot process can also load a storage dump program to diagnose problems in the operating system.
Boot is short for bootstrap or bootstrap load and comes from the phrase to withdraw by someone bootstraps . use calls attention to the requirement that, if most of the software is loaded onto the computer by other software already running on the computer, some mechanism must exist to load the initial software onto the computer. The initial computer used various ad-hoc methods to get a small program into memory to solve this problem. The discovery of read-only memory (ROM) of various types solves this paradox by allowing the computer to be sent with an un-removable start-up program. ROM capacity growth has enabled more complicated start procedures to implement.
Video Booting
History
There are many different methods available for loading short start programs into the computer. These methods achieve from simple, physical inputs to removable media that can store more complex programs.
Examples of pre-circuit-ROM
Initial computer
Early computers in the 1940s and 1950s were one of the engineering efforts that could take weeks to load programs and programs was one of many problems to be solved. The initial computer, ENIAC, has no "program" stored in memory, but is set up for each issue with interconnect cable configuration. Bootstrapping does not apply to ENIAC, whose hardware configuration is ready to troubleshoot as soon as power is applied.
In 1960, the Ballistic Missile Early Warning System Displays Processor Information (DIP) in Colorado Springs? -? Before the NORAD facility was built in the Cheyenne Mountain Complex underground? -? Only run one program, which carries its own startup code. The program is stored as a continuous drum bit image on the magnetic drum, and is loaded in fractions of a second. The core memory may be emptied manually through the maintenance console, and startup from full power is fast, just a few seconds. In general design, DIP compares roughly with DEC PDP-8. Thus, it is not the one-button-pressed bootstrap type that comes later, or read-only memory (ROM) in tight terms, since the magnetic drums involved can be written to.
First commercial computer
The first preprogrammed computers for commercial sales, such as UNIVAC I and IBM 701 included features to make their operations simpler. They usually include instructions that perform complete input or output operations. The same hardware logic can be used to load the contents of punch cards (most common) or other input media, such as magnetic drums or magnetic tape, which contains a bootstrap program with the push of a button. This boot concept was called various names for IBM computers of the 1950s and early 1960s, but IBM used the term "Initial Load Program" with the IBM 7030 Stretch and then used it for their mainframe line, starting with System/360 in 1964.
The IBM 701 computer (1952-1956) has a "Load" button that begins reading the first 36-bit word into the main memory of the card in the card reader, magnetic tape drive, or magnetic drum unit, depending on the position of the Load Selector switch. The remaining 18-bit half-bit word is then executed as an instruction, which usually reads additional words into memory. The boot program that is loaded is then executed, which, in turn, loads a larger program of that medium into memory without further assistance from the human operator. The term "boot" has been used in this sense at least since 1958.
Other IBM computers of that era had similar features. For example, the IBM 1401 system (c 1958) uses a card reader to load programs from hollow cards. 80 characters stored in hollow cards are read into memory locations from 001 to 080, then the computer will branch off to the memory location 001 to read the first stored instruction. This instruction is always the same: move the information in the first 80 memory locations to the assembly area where the information in the hole cards 2, 3, 4, and so on, can be combined to form the stored program. After this information is transferred to the assembly area, the machine will branch off to instructions at location 080 (read card) and the next card will be read and the information processed.
Another example is IBM 650 (1953), a decimal machine, which has a group of ten 10-position switches on its operator panel addressed as a memory word (address 8000) and can be executed as an instruction. Thus setting switches to 7004000400 and pressing the corresponding key will read the first card in the card reader into memory (op code 70), starting at 400 and then jumping to 400 to start executing the program on the card.
Competitors IBM also offers the loading of one button program.
- CDC 6600 (c.1964) has a start dead panel panel with 144 toggle switches; the switch starts off entering 12 words from the toggle switch to memory peripheral processor ( PP ) 0 and starting the loading sequence. PP 0 loads the required code into its own memory and then initializes another PP.
- GE 645 (c 1965) has a "SYSTEM BOOTLOAD" button which, when pressed, causes one of the I/O controllers to load a 64-word program into memory from read-only diode memory and sends an interrupt causing the program to start running.
- The first model of the PDP-10 has a "READ" button which, when pressed, resets the processor and initiates the I/O operation on the device specified by the switch on the control panel, reading in a 36-bit word that gives the target address and is calculated for reading the next word; when the readout is complete, the processor begins to execute the code read by jumping to the last word read in.
Noteworthy variations of this can be found in Burroughs B1700 where there is no bootstrap ROM or disconnected IPL operation. Instead, once the system is reset, it reads and runs the opcode sequentially from a tape drive mounted on the front panel; this makes boot loader in RAM which is then executed. However, since this makes some assumptions about the system it can equally be used to load diagnostics (Routine Test Maintenance) tapes that display understandable code on the front panel even in case of gross CPU failure.
IBM IBM System/360 and router
In the IBM/360 System and its successors, including the current z/Architecture engine, the boot process is known as Initial Program Charges (IPL).
IBM coined this term for 7030 (Stretching), revived for the System/360 design, and continues to use it in that environment right now. In system/processor 360, IPL is initiated by the computer operator by selecting three hexadecimal digits (CUU; C = I/O Channel address, UU = Control unit and Device address) followed by pressing LOAD . In the upscale System/360 model, most of the System/370 and some systems in the future, the switch function and LOAD buttons are simulated using an area that can be selected on the graphics console screen, often in the form of devices like the IBM 2250 or IBM Devices like 3270. For example , on System/370 Model 158, the order of the keyboard 0-7-X (zero, seven and X, in that order) produces the IPL of the device address entered into the input area. Amdahl 470V/6 and associated CPUs support four hexadecimal digits on CPUs that have optional second channel units installed, for a total of 32 channels. Later, IBM will also support more than 16 channels.
The IPL function in the/360 System and its successors, and compatibilities such as Amdahl, reads 24 bytes from the device specified by the operator to the main storage starting from the true address zero. The second and third groups of the eight bytes are treated as Channel Command Words (CCWs) to continuously load the startup program (the first CCW is always simulated by the CPU and consists of the Read IPL command, 02h , with chaining and long indication the wrong ones are enforced). When the I/O channel command is complete, the first group of eight bytes is then loaded into the Program Status Word (PSW) processor and the startup program initiates the execution at the location specified by the PSW. IPL devices are usually disk drives, so the special meaning of the 02h type read command, but the exact same procedure is also used for IPL from other input type devices, such as tape drives, or even card readers, in a way free-of-device, enabling, for example, the installation of the operating system on a new computer from the OS's initial magnetic distribution tape. For disk handlers, the 02h command also causes the selected device to search the 0000h cylinder, head 0000h , simulates the cylinder command and the Search head, 07h , and to search for the 01h record, simulate the Equal ID Search command, 31h ; searching and searching are not simulated by tape and card controllers, as for this device class the 02h command is just a sequential read command instead of the IPL Read command.
The disk, tape or deck of the card must contain a special program to load the actual operating system or stand-alone utility into the primary storage, and for this particular purpose the "IPL Text" is placed on disk by a stand-alone DASDI (Direct Access Storage Device Initialization) program or equivalent programs that run under the operating system, for example, ICKDSF, but IPL cassette and deck cards are usually distributed with this "IPL Text" already present.
Minicomputer
Minicomputers, starting with Digital Equipment Corporation (DEC) PDP-5 and PDP-8 (1965) are simplified by using the CPU to assist input and output operations. This saves money but makes booting more complicated than pressing a button. Minicomputers usually have several ways to shortcut in short programs by manipulating array switches on the front panel. Since the initial minicomputer uses magnetic core memory, which does not lose its information when power is off, this bootstrap loader will remain in place unless it is deleted. Deletion sometimes happens by accident when a program bug causes a loop that overwrites all memory.
Other Minikomputer with simple boot form such as HP 2100 series Hewlett-Packard (mid 1960s), Original Genuine Data Nova (1969), and DEC's PDP-11 (1970).
The DEC then adds an optional read-only matrix diode memory for the PDP-11 which stores the bootstrap program for up to 32 words (64 bytes). It consists of a printed circuit card, M792, which is plugged into Unibus and held 32 by 16 semiconductor diode arrays. With all 512 diodes, the memory contains all the "one" bits; the card is programmed by cutting each diode whose bit becomes "zero". DEC also sells the card version, BM792-Yx series, already programmed for many standard input devices by simply removing unnecessary diodes.
Following the older approach, the PDP-1 previously had a hardware loader, so the operator just had to hit the "load" switch to instruct the paper tape reader to load the program directly into the core memory. General Supernova data using front panel switches causes the computer to automatically load instructions into memory from the device specified by the front panel data switch, and then jumps to the loaded code; Nova 800 and 1200 have switches that load the program into the main memory of the special read-only memory and jump to it.
Example early mini computer boot loader
In a mini-computer with a paper tape reader, the first program that runs in the boot process, the boot loader, will read into the core memory of both the second stage boot loader (often called Binary Loader ) which can read the paper ribbon with the checksum or operating system of external storage media. Pseudocode for the boot loader may be as simple as the following eight instructions:
- Set the list P to 9
- Check reader of ready paper ribbon
- If not ready, skip to 2
- Read the bytes from the paper tape reader to the accumulator
- Save the accumulator to the address in the P list
- If the end of the tape, skip to 9
- Increase P list
- Jump to 2
The related example was based on a loader for the Nicolet Instrument Corporation minicomputer of the 1970s, using a paper-reader unit on the Teletype Model 33 ASR teleprinter. The byte of the second stage loader is read from the paper tape in reverse order.
- Set P list to 106
- Check reader of ready paper ribbon
- If not ready, skip to 2
- Read the bytes from the paper tape reader to the accumulator
- Save the accumulator to the address in the P list
- Lower P list
- Jump to 2
The length of the second stage loader is such that the last byte overwrites the location 7. After the instruction at location 6 starts, location 7 starts the second stage loader that is run. The second stage loader then waits for a longer recording containing the operating system to be placed in the tape reader. The difference between boot loader and second stage loader is the addition of checking code to trap paper readout errors, often with relatively cheap "part-time" hardware such as Teletype Model 33 ASR. (Fridays Flexowriters are much more reliable, but also relatively expensive.)
Boot the first microcomputer
The earliest microcomputers, such as the Altair 8800 (first released in 1975) and earlier, more similar machines (based on the Intel 8008 CPU) do not have such boot boot devices. When started, the CPU will see a memory that will contain executable code that contains only binary zero - the memory is deleted with reset when it is turned on. The front panel of this machine carries a toggle switch for entering addresses and data, one button per bit from said computer memory and address bus. A simple addition to the hardware allows one memory location at a time to load from that switch to store the bootstrap code. Meanwhile, the CPU is saved from attempts to execute memory content. Once loaded correctly, the CPU is enabled to execute bootstrap code. This process is tedious and must be error free.
Era of read-only integrated-circuit memory
The boot process was revolutionized by the introduction of integrated read-only memory (ROM), with many variants, including programmable ROM mask, programmable ROM (PROM), erasable programmable ROM (EPROM), and flash memory. This allowed firmware boot program will be sent on the computer. The introduction of ROM (external) is in the Italian telephone switching elaborator, called "Gruppi Speciali", patented in 1975 by Alberto Ciaramella, a researcher at CSELT. Gruppi Speciali is, starting from 1975, a single-key machine that fully boots into the operating system from a semiconductor-made ROM memory instead of a ferrite core. Although the ROM device is not embedded naturally in Gruppi Speciali computers, due to the design of the machine, it also allows single-button ROM booting on machines not designed for it (hence, this "bootstrap device" is architecture-independent), eg PDP- 11. Storing machine status after switch also applies, which is another important feature in the telephone switching contest.
Typically, each microprocessor will, after a reset or power-on condition, perform a start-up process that typically takes the form "start execution code found starting from a particular address" or "search for multibyte code at a specified address and jump to the indicated location to start execution ". The system built using the microprocessor will have a permanent ROM that occupies this special location so that the system always starts operating without the help of the operator. For example, the Intel x86 processor always starts by executing the instructions starting at F000: FFF0, while for the MOS 6502 processor, initialization begins by reading the two-byte vector address in $ FFFD (MS byte) and $ FFFC (LS byte) and jumping to that location to run bootstrap code.
Apple Inc.'s first computer, Apple 1 introduced in 1976, featured a PROM chip that eliminates the need for a front panel for booting (as is the case with the Altair 8800) on a commercial computer. According to Apple's advertisement announcing "No More Switches, No More Lights... the firmware in PROMS allows you to insert, display, and debug programs (all in hex) from the keyboard."
Because of the read-only memory costs at the time, the Apple II series booted its disk operating system using a series of very small additional steps, each passing control to the next stage of the gradually more complex boot process. (See Apple DOS: Boot loader). Because very few of the disk operating systems rely on ROM, the hardware is also very flexible and supports multiple customized copy disk protection mechanisms. (See Software Cracking: History.)
Some operating systems, especially Apple's pre-1995 Macintosh system, are so tightly intertwined with hardware that it is impossible to boot the operating system apart from standard ones. This is the opposite of the scenario using the above mentioned switches; it's very inflexible but relatively error-proof and very easy as long as all hardware is working normally. A common solution in such situations is to design a boot loader that functions as a program that belongs to a standard OS that hijacks the system and loads an alternate OS. This technique is used by Apple for the implementation of A/UX Unix and copied by various freeware operating systems and BeOS Personal Edition 5.
Some machines, such as Atari ST microcomputers, are "instant-on", with operating systems executing from ROM. The retrieval of the OS from a secondary or tertiary store is thus omitted as one of the characteristic operations for bootstrapping. To allow for customization of systems, accessories, and other support software to be loaded automatically, Atari's floppy drive is read for additional components during the boot process. There is a waiting time delay that provides time to manually insert the diskette as the system searches for additional components. This can be avoided by inserting a blank disc. Atari ST hardware is also designed so that the cartridge slot can provide original program execution for game purposes as a relic of Atari's legacy of electronic gaming; by inserting the GCR Spectre cartridge with the Macintosh system ROM in the game slot and enabling Atari, it can "natively boot" the Macintosh operating system rather than Atari TOS itself.
IBM Personal Computer includes a ROM-based firmware called BIOS; one of the functions of the firmware is to perform self power tests when the computer starts up, and then read the software from the boot device and run it. Firmware compatible with BIOS on IBM Personal Computer is used in computers compatible with IBM PCs. The Extensible Firmware Interface was developed by Intel, originally for Itanium-based machines, and later also used as an alternative to BIOS on x86-based machines, including Apple Macs using Intel processors.
The Unix workstation initially has vendor-specific ROM-based firmware. Sun Microsystem then developed OpenBoot, which became known as Open Firmware, which uses Forth interpreters, with many firmware written in Forth. It's standardized by IEEE as standard IEEE 1275-1994; firmware that implements the standard is used in PowerPC-based Macs and some other PowerPC-based machines, and Sun's own SPARC-based computers. Advanced Specifications RISC Computing defines other firmware standards, which are implemented on some MIPS-based and Alpha-based machines and workstations based on x86 SGI Visual workstations.
Maps Booting
Modern boot loader
When the computer is turned off, the software? -? Including operating system, application code, and data? -? It remains stored in non-volatile memory. When the computer is turned on, it usually does not have an operating system or its loader in random access memory (RAM). The computer first runs a relatively small program stored in read-only memory (ROM) along with a small amount of data needed, to access non-volatile devices or devices from which operating system programs and data can be loaded into RAM.
Small programs that start this sequence are known as bootstrap loaders, bootstrap or boot loader. The only task of this small program is to load data and other programs that are then run from RAM. Often, multi-stage boot loaders are used, where some complexity improvement programs load one by one in the chain loading process.
Some computer systems, after receiving a boot signal from a human operator or peripheral device, can load a 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 usually start the input operation of some peripheral devices (which can be selected by the operator). Other systems can send hardware commands directly to peripheral devices or I/O controllers that cause very simple input operations (such as "read zero sector from system device into memory starting from location 1000") to do, effectively load small amount boot loader instruction into memory; the settlement signal from the I/O device can be used to initiate CPU instruction execution.
Smaller computers often use a more flexible but more automated boot loader mechanism to ensure that computers start up quickly and with predefined software configurations. On many desktop computers, for example, the bootstrap process begins with software that executes the CPU contained in ROM (for example, BIOS from an IBM PC) at a predetermined address (multiple CPUs, including the Intel x86 series designed to execute this software after reset without outside help). The software contains incomplete functionality to search for devices that are eligible to participate in the boot, and load small programs from special sections (most often boot sectors) from the most promising devices, usually starting at a fixed entry point like the start of the sector.
First level boot loader
Boot loaders may face strange obstacles, especially in size; for example, on IBM PCs and compatibles, the boot sector should normally work only in 32 KB (then 64 KB) of system memory and not use instructions that are not supported by the original 8088/8086 processor. The first stage of the PC boot loader (FSBL, first-stage boot loader) located on fixed disks and removable drives must match the first 446 bytes of the Master Boot Record to leave space for the default 64-byte partition table with four partition entries and alerts two-byte boot hands, the required BIOS for the proper boot loader - or even less, when additional features like more than four partition entries (up to 16 by 16 bytes each), disk signature (6 bytes), disk timestamp (6 bytes), Advanced Active Partition (18 bytes) or a dedicated multi boot loader must also be supported in some environments. In Archive Volume Boot floppy and superfloppy, up to 59 bytes are occupied for Extended BIOS Parameter Block on FAT12 and FAT16 volumes since DOS 4.0, while FAT32 EBPB introduced with DOS 7.1 requires even 71 bytes, leaving only 441 bytes for boot loader when assuming sector size 512 bytes. The Microsoft boot sector therefore has traditionally imposed certain restrictions on the boot process, for example, the boot file must be placed in a fixed position in the root directory of the file system and stored as a successive sector, the conditions handled by the SYS Command and a little relaxed in newer DOS versions. The boot loader can then load the first three sections of the file into memory, which happens to contain other embedded boot loaders that can load the rest of the files into memory. When they added LBA and FAT32 support, they even switched to a two-sector boot loader using 386 instructions. At the same time, other vendors managed to squeeze more functions into a single boot sector without relaxing the original constraints on less memory and available processor support. For example, the DR-DOS boot sector can find boot files in the FAT12, FAT16 and FAT32 file systems, and load them into memory as a whole via CHS or LBA, even if the files are not stored in fixed locations and in successive sectors.
Examples of first-level bootloaders include coreboot, Libreboot, and U-Boot Das.
Secondary boot loader
The second stage boot loader, such as GNU GRUB, BOOTMGR, Syslinux, NTLDR, or BootX, is not an operating system, but can load the operating system properly and transfer the execution to it; the operating system then initializes itself and can load additional device drivers. The second stage boot loader does not require drivers for its own operation, but can use generic storage access methods provided by system firmware such as BIOS or Open Firmware, although usually with limited hardware and lower performance functions.
Many boot loaders (such as GNU GRUB, Windows BOOTMGR, and NTLDR Windows NT/2000/XP) can be configured to provide multiple boot options to users. This option may include different operating systems (for dual or multi-booting of different partitions or drives), different versions of the same operating system (in case the new version has unexpected problems), different operating system loading options (eg , boot into rescue mode or secure), and some standalone programs that can work without an operating system, such as a memory tester (eg, memtest86), basic shell (as in GNU GRUB), or even games (see PC Booter Game list). Some boot loaders can also load other boot loaders; for example, GRUB loads BOOTMGR instead of loading Windows directly. Usually the default option is previously selected with a time delay where the user can press a button to change the selection; after this delay, the default option is automatically executed so that a normal boot can occur without interaction.
The boot process can be considered completed when the computer is ready to interact with the user, or the operating system is capable of running the system program or application program.
Many embedded systems should boot up immediately. For example, waiting a minute for a digital television or GPS navigation device to start is generally unacceptable. Therefore, the device has a software system in ROM or flash memory so that the device can start functioning immediately; little or no loading is required, because loading can be predicted and stored in ROM when device is created.
Large and complex systems may have boot procedures running in several phases until eventually the operating system and other programs are loaded and ready to run. Because the operating system is designed as if it never started or stopped, the boot loader may load the operating system, configure itself as a mere process within the system, and then transfer the transfer to the operating system irrevocably. The boot loader then stops normally as any other process.
Boot network
Most computers are also capable of booting over a computer network. In this scenario, the operating system is stored on the server disk, and certain parts are transferred to the client using a simple protocol such as Trivial File Transfer Protocol (TFTP). After these parts are transferred, the operating system takes over the control of the boot process.
Like a second-stage boot loader, network booting begins using a common network access method provided by the network interface's ROM boot, which usually contains a Preboot Execution Environment (PXE) image. No driver is required, but system functionality is limited until the kernel and operating system drivers are transferred and started. As a result, once ROM-based booting is complete, it is possible to boot boot into an operating system that does not have the ability to use a network interface.
Personal computer (PC)
Boot devices
The boot device is the device from which the operating system is loaded. UEFI or BIOS firmware Modern PCs support booting from multiple devices, usually local solid state drives or hard disk drives via GPT or Master Boot Record (MBR) on such drives or disks, optical disk drives (using El Torito), USB mass storage devices (FTL-based flash drives, SD cards, or multi-media card slots; hard disk drives, optical disk drives, etc.), or network interface cards (using PXE). Older and less common BIOS-bootable devices include floppy disk drives, SCSI devices, Zip drives, and LS-120 drives.
Normally, firmware (UEFI or BIOS) will allow the user to configure boot sequence . If the boot sequence is set to "first, DVD drive; second, hard disk drive", then the firmware will try to boot from the DVD drive, and if this fails (eg since there is no DVD in the drive), it will try to boot from the hard disk local drive.
For example, on a PC with Windows XP installed on the hard drive, the user can set the boot sequence to the one given above, and then insert the Linux Live CD to try Linux without having to install the operating system onto the hardware. This is an example of dual booting, where the user selects the operating system to run after the computer has performed a POST (Power-on self-test). In this dual boot example, the user selects by inserting or removing the CD from the computer, but it is more common to choose which operating system to boot by selecting from the BIOS or UEFI boot menu, using the computer keyboard; the boot menu is usually entered by pressing Delete or F11 during POST.
Several devices are available that allow users to quick boot into what is usually a Linux variant for a variety of simple tasks such as Internet access; examples are Splashtop and Latitude ON.
Boot sequence
After starting, the x86 CPU of IBM compatible personal computer executes, in real mode, the instruction located in the reset vector (physical memory address FFFF0h on the 16-bit x86 processor and FFFFFFF0h on 32-bit and 64-bit x86 processors), usually pointing to the firmware entry point (UEFI or BIOS) inside the ROM. This memory location usually contains leap instructions that transfer execution to the start-up firmware program location (UEFI or BIOS). The program runs a power self-test (POST) to check and initialize required devices such as DRAM and PCI bus (including running embedded ROMs). The most complicated step is to prepare DRAM over SPI, made more difficult by the fact that at this point the memory is very limited.
After initializing the required hardware, firmware (UEFI or BIOS) via a pre-configured list of pre-volatile storage devices ("boot device sequence") until it finds bootable. A bootable boot MBR device is defined as a readable device, and where the last two bytes of the first sector contain the little-endian AA55h , found as a byte order 55h , AAh on disk (also known as MBR boot signature), or where it is not specified that the code inside this sector can be executed on x86 PC.
Once the BIOS has found a bootable device, it will load the boot sector to the linear address 7C00h (usually segment: offset 0000h : 7C00h , but some wrong BIOS uses 07C0h : 0000h ) and executes the transfer to the boot code. In the case of hard disks, this is called the Master Boot Record (MBR) and by definition is not a special operating system. The conventional MBR code checks the MBR partition table for the partition set as bootable (the one with set active ). If an active partition is found, the MBR code contains the boot sector code of the partition, known as the Volume Boot Record (VBR), and executes it.
VBR is often a special operating system; However, in most operating systems, the main function is to load and run the operating system kernel, which continues the startup.
If no active partition exists, or the active partition boot sector is invalid, the MBR can load a secondary boot loader that will select the partition (often via user input) and load the boot sector, which usually loads the appropriate operating system kernel. In some cases, the MBR can also try loading the secondary boot loader before trying to boot the active partition. If all else fails, it should issue interrupt BIOS interfaces INT 18h (followed by INT 19h only in case INT 18h will return) to give back control to the BIOS, which then will try to disassemble other devices, try to boot remotely over the network or enable ROM BASIC.
Some systems (especially newer Macintoshes and newer editions of Microsoft Windows) use Intel EFI. Also coreboot allows the computer to boot without firmware/BIOS constantly running in system management mode. The 16-bit BIOS interface is required by certain x86 operating systems, such as DOS and Windows 3.1/95/98 (and all when not booted through UEFI). However, most boot loaders maintain 16-bit BIOS call support.
Other types of boot sequence
Some modern CPUs and microcontrollers (eg, TI OMAP) or sometimes even DSP may have boot ROMs with boot code integrated directly into their silicon, so such processors can do quite a sophisticated boot sequence themselves and load boot programs from various sources such as flash NAND, SD or MMC card and so on. It is difficult to set up all the logic required to handle the device, so integrated ROM boot is used instead of in the scenario. The use of Boot ROM allows boot sequences that are more flexible than those required by embedded logic. For example, boot ROM can try to boot from multiple boot sources. Also, boot ROM can often load a boot loader or diagnostic program via serial interface such as UART, SPI, USB, and so on. This feature is often used for system recovery purposes when for some reason the regular boot software in non-volatile memory is erased, and it can also be used for early non-volatile memory programming when there is net non-volatile memory installed and hence no software is available in the system.
Some embedded system designs may also include an intermediate boot sequence step in the form of additional code that is loaded into the system RAM by the integrated boot ROM. Additional code that is loaded that way usually serves as a way to overcome the limitations of the platform, such as small amounts of RAM, so that a special primary boot loader, such as Das U-Boot, can be loaded as the next step in the system boot sequence. The additional code and boot sequence steps are usually referred to as the secondary program loader (SPL).
It is also possible to control the system by using a hardware debug interface such as JTAG. Such an interface can be used to write boot loader programs into non bootable memory (eg flash) by instructing the processor core to perform the actions necessary to program non-volatile memory. Or, the debug interface can be used to upload multiple diagnostics or boot code into RAM, and then start the processor core and order it to execute the code uploaded. This allows, for example, embedded system recovery where no software is left on supported boot devices, and where the processor does not have an integrated boot ROM. JTAG is a standard and popular interface; many CPUs, microcontrollers and other devices are manufactured with JTAG interface (as of 2009).
Some microcontrollers provide special hardware interfaces that can not be used to extract arbitrary control of a system or run code directly, but they allow the insertion of boot codes into non bootable memory (such as flash memory) via protocol simple. Then in the creation phase, such interfaces are used to inject boot code (and possibly other codes) into non-volatile memories. After the system reset, the microcontroller starts executing code that is programmed into non-volatile memory, just like a regular processor that uses ROM to boot. Especially this technique is used by Atmel AVR microcontroller, and by others too. In many cases, such interfaces are implemented by wired logic. In other cases, the interface can be created by software running on the boot boot boot boot from GPIO pin.
Most digital signal processors have serial boot modes, and parallel boot modes, such as a host port interface (HPI boot)
In the case of DSPs there are often microprocessors or microcontrollers both present in system design, and these are responsible for overall system behavior, handling interrupts, dealing with external events, user interfaces, etc. while DSP is dedicated to signal processing only tasks. In such systems the DSP can be booted by another processor sometimes referred to as the host processor (naming it to Port Host). Such processors are sometimes also referred to as masters , as they usually boot first from their own memories and then control the overall behavior of the system, including booting from the DSP, and then further controlling the behavior of the DSP. DSPs often do not have their own boot memory and rely on the host processor to provide the required code. The most prominent systems with such designs are cell phones, modems, audio and video players and so on, where DSP and CPU/microcontroller work together.
Many FPGA chips load their configuration from external serial EEPROM ("ROM configuration") on power-up.
See also
Note
References
External links
- Change Boot Sequence in BIOS
- The boot loader tutorial is practical for ATmega microcontrollers
- Boot with GRUB, OSDEV Community, May 4, 2006, archived from the original on February 10, 2007
- x86 BootStrap Programming Tutorial
- The boot process is described: Linux, FreeBSD, MacÃ, OSÃ, X on PowerPC, EFI, ARC, DOS/Windows, and Windows NTÃ, 6
Source of the article : Wikipedia
0 Comments