| Previous | Contents | Index |
The following flags 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 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 following flags are passed (via register R5) to the OpenVMS VAX primary bootstrap image VMB.EXE. These flags control the particular behaviour of the bootstrap:
The exact syntax is console-specific, recent VAX consoles tend to use the following:
>>> BOOT/R5:flags
Bit Meaning
--- -------
0 RPB$V_CONV
Conversational boot. At various points in the
system boot procedure, the bootstrap code
solicits parameter and other input from the
console terminal. If the DIAG is also on then
the diagnostic supervisor should enter "MENU"
mode and prompt user for the devices to test.
1 RPB$V_DEBUG
Debug. If this flag is set, VMS maps the code
for the XDELTA debugger into the system page
tables of the running system.
2 RPB$V_INIBPT
Initial breakpoint. If RPB$V_DEBUG is set, VMS
executes a BPT instruction immediately after
enabling mapping.
3 RPB$V_BBLOCK
Secondary boot from the boot block. Secondary
bootstrap is a single 512-byte block, whose LBN
is specified in R4.
4 RPB$V_DIAG
Diagnostic boot. Secondary bootstrap is image
called [SYSMAINT]DIAGBOOT.EXE.
5 RPB$V_BOOBPT
Bootstrap breakpoint. Stops the primary and
secondary bootstraps with a breakpoint
instruction before testing memory.
6 RPB$V_HEADER
Image header. Takes the transfer address of the
secondary bootstrap image from that file's
image header. If RPB$V_HEADER is not set,
transfers control to the first byte of the
secondary boot file.
7 RPB$V_NOTEST
Memory test inhibit. Sets a bit in the PFN bit
map for each page of memory present. Does not
test the memory.
8 RPB$V_SOLICT
File name. VMB prompts for the name of a
secondary bootstrap file.
9 RPB$V_HALT
Halt before transfer. Executes a HALT
instruction before transferring control
to the secondary bootstrap.
10 RPB$V_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 RPB$V_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 DIAG is also on, then
the diagnostic supervisor enters "AUTOTEST" mode.
12 RPB$V_USEMPM
Specifies that multi-port memory should be used in
addition to local memory, as though both were one
single pool of pages.
13 RPB$V_MEMTEST
Specifies that a more extensive algorithm be used
when testing main memory for hardware
uncorrectable (RDS) errors.
14 RPB$V_FINDMEM
Requests use of MA780 memory if MS780 is
insufficient for booting. Used for 11/782
installations.
<31:28> RPB$V_TOPSYS
Specifies the top level directory number for
system disks with multiple systems.
|
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.27 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, please see Section 14.3.10.
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.
14.3.9 Why do my EFI Boot Aliases Fail?
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.
14.3.10 Downloading and using EFI Console Firmware?
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 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:
For information on Alpha SRM console firmware upgrades, please see
Section 14.3.7.
14.4 What platforms will OpenVMS operate on?
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.
| Previous | Next | Contents | Index |