>b [ device [ (c,u,p) ] ] [ filename ] boot-flags
>b [ device-specifier ] [ filename ] boot-flags
Desktop SPARCsystems, SPARCsystem 600MP series only.
The boot program is started by the PROM monitor and loads the kernel, or another executable program, into memory.
When booting standalone, the boot program (/boot) is brought in by the PROM from the file system. The PROM contains drivers for all devices. The boot program simply accesses the PROM device drivers via the ROMVEC interface.
When booting over the network, the system PROM obtains a version of the boot program from a server using the Trivial File Transfer Protocol (TFTP). The client broadcasts a RARP request containing its Ethernet address. A server responds with the client's Internet address. The client then sends a TFTP request for its boot program to that server (or if that fails, it broadcasts the request). The filename requested from a server must have a suffix that reflects the kernel architecture of the machine being booted. For these systems, the requested filename has the form:
where ip-address is the machine's Internet Protocol (IP) address in hex, and arch is a suffix representing its kernel architecture. These filenames are restricted to 14 characters for compatibility with UNIX System V and other operating systems. Therefore, the architecture suffix is limited to 5 characters; it must be in upper case. At present, the following suffixes are recognized: SUN3 for Sun-3 systems, SUN3X for Sun-3x systems, SUN4 for Sun-4 systems, SUN4C for Sun-4c systems, SUN4M for Sun-4m systems, S386 for Sun386i systems, and PCNFS for PC-NFS. arch.1 may be used to determine the kernel architecture of a machine.
When the Sun server receives the request, it looks in the directory /tftpboot for filename. That file is typically a symbolic link to the client's boot program, normally boot.arch in the same directory. The server invokes the TFTP server, tftpd.8c to transfer the file to the client.
When the file is successfully read in by the client, the boot program jumps to the load-point and loads vmunix (or a standalone program). In order to do this, the boot program makes a broadcast RARP request to find the client's IP address, and then makes a second broadcast request to a bootparamd.8 bootparams daemon, for information necessary to boot the client. The bootparams daemon obtains this information either from a local /etc/bootparams database file, or from a Network Information Service (NIS) map. The boot program sends two requests to the bootparams daemon -- the first, whoami, to obtain its hostname, and the second, getfile, to obtain the name of the client's server and the pathname of the client's root partition.
The boot program then performs a mount.8 operation to mount the client's root partition, after which it can read in and execute any program within that partition by pathname (including a symbolic link to another file within that same partition). Typically, it reads in the file /vmunix. If the program is not read in successfully, boot responds with a short diagnostic message.
Once the system is loaded and running, the kernel performs some internal housekeeping, configures its device drivers, and allocates its internal tables and buffers. The kernel then starts process number 1 to run init.8 which performs file system housekeeping, starts system daemons, initializes the system console, and begins multiuser operation. Some of these activities are omitted when init is invoked with certain boot-flags. These are typically entered as arguments to the boot command and passed along by the kernel to init.
The OBP command devalias displays all of the system built-in and user-defined device aliases. For example, the alias disk may represent the device-path
Open Boot PROM 2.0 Toolkit
Open Boot PROM Toolkit User's Guide
[a manual with the abbreviation INSTALL]
[a manual with the abbreviation ADMIN]
The Network Information Service (NIS) was formerly known as Sun Yellow Pages (YP). The functionality of the two remains the same; only the name has changed.
Created by unroff & hp-tools. © by Hans-Peter Bischof. All Rights Reserved (1997).
Last modified 21/April/97