setboot(1M)

SpeedyBoot

The SpeedyBoot firmware and software extensions allows a superuser to control which firmware tests are executed by the system during the boot process. The tests settings can be specified both for all subsequent boots and for the next one only. They are described in the The Tests section below.

The -v, -t, and -T options of the setboot command provide the user interface to the firmware tests. Currently -t options is not supported on Integrity system architecture.

SpeedyBoot augments the test control that is available on systems that have the Boot Console Handler (BCH). By turning off some or all of the boot tests, you can shorten boot time appreciably. However, in the event of a system panic or boot failure, all tests are executed on the subsequent boot.

SpeedyBoot Tests

The SpeedyBoot tests and the possible display values on a PA-RISC platform are summarized in the following table:

The SpeedyBoot tests and the possible display values on an Integrity platform are summarized in the following table:

Hyperthreading

Some Integrity processors support chip level multiprocessing which is a physical core presenting itself as two (or possibly more) logical CPUs (or hardware threads). Hyperthreading increases the instruction throughput by making use of the idle cycles and idle functional units that occur due to stalls.

Supported on some Integrity platform.

Failover

setboot will support boot path failover irrespective of whether a persistent device special file, lunpath hardware path, or legacy hardware path is given as input.

A persistent device special file is associated with a device based on its worldwide identifier, rather than its physical hardware path. When a persistent device special file is given as input, setboot writes an available lunpath hardware path to the LUN into stable storage.

Note: There is no order in which the available lunpath hardware paths get selected. Also, when the same persistent device special file is given as input for more than one boot path, setboot will avoid setting the same lunpath for the concerned boot paths.

When a lunpath hardware path is given as input, setboot writes that path into stable storage.

When a legacy hardware path is given as input, setboot writes the corresponding lunpath hardware path into stable storage. For more information on legacy hardware path and lunpath hardware path mapping, see ioscan(1M).

For more information on Hardware Paths and Device File Naming Conventions, including persistent device special file names, see intro(7).

If the hardware path written into stable storage goes offline, setboot retrieves an alternate available hardware path to the LUN and writes that path into stable storage. setboot supports failover by subscribing to the health of the hardware path that it writes to stable storage using EVM (see EVM(5)).

Options

The setboot command supports the following options:

General

SpeedyBoot

Autoboot and Autosearch on PA-RISC Systems

The interpretation of Autoboot and Autosearch has changed for PA-RISC systems that support hardware partitions. The firmware interprets the bits in combination and not individually as done before. In order to approximate the traditional behavior of setboot, the user input for the autoboot and autosearch flags is internally mapped to the right combination to achieve the desired behavior. This mapping should be transparent to the user of setboot, but might show up when accessing the firmware using means other than setboot.

For the primary path, the boot action corresponds to the Autoboot and Autosearch flags in the following manner:

Additionally, systems with hardware partitions support a boot action for each path. However the boot action for the paths other than the primary path cannot be set using setboot. Instead, these must be set through the Boot Console Handler using the pf (path flags) command of the BCH Configuration menu. The default boot action for the hardware partitions is to "skip this device and try next path". The case where both the autosearch and autoboot flags are on, will not work as expected until the path flags for the alternate paths are set appropriately through the BCH. In the default case, specifying setboot -b on -s on will not cause an alternate path to be automatically booted when the primary path fails, instead the user will be prompted.