| Previous | Contents | Index |
The OpenVMS I64 primary bootstrap flags are processed within the IA-64 primary bootstrap image IPB.EXE; within the SYS$EFI.SYS structures. The primary bootstrap boot flags are largely parallel to those of OpenVMS Alpha (see Section 14.3.5.2, though the console and the console mechanisms used to specify the boot command, the boot flags, and boot command options do differ markedly.
You can specify the boot flags via an EFI environment variable VMS_FLAGS , or via the boot alias boot options mechanism, or by appending the requested boot flags onto the specification of VMS_LOADER.EFI.
To set the bootstrap flags environment variable at the EFI shell prompt, use:
Shell> SET VMS_FLAGS "0,1" |
When you register an EFI boot alias (please see Section 14.4.5 for Intel Itanium terminology), you will be asked if you want to enter boot options, and what type. To add boot flags to a boot alias, select Unicode as the boot options type, and enter an SRM-like options string, such as the conversational bootstrap selected by the following example:
-flages 0,1 |
For related information on managing EFI boot aliases from OpenVMS I64, please see Section 14.3.10.
When using VMS_LOADER.EFI to request boot flags, you will want to specify the invocation as follows:
fsn:\efi\vms\vms_loader -flags 0,1 |
The above shows a conversational bootstrap request.
Typical boot flags are listed in Table 14-1.
| Bit | Example | Mnemonic | Description |
|---|---|---|---|
| 0 | 0,1 | CONV | Conversational bootstrap |
| 1 | 0,2 | DEBUG | Load SYSTEM_DEBUG.EXE (XDELTA) |
| 2 | 0,4 | INIBPT | Stop at initial system breakpoints |
| 16 | 0,10000 | DBG_INIT | Enable verbose bootstrap messages |
| 17 | 0,20000 | USER_MSGS | Enable additional bootstrap messages |
| 17 | 0,200000 | ? | Request for a bootstrap from USB keydisk |
For a conversational bootstrap of the OpenVMS I64 root SYS4 associated with the fs2: EFI file system device with full bootstrap messaging enabled, specify:
fs2:\efi\vms\vms_loader -flags 4,30001 |
The flags listed in Table 14-2 are passed (via register R5) to the OpenVMS Alpha primary bootstrap image APB.EXE. These flags control the particular behaviour of the bootstrap.
BOOT -FL root,flags |
| Bit | Mnemonic | Description |
|---|---|---|
| 0 | CONV | Conversational bootstrap |
| 1 | DEBUG | Load SYSTEM_DEBUG.EXE (XDELTA) |
| 2 | INIBPT | Stop at initial system breakpoints if bit 1 set (EXEC_INIT) |
| 3 | DIAG | Diagnostic bootstrap (loads diagboot.exe) |
| 4 | BOOBPT | Stop at bootstrap breakpoints (APB and Sysboot) |
| 5 | NOHEADER | Secondary bootstrap does not have an image header |
| 6 | NOTEST | Inhibit memory test |
| 7 | SOLICIT | Prompt for secondary bootstrap file |
| 8 | HALT | Halt before transfer to secondary bootstrap |
| 9 | SHADOW | Boot from shadow set |
| 10 | ISL | LAD/LAST bootstrap |
| 11 | PALCHECK | Disable PAL rev check halt |
| 12 | DEBUG_BOOT | Transfer to intermediate primary bootstrap |
| 13 | CRDFAIL | Mark CRD pages bad |
| 14 | ALIGN_FAULTS | Report unaligned data traps in bootstrap |
| 15 | REM_DEBUG | Allow remote high-level language debugger |
| 16 | DBG_INIT | Enable verbose boot messages in EXEC_INIT |
| 17 | USER_MSGS | Enable subset of verbose boot messages (user messages) |
| 18 | RSM | Boot is controlled by RSM |
| 19 | FOREIGN | Boot involves a foreign disk |
If you want to set the boot flags "permanently", use the SET BOOT_FLAGS command, e.g.:
>>> SET BOOT_OSFLAGS 0,1 |
The flags described in Table 14-3 are passed (via register R5) to the OpenVMS VAX primary bootstrap image VMB.EXE. These flags control the particular behaviour of the bootstrap.
| Bit | Mnemonic | Description |
|---|---|---|
| 0 | CONV | Conversational boot. At various points in the system boot procedure, the bootstrap code solicits parameter and other input from the console terminal. If DIAG is set, then the diagnostic supervisor should enter its menu mode and prompt user for the devices to test. |
| 1 | DEBUG | Debug. If this flag is set, OpenVMS VAX maps the code for the XDELTA debugger into the system page tables of the running system. |
| 2 | INIBPT | Initial breakpoint. If RPB$V_DEBUG is set, OpenVMS VAX executes a BPT instruction immediately after enabling mapping. |
| 3 | BBLOCK | Secondary boot from the boot block. Secondary bootstrap is a single 512-byte block, whose LBN is specified in R4. |
| 4 | DIAG | Diagnostic boot. Secondary bootstrap is the Diagnostic Supervisor image; the image [SYSMAINT]DIAGBOOT.EXE. |
| 5 | BOOBPT | Bootstrap breakpoint. Stops the primary and secondary bootstraps with an XDELTA breakpoint instruction prior to the memory test. |
| 6 | HEADER | Image header. Takes the transfer address of the secondary bootstrap image from that file's image header. If the RPB$V_HEADER bit is not set, the image is assumed to have no image header, and control is transfered to the first byte of the secondary boot file. |
| 7 | NOTEST | Memory test inhibit. Sets a bit in the PFN bit map for each page of memory present. Does not test the memory. |
| 8 | SOLICT | File name. VMB prompts for the name of a secondary bootstrap file. |
| 9 | HALT | Halt before transfer. Executes a HALT instruction before transferring control to the secondary bootstrap. |
| 10 | NOPFND | No PFN deletion (not implemented; intended to tell VMB not to read a file from the boot device that identifies bad or reserved memory pages, so that VMB does not mark these pages as valid in the PFN bitmap). |
| 11 | MPM | Specifies that multi-port memory is to be used for the total EXEC memory requirement. No local memory is to be used. This is for tightly-coupled multi-processing. If the RPB$V_DIAG bit is also enabled, then the Diagnostic Supervisor enters its AUTOTEST mode. |
| 12 | USEMPM | Specifies that multi-port memory should be used in addition to local memory, as though both were one single pool of pages. |
| 13 | MEMTEST | Specifies that a more extensive algorithm be used when testing main memory for hardware uncorrectable (RDS) errors. |
| 14 | FINDMEM | Requests the use of MA780 multiport memory if the main MS780 memory is insufficient for booting. This is a remnant of the support for the VAX-11/782 series system and its Asymmetric Multiprocessing (ASMP) environment. Support for the VAX-11/782 and for ASMP was withdrawn with the V5.0 release; with the advent of Symmetric Multiprocessing (SMP) support. |
The exact syntax is console-specific, recent VAX consoles tend to use the following:
>>> BOOT/R5:flags |
The AlphaStation series will boot without a keyboard attached. To use a serial terminal as the console, issue the SRM console command SET CONSOLE SERIAL followed by the console INIT command. Once this SRM command sequence has been invoked and the CONSOLE environment variable is set to SERIAL, the Alpha system will use the serial terminal. (Set the environment variable to GRAPHICS to select the console display output via the graphics display.)
The DEC 3000 series has a jumper on the motherboard for this purpose. Various older Alpha workstations generally will not (automatically) bootstrap without a keyboard connected, due to the self-test failure that arises when the (missing) keyboard test fails.
The usual settings for the console serial terminal (or PC terminal emulator acting as a serial console are:
9600 baud, 8 bits, no parity, one stop bit (9600 baud, 8N1). |
AlphaServer 4100 and derivative series platforms, and AlphaServer GS80, GS160, and GS320 series system consoles are capable of 57600 baud. See the COM2_BAUD console environment variable, and ensure that you have current SRM firmware version loaded.
The AlphaStation and AlphaServer series use a PC-compatible DB9 serial connector for the COM1 and COM2 serial lines (and for the OPA0: console line, if that was configured via SRM), please see Section 14.26 for details and pin-out.
For information on registering software license product authorization keys (PAKs), please see Section 5.6.2.
For a related behaviour of DECwindows, please see Section 11.10. For
information on the VAXstation alternate console mechanisms, please see
Section 14.3.3.3.
14.3.7 Downloading and using SRM console Firmware?
This section discusses downloading and using Alpha console firmware,
sometimes called PALcode.
14.3.7.1 Where can I get updated console firmware for Alpha systems?
Firmware updates for HP Alpha systems are available from:
The latest and greatest firmware---if updated firmware has been released after the most recent firmware CD was distributed---is located at:
For information on creating Alpha bootable floppies containing the firmware, and for related tools, please see the following areas:
The SROM firmware loader expects an ODS-2 formatted floppy, see mkboot. As for which image to use, the ROM image uses a header and the file extension .ROM, and the SROM bootable floppy cannot use the .ROM file.
To check the firmware loaded on recent OpenVMS Alpha systems, use the command:
$ write sys$output f$getsyi("console_version")
$ write sys$output f$getsyi("palcode_version")
SDA> CLUE CONFIG
|
Also see Section 14.3.7.2. For information on HP Integrity EFI firmware
upgrades and for a sequence useful in generating CD-R or CD-RW media
containing a firmware disk image, please see Section 14.3.11.
14.3.7.2 How do I reload SRM firmware on a half-flash Alpha system?
Some of the AlphaStation series systems are "half-flash" boxes, meaning only one set of firmware (SRM or AlphaBIOS) can be loaded in flash at a time. Getting back to the SRM firmware when AlphaBIOS (or ARC) is loaded can be a little interesting...
That said, this usually involves shuffling some files, and then getting into the AlphaBIOS firmware update sequence, and then entering "update srm" at the apu-> prompt.
To shuffle the files, copy the target SRM firmware file (as200_v7_0.exe is current) to a blank, initialized, FAT-format floppy under the filename A:\FWUPDATE.EXE
From the AlphaBIOS Setup screen, select the Upgrade AlphaBIOS option. Once the firmware update utility gets going, enter:
Apu-> update srm
Answer "y" to the "Are you ready...?"
Apu-> quit
|
You've reloaded the flash. Now power-cycle the box to finish the process.
Also see Section 14.3.7.1.
14.3.7.3 How do I switch between AlphaBIOS/ARC and SRM consoles?
The specific steps required vary by system. You must first ensure that the particular Alpha system is supported by OpenVMS (see the SPD), that all core I/O components (graphics, disk controllers, etc) in the system are supported by OpenVMS (see the SPD), and that you have an OpenVMS distribution, that you have the necessary license keys (PAKs), and that you have the necessary SRM firmware loaded.
A typical sequence used for switching over from the AlphaBIOS graphics console to the SRM console follows:
Most Alpha systems support loading both the AlphaBIOS/ARC console and the SRM console at the same time, but systems such as the AlphaStation 255 are "half-flash" systems and do not support the presence of both the AlphaBIOS/ARC and SRM console firmware at the same time. If you have a "half-flash" system, you must load the SRM firmware from floppy, from a network download, or from a firmware CD-ROM. Following the normal AlphaBIOS or ARC firmware update sequence to the APU prompt, and then explictly select the target console. In other words, power up the system to the AlphaBIOS or ARC console, use the supplementary options to select the installation of new firmware (typically from CD-ROM), and then rather than using a sequence which updates the current firmware:
Apu-> update
-or-
Apu-> update ARC
Apu-> verify
Apu-> quit
Power-cycle the system
|
Use the following sequence to specifically update (and load) SRM from AlphaBIOS/ARC on a "half-flash" system:
Apu-> update SRM
Apu-> verify
Apu-> quit
Power-cycle the system
|
Use the following sequence to specifically update (and load) the AlphaBIOS/ARC console from SRM on a "half-flash" system:
>>> b -fl 0,A0 ddcu
BOOTFILE: firmware_boot_file.exe
Apu-> update ARC
Apu-> verify
Apu-> quit
Power-cycle the system
|
Once you have the SRM loaded, you can directly install OpenVMS or Tru64 UNIX on the system. Do not allow Microsoft Windows NT or other operating system(s) to write a "harmless" signature to any disk used by OpenVMS Alpha or OpenVMS VAX, as this will clobber a key part of the disk; this will overwrite the OpenVMS bootblock. (On OpenVMS Alpha and OpenVMS VAX, you can generally recover from this so-called "harmless" action by using the WRITEBOOT.EXE tool.
Using OpenVMS I64 and the EFI console, the bootblock structures are expected to be compatible with those of Microsoft Windows and other Integrity operating systems; please see the discussion of the SET BOOTBLOCK command and the SYS$SETBOOT.EXE image in Section 9.7.3, in Section 14.3.9, and in the OpenVMS documentation for related details.)
If you have a "full-flash" system and want to select the SRM console from the AlphaBIOS or ARC console environment, select the "Switch to OpenVMS or Tru64 UNIX console" item from the "set up the system" submenu. Then power-cycle the system. If you have a "full-flash" system with the SRM console and want to select AlphaBIOS/ARC, use the command:
>>> set os_type NT |
and power-cycle the system.
For information on acquiring firmware, see Section 14.3.7.1. For information on OpenVMS license PAKs (for hobbyist use) see Section 2.8.1. For information on the Multia, see Section 14.4.1.
Information on enabling and using the failsafe firmware loader for various systems---this tool is available only on some of the various Alpha platforms---is available in the hardware documentation for the system. This tool is used/needed when the firmware has been corrupted, and cannot load new firmware.
The full list of AlphaBIOS key sequences---these sequences are needed when using an LK-series keyboard with AlphaBIOS, as AlphaBIOS expects a PC-style keyboard:
F1 Ctrl/A
F2 Ctrl/B
F3 Ctrl/C
F4 Ctrl/D
F5 Ctrl/E
F6 Ctrl/F
F7 Ctrl/P
F8 Ctrl/R
F9 Ctrl/T
F10 Ctrl/U
Insert Ctrl/V
Delete Ctrl/W
Backspace Ctrl/H
Escape Ctrl/[
Return Ctrl/M
LineFeed Ctrl/J
(Plus) + upselect (some systems)
(Minus) - downselect (some systems)
TAB down arrow
SHIFT+TAB up arrow
|
Options to collect multiple consoles into a single server are available, with both hardware options and software packages that can provide advanced features and capabilities.
Some of the available console management options for OpenVMS:
Computer Associates is the owner of what was once known as the VAXcluster Console System (VCS) console management package, and has integrated this capability into the CA management product suite.
| Previous | Next | Contents | Index |