Bootstrapping Unix into Memory.

When power is turned on the machine must go through some machine-dependent operation to load the Unix kernel into system memory. Usually this is done in one of the following ways:

Through a special console subsystem and some form of secondary storage such as a floppy drive.
Through a ROM-based program that is executed on power-up and which understands how to find and load the Unix kernel.
Over the network using a protocol such as BOOTP.

This is not an exhaustive list and there are other means in which a machine may be booted; however the three methods listed above are by far the most commonly used.

Console based Bootstrap operation.

Many older systems, such as the Vax 7xx and 8xxx series of processors had a dedicated console processor installed in the machine and some form of secondary storage (rk05 disk, floppy, or tape). The console processor was often a PDP-11 series processor. It was the resposibility of the console processor to load the bootstrap program into memory and start execution of the boot program. The boot program would then load the file containing the kernel image into memory. This bootstrap process requires that the initial bootstrap program know where to find the kernel file. In the case of the Vax, the device was specified via a boot-device register. By setting this register to different values you could load a copy of the kernel from different devices. The console processor generally supported a small number of commands for viewing and manipulating the boot file commands.

ROM-based Bootstrap operation.

Most newer systems, especially workstations, now use PROM's (Programmable Read-Only Memory) or ROM (Read-Only Memory) for booting. Upon power-up the system executes code located in the ROM and provides the system administrator a means to select the boot device and kernel file. On Silicon Graphics systems the PROM mode supports the following commands:

auto - autoboot the system
boot [-f file] [-n] [-args] - boot system
disable device - disables console device (gfx(0), tty(0), tty(1))
enable device - enables a console device (gfx(0), tty(0),tty(1))
printenv - prints environment variables
setenv - sets an environment variable
unsetenv - unsets an environment variable
go [pc] - transfers control to PC location
hinv - displays hardware configuration
version - displays PROM monitor version

On the SGI system you specify a file to boot via the syntax:

device([controller, [unit, [partition]]])file

device specifies the type of device ( SCSI, ESDI, IPI)
controller specifies the controller number.
unit specified the drive unit.
partition specifies the file partition to use.
file specifies the pathname for the file to load.

The SGI system allows you to specify many default values in non-volatile ram. These values are referred to as environment variables and control such things as the bootfile, bootmode, root device, console, initialization state, and swap. The SGI Prom monitor actually goes through a two stage boot process. First, when you issue the boot command a second boot program is executed named sash, which stands for (Stand-Alone SHell). Sash is passed the list of environment variables and understands how to access the Unix file system and load the kernel file into memory. This dual process is quite useful because the PROM monitor can then be used for loading files other than boot files. For example, a hardware diagnostic program can be loaded by the PROM monitor if there is a question regarding hardware.