Section 4.9. Firmware Boot Sequence

4.9. Firmware Boot Sequence

Recall from our discussion in Section 4.1 that at power-on time, a typical computer performs low-level initialization followed by a self-test that sanity-checks the processor and closely connected hardware. In the case of a PowerPC-based Apple computer, Open Firmware is passed control next. As Open Firmware begins initializing itself, it performs the following sequence of operations.

• It determines the memory configuration of the machine. It then allocates and initializes memory for its internal data structures, memory pools, the device tree, and the Forth runtime environment.

• It initializes devices that are necessary for a basic Forth environment: the memory management unit, interrupt controllers, timers, and so on.

• It verifies its NVRAM. If the NVRAM's contents are invalid, it resets the NVRAM variables to their default values.

• If the use-nvramrc? NVRAM variable contains a TRue value, Open Firmware evaluates the nvramrc script (see Section 4.9.1).

• After handling nvramrc, Open Firmware probes for plug-in devices. It evaluates the FCodes residing on the ROMs of discovered devices. In this manner, the device tree incrementally grows as each device is found.

• Next, Open Firmware installs a console^[16] and prints a banner. You could also arrange for your own banner to be printed. For example, the following command causes your email address to be printed as the banner by Open Firmware:

  ^[16] The console may be a plug-in device, which is why Open Firmware installs a console after probing for devices.

  0 > setenv oem-banner [e-mail]  ok 0 > setenv oem-banner? true  ok

• It then performs some secondary diagnostics and any platform-dependent initialization.

• If the variable auto-boot? is false, Open Firmware drops into a prompt; otherwise it looks for a boot device, unless one was explicitly specified through boot arguments. The variable boot-device contains the default boot device. A typical device specification includes not just the containing device of the appropriate client programthe bootloaderbut also the client program's location on that device. Note that whether booting continues automatically also depends on the configured firmware security mode, as we will see in Section 4.12.

• Open Firmware is capable of reliably reading files from block devices. It invokes the boot device's load method to read the client program from that device into memory. This is done using a device-dependent protocol. For example, in the case of a local disk, Open Firmware reads the bootloader from disk. Alternatively, it can use TFTP for booting over the network, in which case it downloads three files: the bootloader, the kernel, and a kernel extensions cache.

• If Open Firmware fails to find a boot device, it displays a blinking folder.

• If all steps were completed successfully, Open Firmware eventually executes the bootloader.

Specifying Boot Devices

A boot device could be a locally attached hard disk or optical disc, a network interface, a ROM device, a serial line, and so on. A typical value of the boot-device variable is hd:,\\:tbxi, which specifies the boot device to be a file of type tbxi on the device referred to by the hd alias. This normally resolves to the Mac OS X bootloader. Note that the default definition of the hd alias may not contain a partition specifier, for example:

0 > devalias hd /pci@f4000000/ata-6@d/disk@0  ok 0 >

In such a case, Open Firmware will attempt to boot from the first bootable partition on the device. If you have multiple bootable partitions, boot-device can be set to be more specific. For example, hd:3,\\:tbxi refers to the third partition on the device specified by hd. Similarly, /ht/pci@7/k2-sata-root/k2-sata@0/disk@0:9,\\:tbxi refers to the ninth partition on an explicitly specified device path. A file can be referred to by its full pathname instead of file type, as in hd:3,\System\Library\CoreServices\MegaBootLoader.

Open Firmware can directly load ELF, XCOFF, and bootinfo files as client programs, although it cannot load Mach-O binaries. BootX, which can load Mach-O binaries, is presented to Open Firmware as a file with a bootinfo header and an XCOFF trailer.

4.9.1. The Script

The user may create a script, usually simply called the script, which is also stored in NVRAM. The script's contents are user-defined commands that can be executed during startup, depending on the value of the use-nvramrc? firmware variable. The script is initially empty. You can start editing the (intended) contents of the script by calling nvedit from Open Firmware. Doing so runs the script editor, which supports rudimentary text editing. Table 43 lists some useful key combinations available in nvedit.

Table 43. Key Combinations for nvedit Command-Line Editing

Keys	Purpose
^c	Exit the script editor and return to the Open Firmware prompt.
^k	Delete from the current position to the end of the line. If the cursor is at the end of the line, then join the current line with the next linethat is, kill the newline.
^l	Display the entire contents of the editing buffer.
^n	Go to the next line.
^o	Open another line at the current cursor position.
^p	Go to the previous line.

The text you edit using nvedit is stored in a temporary buffer. Once you exit the editor, you may discard the buffer's contents using nvquit or copy them to NVRAM using nvstore. You may also execute the contents using nvrun.

Warning

An erroneous script can render the system unbootable and may even cause permanent damage that would necessitate hardware repair. Use extreme caution while experimenting with this feature of Open Firmware.

4.9.2. Snag Keys

Open Firmware supports snag keys that you can press as the computer is started to redirect the boot sequence to various boot devices. Table 44 shows some examples of such keys.

Table 44. Boot-Time Snag Keys

Snag Keys	Description
c	Use the first bootable partition on the cd aliasnormally a CD-ROM drive.
d	Use the first bootable partition on the hd aliasnormally a disk drive.
n	Attempt to force boot over the network using BOOTP[a]/TFTP on the enet aliasnormally a network device.
t	Boot into target disk mode.
x	Boot a Mac OS X system (as opposed to Mac OS 9) if a bootable installation exists. This key is deprecated.
z	Use the first bootable partition on the zip aliasnormally a ZIP drive.
option	Interrupt Open Firmware's boot device selection and invoke the OS Picker application, which allows the user to choose an alternate boot device or system installation.
shift	Boot in safe mode.
	Boot into Open Firmware.
	Zap the parameter memory.
	Attempt to force boot from any device other than the one specified by the boot-device firmware variable.
	Boot in verbose mode.

^[a] Bootstrap Protocol.

Target Disk Mode

Pressing the t key as an Apple computer powers on will boot it into the FireWire target disk mode. Essentially, your machine becomes an external FireWire disk drive that can be connected to another computer through a FireWire cable. This mode is implemented by an Open Firmware package called firewire-disk-mode. You can also enter this mode from the Open Firmware prompt by using the target-mode word. Beginning with Mac OS X 10.4, the Startup Disk preference pane provides a button for restarting the computer in the target disk mode. Clicking this button is equivalent to setting the boot-command firmware variable (whose usual value is mac-boot) as follows. The first reboot after setting this variable will result in the computer entering the target disk mode, after which boot-command will be reset to mac-boot.

[View full width]
$ sudo nvram boot-command='" mac-boot" " boot-command" $setenv  target-mode'