HP OpenVMS Systems Documentation
The OpenVMS Frequently Asked Questions (FAQ)
188.8.131.52 What are the VAX VMB boot flag values?
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.
14.3.6 How do I boot an AlphaStation without monitor or keyboard?
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:
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
This section discusses downloading and using Alpha console firmware,
sometimes called PALcode.
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:
Also see Section 184.108.40.206. 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.
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:
You've reloaded the flash. Now power-cycle the box to finish the process.
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:
Use the following sequence to specifically update (and load) SRM from AlphaBIOS/ARC on a "half-flash" system:
Use the following sequence to specifically update (and load) the AlphaBIOS/ARC console from SRM on a "half-flash" 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:
and power-cycle the system.
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:
14.3.8 Console Management Options
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.
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.
OpenVMS I64 boot aliases contain signature information referencing the specific volume, meaning that the entries are specific to the disk volume and not the disk device. This also means that certain operations, such as the SET BOOTBLOCK command or the RUN SYS$SETBOOT.EXE operation that can rewrite these volume signatures (signature or GUID values) can render existing boot aliases unusable.
If your boot aliases do not function as expected, first try removing
and re-adding them; this will resynchronize the boot aliases with the
volume contents. If you are using the SET BOOTBLOCK command or the
RUN SYS$SETBOOT.EXE operation to rewrite the disk bootblock, you can
request that the current signatures (if any) be preserved, and this
will typically maintain the validity of your EFI console boot aliases.
For access to the EFI console environment from OpenVMS I64, see the BOOT_OPTIONS.COM command procedure, and the EFI SET, SHOW and BCFG mechanisms. Details on these are in the System Manager's and particularly in the System Manager's Utilities manual.
For related information on boot aliases, please see Section 220.127.116.11.
HP Integrity EFI system firmware can be downloaded in the form of a bootable image master, unzipped and then burned onto CD or DVD media (please see Section 9.7 for details of recording optical media directly on OpenVMS), and the system can then generally be booted off the created media to perform the EFI firmware upgrade.
The HP Integrity Server website is accesssable via the following URL, and the available services and support information there has links to the available platform-specific firmware images and upgrade-related materials:
To use the following sequence, you will need a writable or rewritable CD drive and software, and a blank CD-R or CD-RW disk. If you use CD writer software for another platform, you will want to use the block, binary, ISO or raw mode operations appropriate for the particular chosen recording package. The following directions assume use of OpenVMS and native CD-R capabilities, please see Section 9.7 for associated details.
For the list of boxes that are officially and formally supported by OpenVMS Engineering, please see the OpenVMS Software Product Description (SPD).
Sometimes a particular and officially unsupported Alpha box or Alpha motherboard will sufficiently resemble a supported box that the platform can effectively mimic and can bootstrap OpenVMS. Alternatively, somebody (usually one or more engineers within the OpenVMS Engineering group) will have put together a bootstrap kit -- such as the kit for the Alpha Multia---which permits OpenVMS to bootstrap on the platform.
Contrary to the assumptions of some folks, there are platform-level differences even within the VAX and within the Alpha platforms--- hardware-level differences that can require moderate to extensive new coding within OpenVMS. Within a platform series, and particularly within Alpha platforms (and those few VAX systems) that support Dynamic System Recognition (DSR), OpenVMS can usually bootstrap.
DSR is a mechanism by which OpenVMS can gather platform-specific information, and DSR is the reason why newer Alpha systems can be more easily and more commonly supported on older OpenVMS Alpha releases. DSR is implemented with OpenVMS Alpha code, with SRM console code, and with platform non-volatile memory.
OpenVMS users with experience on older OpenVMS VAX releases and VAX hardware will recall that then-new VAX systems either required an OpenVMS VAX upgrade, or that earlier releases would mis-identified then-newer VAX systems---such as the case of the VAX 7000 model 800 being (mis)identified as a VAX 7000 model 600 when bootstrapped on OpenVMS VAX V5.5-2. (This (mis)identification was the outcome of a deliberate engineering effort to permit the VAX 7000 model 800 to bootstrap on V5.5-2; the system manager could configure the VAX 7000 model 800 to (mis)identify itself as a model 600, to permit the system to bootstrap on V5.5-2.) OpenVMS VAX and VAX platforms lack DSR support.
OpenVMS I64 (please see Section 14.4.5 for Intel Itanium terminology) supports a platform-level feature similar to the OpenVMS Alpha DSR mechanism, based on the ACPI interface and the byte-code interpreter implemented within OpenVMS, within the EFI console, and particularly within non-volatile memory located on (byte-code interpreter compliant) PCI I/O hardware. ACPI tables provide the information that was formerly retrieved from DSR and from the SRM, and the byte-code interpreter can (theoretically) permit at least limited operations with (compliant) PCI hardware, whether or not OpenVMS has a driver for the particular hardware.
The byte code interpreter may or may not permit operations with any particular PCI hardware, and may or may not have sufficient performance for local requirements, and PCI hardware may or may not include the necessary ROM-based drivers in the PCI hardware non-volatile storage. (The intent of this Intel platform-level effort is to move the host software drivers out onto the specific PCI hardware, and to permit the same byte code to operate regardless of the particular host platform.) At least the initial releases of OpenVMS I64 will not have support for the byte code interpreter nor for arbitrary PCI or system hardware, but will have support for ACPI-based system identification and system configuration.