Industrial Technology Department Computer Software Application “Personal Computers” Prepared by: Albert Patrick J. David, ECT
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 via the Master Boot Record (MBR) (and of several MS-DOS partitions on such a disk, or GPT through GRUB 2), an optical disc drive (using El Torito ), a USB mass storage device (FTL-based flash drive, SD card, or multi-media card slot; hard disk drive, optical disc drive, etc.), or a network interface card (using PXE). Older, less common BIOS-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 “first, the DVD drive; second, 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
Boot Sequence Upon starting, an IBM-compatible personal computer’s x86 CPU executes, in real mode, the instruction located atreset vector (the physical memory address FFFF0h on 16-bit x86 processors and FFFFFFF0h on 32-bit and 64-bit x86 processors), usually pointing to the BIOS entry point inside the ROM. This memory location 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 such as DRAM and the PCI bus (including running embedded ROMs). The most complicated step is setting up DRAM over SPI, made more difficult by the fact that at this point memory is very limited. After initializing required hardware, the BIOS goes through a pre-configured list of nonvolatile storage devices (“boot device sequence”) until it finds one that is bootable. Once the BIOS has found a bootable device it loads the boot sector to linear address 7C00h (usually segment:offset0000h:7C00h, but some BIOS’es erroneously use 07C0h:0000h) and transfers execution to the boot code.
Boot Sequence In the case of a hard disk, this is referred to as the Master Boot Record (MBR) and is by definition 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). If an active partition is found, the MBR code loads the boot sector code from that partition, known as Volume Boot Record (VBR), and executes it. The VBR 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 and new editions of Microsoft Windows) use Intel’s EFI. Also coreboot allows a computer to boot without having the firmware/BIOS constantly running in system management mode. 16-bit BIOS interfaces are required by certain x86 operating systems, such as DOS and Windows 3.1/95/98 (and all when not booted via UEFI). However, most boot loaders retain 16-bit BIOS call support.
Other kinds of Boot Sequence 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. Some embedded system designs may also include an intermediary boot sequence step in form of additional code that gets loaded into system RAM by the integrated boot ROM. Additional code loaded that way usually serves as a way for overcoming platform limitations, such as small amounts of RAM, so a dedicated primary boot loader, such as Das U-Boot, can be loaded as the next step in system’s boot sequence. The additional code and boot sequence step are usually referred to as secondary program loader (SPL)
Other kinds of Boot Sequence 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).
Other kinds of Boot Sequence Some microcontrollers provide special hardware interfaces which cannot 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. Most digital signal processors have a serial mode boot, and a parallel mode boot, such as the host port interface (HPI boot)
POST (Power-On Self TesT ) A Power-On Self-Test (POST) is an operation initiated by a computer after it has been turned on but before it boots up the OS. The computer's firmware -- BIOS , Unified Extensible Firmware Interface ( UEFI ) or another system -- carries out this operation by running a diagnostic testing sequence to determine if the computer's essential hardware is working properly.
POST (Power-On Self TesT ) When a POST is completed successfully, bootstrapping -- which starts the initialization of the boot-up -- is enabled. In computing, bootstrap means to boot or load a program, usually an OS, onto a computer using a much smaller initial program. Computers aren't the only devices that use POSTs. Some appliances, medical equipment and other hardware run similar self-tests after being turned on.
POST (Power-On Self TesT )
How Power-On Self-Test works? The way in which a computer carries out the POST process depends on the system's hardware architecture and installed firmware . Generally, the process verifies the viability of all the hardware necessary to ensure the OS and applications can run properly. This typically includes the following devices: processors, memory, storage, controllers, keyboard, pointer device and system timer.
How Power-On Self-Test works? The exact list of hardware devices will depend on the system. A POST operation might also perform other tasks, such as verifying the firmware, validating hardware configurations or initializing the hardware. During the POST process, a user might see some indication that it's underway. For example, hardware lights might flash, or the screen might display a company logo. However, today's computers are so fast that they usually zip right through their POST operations with little indication, unless there's a problem. If the necessary hardware is detected and operating properly, the computer continues with the rest of the boot process.
How Power-On Self-Test works? If the specified hardware isn't detected or operating properly, the firmware usually stops the boot process and issues an error message. The message might be displayed on the computer's screen, sent as a series of coded beeps or both, depending on the nature of the problem. Because the POST operation runs before the computer's graphics card is initialized, it might not be possible to display error information on the screen, in which case, the computer uses only beeps. The pattern of beeps depends on the system architecture, the type of firmware installed and vendor choices. In general, the pattern is meant to reflect the type of error or at least provide a general sense of where to look for the error. For example, the system might emit three long beeps if there's a problem with the keyboard card or one long and two short beeps if the problem is related to the display adapter.
How Power-On Self-Test works? An error found during the POST operation is usually fatal and will halt the boot process. This is because the hardware being checked is essential for the computer's functions. For the same reason, other types of electronic devices might also run POST operations when they start up.