At power up, a microprocessor unit needs initialization and self-test operations to load an operating system. Once the operating system is loaded, the microprocessor is ready to run application programs. Sometimes, an instruction is given to reboot or reset the operating system, i.e. to reload it. Booting or loading an operating system is different from installing it, which is generally an initial one-time activity, which stores the operating system source code on hard disk, where it is ready to be booted (loaded) into random access memory. The microprocessor unit’s storage is closer to the microprocessor and faster to work with than the hard disk, so when an operating system is installed, it is usually set up so that when the microprocessor unit is turned on, the system is automatically booted as well. If storage (memory) runs out, or the operating system or an application program encounters an error, it may display an error message or the screen may freeze. In this event, the operating system may need to be rebooted.
A boot or reboot system in a single multiprocessor makes use of central processing units (CPUs) of different types. On larger units (including mainframes), the equivalent term for boot is initial program load and for reboot it is reinitial program load. The booting of an operating system works by loading a very small program into the microprocessor set and then giving that program control so that it in turn loads the entire operating system. These operations routinely involve storing the config- uration table, initialization self-test code, and loading the operating system specific to each processor. The multiprocessor system automatically transfers initialization operations from a default processor to the first alternative if the default fails, and automatically transfers initialization oper- ations to a second alternative processor if the first fails, and so forth, depending upon how many processors are installed.
CODE STRUCTURES
The boot code of a microprocessor unit is a complex program set consisting mainly of BIOS and kernel, master boot record (MBR), and boot program.
15.1.1 BIOS and kernel
(1) BIOS
In computing, BIOS stands for basic input and output system, and refers to the software code run by a computer or a programmable controller when first powered on. Its primary function is to prepare the machine so other software programs can load, execute, and assume control. The other main respon- sibilities of the BIOS include booting the system, and providing the BIOS setup program that allows the changing of BIOS parameters.
When a computer or a controller is first turned on, the microprocessor needs some instructions for execution. However, since the machine has just been turned on, all the registers of its system memory are empty; there are no programs to run. To make sure that the BIOS program is always available to the microprocessor, even when first turned on, it is hard-wired into a read-only memory (ROM) chip on the system’s motherboard. A uniform standard was created between the makers of microprocessors and the makers of BIOS programs to ensure that the microprocessor would always look in the same place in memory to find the start register of the BIOS program. The microprocessor gets its first instructions from this location, and the BIOS program then begins executing. The BIOS program then begins the system boot sequence that calls other programs, and gets the operating system loaded, and the computer or controller can start running.
A microprocessor system can contain several BIOS firmware chips, particularly multiprocessor systems for supercomputers and programmable industrial controllers. The motherboard BIOS typically contains code to access fundamental hardware components such as the keyboard, ATA (IDE) hard disk controllers, USB ports, graphical user interfaces, and storage devices. The motherboard ensures that the instruction at the reset vector is a jump to the memory location mapped to the BIOS entry point. In addition, plug-in adapter cards such as SCSI, RAID, network interface cards, and video boards often include their own BIOS, complementing or replacing the system BIOS code for the given component. In some cases, where devices may also be used by add-in adapters, and actually directly integrated on the motherboard, the add-in ROM may also be stored as separate code on the main BIOS flash chip. It may then be possible to upgrade this add-in BIOS (sometimes called an option ROM) separately from the main BIOS code.
(2) Kernel
The kernel is a program that constitutes the central core of an operating system. It has complete control over everything that occurs in the system, and is the first part of the operating system to load into memory during booting, and it remains there for the entire duration of the session, since its services are required continuously. It is therefore important for it to be as small as possible while still providing all the essential services needed.
Because of its critical nature, the kernel code is usually loaded into a protected area of memory, which prevents it from being overwritten by other, less frequently used parts of the operating system, or by application programs. The kernel works in kernel space, whereas everything a user normally does, such as writing text or running programs is done in user space. This separation is made to prevent user data and kernel data from interfering with each other and thereby diminishing performance or causing the system to become unstable and possibly crash.
The kernel provides basic services for all other parts of the operating system, typically including memory, process file and I/O (input/output) management. These services are requested by other parts of the operating system or by application programs through a specified set of program interfaces referred to as system calls. The contents of a kernel vary considerably according to the operating system, but they typically include the following:
(a) a scheduler, which determines how the various processes share the kernel’s processing time (including in what order);
(b) a supervisor, which grants use of the controller or computer to each process when it is scheduled;
(c) an interrupt handler, which handles all requests from the various hardware devices (such as disk drives and the keyboard) that compete for the kernel’s services;
(d) a memory manager, which allocates the system’s address spaces (i.e., locations in memory) among all users of the kernel’s services;
(e) many (but not all) kernels also provide a “device I/O supervisor” category of services. These services, if available, provide a uniform framework for organizing and accessing the many hardware device drivers that are typical of an embedded system.
The kernel should not be confused with the BIOS. The latter is an independent program stored in a chip on the motherboard (the main circuit board of a computer or a controller) that is used during the booting process for such tasks as initializing the hardware and loading the kernel into memory. Whereas the BIOS always remains in the computer and is specific to its particular hardware, the kernel can be easily replaced or upgraded by changing or upgrading the operating system or, in the case of Linux, by adding a newer kernel or modifying an existing one.
Kernels can be classified into four broad categories: monolithic kernels, microkernels, hybrid kernels, and exokernels. Each has its own advocates and detractors.
When a computer or a programmable controller crashes, it actually means the kernel has crashed. If only a single program has crashed but the rest of the system remains in operation, then the kernel itself has not crashed. A crash is the situation in which a program, either a user application or a part of the operating system, stops performing its expected function(s) and wrongly responds to other parts of the system. The program might appear to the user to freeze. If such a program is critical to the operations of the kernel, the entire computer or controller could stall or shut down.
Master boot record (MBR)
When turning on a computer or a programmable controller, the processor attempts to begin processing data. But, since the system memory is empty, the processor does not really have anything to execute, or even begin to know where to look for it. To ensure that the microprocessor chipset will always boot regardless of the BIOS code, both chip and BIOS manufacturers developed their code so that the microprocessor, once turned on, always reads the first sector (sector zero) of the hard disk, which is called the master boot record (MBR), also referred to as the master boot sector or even just the boot sector. It then simply loads the contents of the MBR into memory and jumps to that location to start executing whatever code is in the MBR.
Similarly, every hard disk must have a consistent starting point where key information is stored about it, such as the number of partitions and what type they are. There also must be some place where the BIOS can load the initial boot program which starts the process of loading the operating system. The MBR is always located at cylinder 0, head 0, and sector 1; the first sector on the disk. This is the consistent starting point that the disk will always use, and is always consulted for instructions and information on how to proceed with the boot process and load the operating system.
As illustrated in Figure 15.1, the master boot record contains the following structures.
(a) Master partition table. This small bit of code, which is referred to as a table, contains a complete description of the partitions on the hard disk. When the developers designed the size of this master partition table, they left just enough room for the description of four partitions, hence the four partition (four physical partitions) limit. This is the reason that a hard disk may only have four
true partitions, also called primary or physical partitions. Any additional partitions must be logical ones that are linked to (or are part of) one of the primary partitions. One of the partitions is marked as active, indicating that it is the one that the computer or the controller should used to continue the boot process.
(b) Master boot code. The master boot record is the small bit of computer code that the BIOS loads and executes to start the boot process. This code, when fully executed, transfers control to the boot program stored on the boot (active) partition, which in turn loads the operating system.
The MBR working in the boot process has bootstrapping firmware contained within the ROM. The MBR of a drive usually includes its partition table, which is used to load and run the boot record of the partition that is marked with the active flag. This design allows the BIOS to load any operating system without knowing exactly where to start inside its partition. Because the MBR is read almost as soon as the computer or controller starts, many computer viruses work here before the virus scanner software is activated, by changing the code within it. Technically, only partitioned media contain a master boot record, while unpartitioned media only have a boot sector as the first sector. In both cases, the BIOS transfers control to the first sector of the disk after reading it into memory. A legacy that the MBR can have is partition selection code, which loads and runs the boot (first) sector of the selected primary partition. That partition boot sector contains another boot loader. Newer MBRs, however, can directly load the next stage from an arbitrary location on the hard disk drive. This can pose some problems with dual-booting, as the boot loader whose location is coded into the MBR must be configured to load each operating system. If one operating system must be reinstalled, it may overwrite the MBR such that it will load a different boot loader.
Boot program
Figure 15.2 gives code examples that can be used to boot a CPU with a microprocessor, and run a program (operating system or an application code) starting at the bottom of the first bank of Flash.
This code occupies the top 256 bytes of EEPROM, most of which is unused. The interrupt vectors are all forced to the boot program in EEPROM. These would normally point to interrupt service routines somewhere. The code examples in Figure 15.2 are written in the Motorola AS11 freeware assembler and are provided as examples only. There is no guarantee that the examples will work in a particular environment when applied.