Booting

Booting a system refers to a sequence of events that loads and executes the operating system code. This sequence, orboot procedure, begins at power-on with the system in an unknown state and ends when the system begins executing the operating system.

Hardware reset

When power is applied to the system, all controllers receive a power-up reset signal. Hardware initialization occurs within the first few clocks after the reset pulse is negated.

The reset signal has the following effects:

EPAC initialization—Hard error reporting is disabled, and all error registers hold their previous values if a hard error was logged before reset was applied. The identification number of each processor is loaded into a CSR. The registers can only be cleared by software.
EPUC initialization—Hard error reporting is disabled, and all error registers are cleared. All other EPUC CSRs hold their previous values and can only be cleared by software.
EPIC initialization—Hard error reporting is disabled, and all error registers hold their previous values. The registers can only be cleared by software.
ERAC initialization—Hard error reporting is disabled, and all error registers hold their previous values. The registers can only be cleared by software. All ports are enabled.
EMAC initialization—Hard error reporting is disabled, and all error registers hold their previous values if a hard error was logged before reset was applied. The registers can only be cleared by software.

Power-On Self Test routine

When the system first powers up, all processors and supporting hardware must be initialized before the system proceeds with booting.

Upon power up, POST begins executing and brings up the system from an indeterminate state and then executes OBP. POST determines the system hardware configuration before running OBP. If POST encounters an error during initialization, it passes the appropriate error code to an LCD.

Figure 10-2 “POST program flow” shows how POST initializes the processors up to booting of OBP.

Figure 10-2 POST program flow

Basic processor initialization and selftest

Upon reset, all processors are initialized and placed in selftest. The extent of the selftest is determined by a mode bit in NVRAM. If both the selftest and cache test NVRAM variables are enabled, cache testing is performed. Data cache initialization is verified, and the portion of the instruction cache used for memory initialization is pattern tested.

Each processor determines its identification (ID) from the EPAC. Also, each processor fetches the Processor Semaphore register on the PUC. Because register requests are queued, one processor will fetch this CSR before the others and becomes the booting, or monarch, processor. All others go into a command wait idle loop. The booting processor continues executing POST code from the EEPROM.

Checksum verification of the core logic NVRAM

The EPUC EEPROM contains the POST, OBP, system diagnostics code, and the spp_pdc code. In addition, these four routines use shared data structures. The routines and shared data structures all reside in sections of the EEPROM know as code spaces. Each code space has an embedded checksum word. POST checks the validity of each code space by reading and comparing its checksum.

Core logic initialization

The core logic contains SRAM and DUARTs that support external terminal connection for self test and the LCD panel. POST initializes the SRAM, DUARTs, and all controller CSRs in the system.

System configuration determination

POST determines which and how many controllers reside in the system (not every system contains a full complement of support hardware). It also determines the number of memory modules and their sizes. Any controller (ASIC) that does not respond to any CSR access is considered to be not installed.

System ASIC initialization

POST sets every system controller (ASIC) to a known state. The state is based both on configuration parameters and the current hardware configuration.

EPACs are reported in the EPUC EPAC-Exist register.

EMACs and EPICs are reported in the EPAC Configuration register.

ERACs are always all present (they are not sensed).

System main memory initialization

The processor reads the node ID from the COP EEPROM and uses its information to load the node identification register.

Next, the monarch processor determines the memory configuration for all EMACs. It determines the size, population, and installation of each DIMM on a memory board and returns this information to POST. The results are compared with the results of each other memory mapping and the least common denominator is determined and mapped in. Once the memory population is determined, the monarch processor assigns available processors to the enabled EMBs, initializing memory and tags in parallel.

System clean up and OBP boot process

POST resets the EPUC Processor Semaphore CSR and cleans up any residual state information from the initialization process. All processors now begin to execute the OBP routine at approximately the same time.

HP-UX bootup

Once each processor in the system has completed initialization and selftest, it loads and executes OBP. The following is the sequence of events for booting the system starting with loading OBP (for every processor) and finishing with the system ready for use:

The processor loads OBP—After initialization and selftest, each processor loads and begins executing OBP. OBP transfers its ROM image to RAM, initializes the virtual mode, and turns on translation.
OBP builds its device tree—It probes the system hardware.
The processor loads spp_pdc from flash RAM—This firmware is layered over OBP and provides interface between OBP and the HP-UX kernel. spp_pdc must be loaded before OBP can perform any boot functions.
OBP loads system boot loader—It opens the boot disk, loads a special system loading program, and closes boot disk.
The processor executes spp_pdc—This firmware layer must be executing so that OBP can complete booting the system.
The processor executes system boot loader—The loader starts in physical mode (32 bits) and performs the following tasks:
- Relocates itself
- Opens PCI devices through spp_pdc
  When spp_pdc calls OBP to perform PCI I/O transfers, OBP must turn on its virtual mode and then turn virtual mode off again when it returns control to spp_pdc. This means all buffers must already be equivalently mapped in OBP"s virtual mode page tables.
- Reads in the kernel using spp_pdc for I/O
- Starts the kernel
The kernel reads /etc/ioconfig—spp_pdc opens the boot device for I/O.
The kernel boot I/O completes.
spp_pdc closes the boot device.
OBP turns off Virtual Mode—It removes PCI CSR virtual mode mapping.
The kernel switches to its virtual mode
The kernel relocates the system boot loader
Kernel continues booting in one of two ways: normal boot and install boot.

Normal booting

For normal booting, the following additional tasks are performed:

OBP loads the special system kernel loader into memory.
The kernel loader loads /stand/vmunix or user-specified kernel.
The kernel uses kernel loader for boot I/O to load /etc/ioconfig. Booting is complete.

Install booting

For install booting, the following sequence is performed:

OBP loads the kernel loader into memory.
The kernel loader loads VINSTALL LIF image.
VINSTALL uses the kernel loader for boot I/O to load ramdisk VINSTALLFS
VINSTALL completes booting, and the cold install GUI opens for the user.