| The first step in the system boot process is controlled by processor-dependent code (PDC). On a multiprocessor system, PDC must first identify the controlling native processor, or monarch. The monarch is the first processor initialized, and it handles all of the early boot process. Each processor on the bus has a value called BOOT_ID, which is set at the factory to 2. Monarch selection begins by looking for the processor with the highest BOOT_ID. If there are multiple processors with the same BOOT_ID, the one with the lowest slot number becomes the monarch. BOOT_IDs are rarely changed, so the monarch is almost always the processor in the lowest slot. The monarch processor then continues with the boot process while all other processors idle, waiting for an interrupt. PDC next configures the initial memory module (IMM). This is the memory module that is mapped to physical address zero. The IMM selection is similar to the monarch selection process, and the IMM is the largest memory module. If there are multiple modules with the same size, the IMM is the one with the lower slot number. On most newer systems, the entire memory space appears to the system as a single module, so this selection process usually selects that one memory module. The module's soft physical address (SPA) is set to 0, mapping it to physical address zero. Now that the system has a monarch processor identified and memory mapped, the next step is to identify the boot and console devices. This is done by the boot console handler (BCH). BCH looks in the system's stable store to find the hardware path to the system console. Once the console path is initialized, it displays some system status information and then proceeds based on the settings of two flags in the stable store: Autoboot and Autosearch. If the Autoboot flag is set, BCH attempts to boot the system without interaction with the user. Without the Autoboot flag, BCH asks the user to verify the boot path. Autosearch allows BCH to search all I/O modules for bootable devices. Without Autosearch, BCH attempts to boot only from the primary path stored in stable storage. Table 15-1 summarizes the effects of Autoboot and Autosearch. Table 15-1. Autoboot and AutosearchAutoboot | Autosearch | Nickname | |
|---|
OFF | OFF | Manual boot | BCH interacts with the user to get the boot path. | OFF | ON | Boot search | BCH finds all bootable paths and presents the user with a list. The user must choose a boot path from the list. | ON | OFF | Auto boot | BCH attempts to boot from the primary path. If the boot fails, BCH prompts the user. | ON | ON | Auto search | BCH first tries the primary path. If that fails, BCH searches for bootable devices and tries to boot each one in turn. |
PDC expects a bootable device to begin with a logical interchange format (LIF) volume. More information about the format of a LIF volume can be found on the lif(4) man page. PDC looks for a LIF header at the beginning of the bootable device. Within this header is a value called IPL_ADDR, which is the offset of the initial program loader (IPL). Also in the header are IPL_SIZE and IPL_ENTRY, which specify the size of the IPL program and the address of the entry point to the program. PDC loads the IPL program into memory, then branches to the start address. The PA-RISC platform can run a variety of operating systems, including HP-UX, MPE, and Linux. The IPL program for each operating system is different. For HP-UX the IPL program is called ISL, for initial system loader. |
