This section describes the basic boot process on the SPARC and x86 platforms. For more information about boot processes on specific hardware types, including systems that have service processors and system that have multiple physical domains, see the product documentation for your specific hardware at http://www.oracle.com/technetwork/indexes/documentation/index.html.
The process of loading and executing a stand-alone program is called bootstrapping. Typically, the stand-alone program is the operating system kernel. However, any stand-alone program can be booted instead of the kernel.
On SPARC platforms, the bootstrapping process consists of the following basic phases:
After you turn on a system, the system firmware (PROM) executes a power-on self-test (POST).
After the test has been successfully completed, the firmware attempts to autoboot, if the appropriate flag has been set in the non-volatile storage area that is used by the machine's firmware.
The second-level program is either a file system-specific boot block, when you booting from a disk, or inetboot or wanboot, when you are booting across the network or using the Automated Installer (AI).
On x86 based systems, the bootstrapping process consists of two conceptually distinct phases, kernel loading and kernel initialization. Kernel loading is implemented by GRUB by using the firmware on the system board and firmware extensions in ROMs on peripheral boards. The system firmware loads GRUB. The loading mechanism differs, depending on the type of system firmware that is shipped on the system board.
After a PC-compatible system is turned on, the system's firmware executes a power-on self (POST), locates and installs firmware extensions from peripheral board ROMS, and then begins the boot process through a firmware-specific mechanism.
For systems with BIOS firmware, the first physical sector of a hard disk (known as the boot sector) is loaded into memory and its code is executed. Disks that are partitioned with the GUID Partition Table (GPT) must have boot sector code that behaves differently, loading code from another location, because the GPT scheme does not reserve the first sector of each partition for boot sector code storage. In the case where GRUB is running on BIOS firmware, that other location is a dedicated partition, which is known as the BIOS Boot Partition. After the GRUB boot sector code loads the rest of GRUB into memory, the boot process continues.
The boot program then loads the next stage, which in the case of Oracle Solaris, is GRUB itself. Booting from the network involves a different process on systems with BIOS firmware. See Chapter 5, Booting a System From the Network (Tasks).
For systems with UEFI-based firmware, the boot process differs significantly. The UEFI firmware searches for the EFI System Partition (ESP) on disks that it has enumerated and then loads and executes UEFI boot programs according to a UEFI-specification-defined process, which results in a UEFI boot application being loaded into memory and executed. On Oracle Solaris, that UEFI boot application is GRUB. The version of GRUB in this release is built to run as a UEFI boot application. The boot process then continues as it does on systems with BIOS firmware.
For more information about boot processes on specific hardware types, including systems that have service processors and systems that have multiple physical domains, see the product documentation for your specific hardware at http://www.oracle.com/technetwork/indexes/documentation/index.html.