|
See reader questions & answers on this topic! - Help others by sharing your knowledge
Archive-name: dec-faq/vms/part9
Posting-Frequency: quarterly
Last-modified: 02 Sep 2005
Version: VMSFAQ_20050902-09.TXT
Hardware Information
________________________________________________________________
Table 14-2 Alpha Conversational Bootstrap 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
14-11
Hardware Information
________________________________________________________________
Table 14-2 (Cont.) Alpha Conversational Bootstrap Flags
_______________________________________________________
Bit_____Mnemonic__________Description__________________
_________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
_____________________________
14.3.5.3 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.
________________________________________________________________
Table 14-3 VAX Conversational Bootstrap Flags
_______________________________________________________
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.
14-12
Hardware Information
________________________________________________________________
Table 14-3 (Cont.) VAX Conversational Bootstrap Flags
_______________________________________________________
Bit_____Mnemonic__________Description__________________
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.
14-13
Hardware Information
________________________________________________________________
Table 14-3 (Cont.) VAX Conversational Bootstrap Flags
_______________________________________________________
Bit_____Mnemonic__________Description__________________
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-14
Hardware Information
________________________________________________________________
Table 14-3 (Cont.) VAX Conversational Bootstrap Flags
_______________________________________________________
Bit_____Mnemonic__________Description__________________
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
_____________________________
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.
14-15
Hardware Information
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:
o ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html
o ftp://ftp.digital.com/pub/Digital/Alpha/firmware/
o ftp://ftp.digital.com/pub/Digital/Alpha/firmware/readme.html
14-16
Hardware Information
The latest and greatest firmware-if updated firmware
has been released after the most recent firmware CD was
distributed-is located at:
widftp://ftp.digital.com/pub/Digital/Alpha/firmware/interim/
For information on creating Alpha bootable floppies
containing the firmware, and for related tools, please
see the following areas:
widftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkboot.txt
widftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkbootarc.txt
widftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkntboot.txt
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.
14-17
Hardware Information
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:
1 Press <F2> to get to the AlphaBIOS setup menu.
2 Pick the "CMOS Setup..." item.
3 Press <F6> to get to the "Advanced CMOS Setup" menu.
4 Change the "Console Selection" to "OpenVMS Console
(SRM)".
5 Press <F10>, <F10>, then <Enter> to save your
changes.
6 Power-cycle the system.
14-18
Hardware Information
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
14-19
Hardware Information
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:
14-20
Hardware Information
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
_____________________________
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.
Some of the available console management options for
OpenVMS:
o Heroix: http://www.robomon.com/
o KI Products: http://www.ki.com/products/clim/
o Global Maintech: http://www.globalmt.com/
o TECsys: http://www.tditx.com/
o CA: http://www.cai.com/products/commandit.htm
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-21
Hardware Information
_____________________________
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 Can OpenVMS access the 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 14.3.5.1.
_____________________________
14.3.11 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 directly on
OpenVMS), and the system can then generally be booted
off the created media to perform the EFI firmware
upgrade.
14-22
Hardware Information
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:
o http://www.hp.com/go/integrity/
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.
1 First, you must acquire the Integrity server
firmware from the above URL. Select the platform,
and navigate to the supporting information and
specifically to the Download Drivers and Software
link
2 Select Cross operating system (BIOS, Firmware, etc.)
3 Locate the appropriate ISO-format firmware file.
There are several firmware file formats available
and there are also various off-line diagnostic
images, choose the ISO-format firmware file.
4 Read the directions for the firmware file, then
download the ISO-format firmware (zip-compressed)
file. A binary-mode FTP transfer should be used.
5 Unzip the file into the corresponding .ISO data
file. Somewhat confusingly, the .ISO extension can
indicate either a block-oriented raw image of a
disk, or a disk with the ISO-9660 volume structure.
In this case, the former is intended and this
file contains a a block copy or disk image of the
firmware disk for the platform, and may or may not
be an ISO-9660 volume structure. The unzip tool is
available on the OpenVMS Freeware and elsewhere;
please see Section 13.11 for details and locations.
14-23
Hardware Information
6 Use CDRECORD or other available recording tool
(please see Section 9.7 for related details) to
burn a CD-R or CD-RW disk, specifying the ISO file
as the source for the burn operation.
7 Shut the Integrity Server system down to the EFI
console level.
8 Unload the recorded CD media from the CD-R drive,
label it, and load it into the Integrity console
drive. This assuming the disk was not generated
directly on an Integrity CD-R/RW-capable drive, of
course.
9 Using the EFI shell, display the current firmware
version using the command
info fw
10 Exit the EFI shell and select the boot options
maintenance menu; create a boot alias for the
removable media drive for the CD; for the newly-
created firmware disk.
11 Boot it. Follow the directions displayed by the
firmware loader and related documentation, heeding
the release notes that were reviewed earlier.
12 Perform a cold restart of the Integrity server.
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).
o http://h18000.www1.hp.com/info/spd/
OpenVMS typically uses SPD 25.01.xx, SPD 41.87.xx,
and SPD 82.35.xx.
14-24
Hardware Information
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
14-25
Hardware Information
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.
_____________________________
14.4.1 on the Alpha Multia?
Yes, there are a set of unsupported images that permit
specific OpenVMS Alpha versions to bootstrap on the
Multia UDB system. These images and the associated
instructions are available at the OpenVMS Freeware
website:
o http://www.hp.com/go/openvms/freeware/
Look in the Freeware V5.0 /multia/ directory.
Instructions are included IN the kits. READ THE
INSTRUCTIONS. PLEASE!
Some of the restrictions involved when running OpenVMS
on the Multia system include (but may well not be
limited to) the following:
o The PCMCIA support was completely removed, because
the Intel chip on the Multia was not compatable with
the Cirrus chip on the Alphabook.
14-26
Hardware Information
This means, of course, that you will not see and
cannot use any PCMCIA cards on a Multia.
The Multia uses shared interrupts, and as a result,
a special ZLXp-E series graphics device driver-one
that does not use interrupts-is needed. This driver
is provided in the kit.
o The serial lines don't work.
o If you have a Multia with a PCI slot, you can't use
any PCI card that requires interrupts.
o The SRM console on this system is very old and
very fragile. (This SRM console was designed
only and strictly for diagnostic use, and was not
particularly tested or used with OpenVMS.)
o If things don't work for you, don't expect to see
any OpenVMS updates, nor SRM console updates, nor
any support.
o Do not expect to see any new versions of OpenVMS
on the Multia nor on any other unsupported systems.
If such new versions do appear and do work, please
consider it as a pleasant surprise.
The Multia images are not included on the OpenVMS
Freeware V4.0 CD-ROM kit, the kit that was distributed
with OpenVMS V7.2. (These images became available after
Freeware V4.0 shipped.)
Other sources of information for OpenVMS on Multia
include:
o http://www.djesys.com/vms/hobbyist/multia.html
o http://www.djesys.com/vms/hobbyist/mltianot.html
o http://www.djesys.com/vms/hobbyist/support.html
o http://www.netbsd.org/Ports/alpha/multiafaq.html
o http://www.brouhaha.com/~eric/computers/udb.html
14-27
Hardware Information
_____________________________
14.4.2 on AlphaPC 164LX? AlphaPC 164SX?
OpenVMS Alpha is not supported on the AlphaPC 164LX and
164SX series, though there are folks that have gotten
certain of the LX series to load SRM and bootstrap
OpenVMS. (The Aspen Durango II variant, specifically.)
One problem has been generally reported: ATA (IDE)
bootstraps will fail; SCSI storage and a SCSI CD-ROM
device is required.
Also see Section 14.4.2.1.
_____________________________
14.4.2.1 on the NoName AXPpci33 system?
Information on bootstrapping OpenVMS (using the Multia
files described in Section 14.4.1) on the (unsupported)
NoName AXPpci33 module is available at:
o http://www.jyu.fi/~kujala/vms-in-axppci33.txt
Tips for using the Multia files with the AXPpci33:
o You have to use the Multia kit and follow the
directions in ALPHA8, but do *not* load the Multia
SRM firmware into the AXPpci33. Rather, download and
use the latest firmware for the AXPpci33 from the HP
Alpha firmware website instead.
o 64 MB memory is generally necessary.
o you cannot use any PCI cards, and if you plan on
networking, you need to find an ISA Ethernet card
supported by OpenVMS.
o When the AXPpci33 board bootstraps, it will dump
some stuff like a crash dump, but it will continue
and-so far-this hasn't caused any particular
hassles.
o The system shutdown and reboot procedures do not
work properly.
o The serial console is reported to not work, though
the serial ports apparently do work. The status of
the parallel port is unknown.
14-28
Hardware Information
o Rumour has it that you have one of the AXPpci33
motherboards with the PS/2 mouse and keyboard
connectors and a VGA card (one that will work
under DECwindows) and you can run DECwindows on
the system.
_____________________________
14.4.3 on the Alpha XL series?
No.
OpenVMS Engineering does not formally support the Alpha
XL series, nor will OpenVMS (informally) bootstrap on
the Alpha XL series.
OpenVMS can not, will not, and does not bootstrap on
the Alpha XL series. The Alpha XL series was targeted
for use (only) with the Microsoft Windows NT operating
system.
The Alpha XL platform does not resemble other supported
platforms.
_____________________________
14.4.4 OpenVMS on the Personal Workstation -a and -au series?
Though OpenVMS is not supported on the Personal
Workstation -a series platforms, OpenVMS might or might
not bootstrap on the platform.
If you wish to attempt this, you must ensure that all
graphics and all I/O controllers in the system are
supported by OpenVMS. You must also ensure that you
have the most current firmware loaded.
Here are some salient differences within the various
Personal Workstation series:
o The -a series was designed and was tested for
Windows NT use. Only. It is not supported for use
with OpenVMS.
o The -au series was designed and tested for Windows,
OpenVMS, and Tru64 UNIX compatibility, and is
considered a supported system.
14-29
Hardware Information
o There are at two different and distinct variants of
the family, and usually refered to by their internal
hardware project names.
o The Miata MX5. The Miata MX5 variant has no USB
ports and no on-board SCSI. The on-board Intel
SIO chipset is not supported by OpenVMS, and thus
OpenVMS cannot bootstrap ATAPI CD-ROM devices.
That said, the Miata MX5 -a series typically came
with DEC branded Adaptec 2940UW SCSI controllers,
Matrox Millennium graphics cards, no L3 cache
module, and an Toshiba IDE CD-Rom. Some came with
very high end Powerstorm graphics card if the
system was destined to do CAD or movie rendering.
Graphics and other I/O can and does vary by
package.
The Miata MX5 is not supported by OpenVMS.
o The Miata GL. The Miata GL variant has USB ports
and on-board SCSI and bootstraps using the on-
board Cypress IDE chipset and an ATAPI CD-ROM
are supported by OpenVMS. The Miata GL -a variant
is need not be configured with an add-on SCSI
controller, given both the ability to bootstrap
from ATAPI CD-ROM and the on-board SCSI.
Graphics and other I/O can and does vary by
package.
Various of the Miata GL systems are supported by
OpenVMS.
For obvious reasons, most folks will prefer and will
select a Miata GL system, given the choice between the
Miata MX5 and the Miata GL series. And as for your next
question, you cannot necessarily nor easily distinguish
the Miata MX5 from the Miata GL based solely on the
model number.
See Section 14.4.4.2 for related details.
14-30
Hardware Information
_____________________________
14.4.4.1 OpenVMS on the Whitebox Windows-Only series Alpha?
Though OpenVMS is not supported on the "Whitebox"
series of Alpha platforms, OpenVMS might or might
not bootstrap on the platform. These systems were
specifically configured, targeted and supported only
for use with the Microsoft Windows NT operating system.
On some of the "Whitebox" systems, the following
sequence of console commands can potentially be used
to convert the system over to unsupported use by and
for OpenVMS Hobbyist users. (But please note that if
you wish to attempt this, you must ensure that all
graphics and all I/O controllers in the system are
supported by OpenVMS, and you must ensure that you have
the most current SRM firmware loaded. (For information
on locating and downloading the most current Alpha SRM
firmware, please see Section 14.3.7.1.) And you must
realize that the resulting Whitebox configuration will
be entirely unsupported and may or may not be stable
and useful.)
set os_type vms
cat nvram ! too see what is in this, if anything
edit nvram
10 set srm_boot on
20 e
init
If your nvram has other contents, you will need to
change the line numbers (10 and 20) to reflect the
contents of your configuration. To obtain documentation
on the commands of the console editor, enter the ?
command within the editor.
The above sequence was reportedly tested on the DIGITAL
Server 3300 series, a relative of the AlphaServer
800 series. The DIGITAL Server 3300 is not supported
by OpenVMS, though the AlphaServer 800 series is a
supported platform. The sequence may or may not work on
other platforms, and may or may not work on the DIGITAL
Server 3300 platform.
Also see Section 5.33.
14-31
Hardware Information
_____________________________
14.4.4.2 OpenVMS and Personal Workstation ATA (IDE) bootstrap?
OpenVMS will boot and is supported on specific Personal
Workstation -au series platforms, though OpenVMS will
require a SCSI CD-ROM if the Intel Saturn I/O (SIO) IDE
chip is present in the configuration- only the Cypress
IDE controller chip is supported by OpenVMS for IDE
bootstraps. (Configurations with the Intel SIO are not
generally considered to be supported systems.)
If you have an -au series system, you can determine
which IDE chip you have using the SRM console command:
SHOW CONFIGURATION
If you see "Cypress PCI Peripheral Controller", you can
bootstrap OpenVMS from IDE storage. If you see "Intel
SIO 82378", you will need to use and bootstrap from
SCSI. (A procedure to load DQDRIVER on the Intel SIO-
once the system has bootstrapped from a SCSI device-is
expected to be included as part of the contents of the
DQDRIVER directory on Freeware V5.0 and later.)
Many of the -a series systems will include the Intel
SIO, and thus cannot bootstrap from IDE.
See Section 14.4.4 for related details.
_____________________________
14.4.5 On the Intel Itanium IA-64 platform?
OpenVMS has been ported to the Intel IA-64
architecture; to HP Integrity systems based on the
Intel Itanium Processor Family.
The first release of OpenVMS I64 was V8.0, with the
first general release of OpenVMS I64 known as V8.2.
Yes, there was a V8.1 release, too.
Some Intel and HP terminology: Itanium Processor Family
is the name of the current implementation; of the
current Intel microprocessor family implementing
the IA-64 architecture. IA-64 is the name of the
Intel architecture implementing the VLIW (Very Long
Instruction Word) design known as EPIC (Explicitly
Parallel Instruction Computing).
14-32
Hardware Information
I64 is the name of a family of HP computer systems that
use Intel Itanium processors and that are supported
by "HP OpenVMS for Integrity Servers" (and itself more
commonly known as "OpenVMS I64"); by one of the HP
operating systems that runs on HP Integrity hardware.
The Extensible Firmware Interface (EFI) is the name of
the console environment for Itanium systems, and the
Baseboard Management Console (BMC) and the optional
Management Processor (MP) are the most typical hardware
interfaces into the system console.
_____________________________
14.4.5.1 Where can I get Intel Itanium information?
Intel Itanium Processor Family and IA-64 Architecture,
Hardware, Software, and related docoumentation
materials are available at:
o ftp://download.intel.com/design/IA-64/manuals/
o ftp://download.intel.com/design/IA-64/Downloads/
o ftp://download.intel.com/design/IA-
64/Downloads/archSysSoftware.pdf
o ftp://download.intel.com/design/IA-
64/Downloads/24870101.pdf
Information on the classic Intel Extensible Firmware
Interface (EFI) (for IA-64) and of the multi-platform
Unified EFI (UEFI) console project documentation are
available at the following URLs:
o Intel
http://developer.intel.com
o UEFI
http://www.uefi.org
Please see Section 14.4.5 for Intel Itanium
terminology.
14-33
Hardware Information
__________________________________________________________
14.5 What is the least expensive system that will run OpenVMS?
The cheapest systems that are or have been recently
offered by HP that will run OpenVMS Alpha are the
AlphaServer DS10 server, the AlphaStation XP900
workstation, the AlphaStation VS10 workstation, and
the AlphaStation XP1000 workstation. Other companies
sell Alpha-powered systems and Alpha motherboards, some
of which will run (and can be purchased with) OpenVMS-
see the OpenVMS Software Product Description (SPD) for
details on the supported systems and configurations.
There are also many used AlphaStation, AlphaServer,
and DEC 3000 series models available which are quite
suitable. For more experienced OpenVMS system managers,
the (unsupported) Multia can bootstrap OpenVMS-see
Section 14.4.1 for details.
Used Itanium-based systems that a hobbyist could
likely use to bootstrap OpenVMS I64 have been seen
selling on auction websites for under US$1000. New
Integrity rx1620 series systems (officially supported
by OpenVMS I64) have been offered as part of a week-
long DSPP porting and training package for US$2000. See
Section 2.8.3 for details on the DSPP program. Also see
the HP Renew used- and/or refurbished-equipment program
for any hardware that might be available.
Free and commercial VAX software-based hardware
emulators are available for various platforms. See
Section 13.12 for details on those.
Depending on the OpenVMS version and configuration, the
OpenVMS Software Product Description (SPD) is available
at:
o http://www.hp.com/go/openvms/doc/
When purchasing a system, ensure that the system itself
is supported, that the system disk drive is supported
or closely compatible, that the optical (CD or DVD)
drive is supported or is closely compatable and that
(in the case of SCSI devices) it also specifically
supports 512-byte block transfers; no equivalent
requirement exists for IDE devices. Also particularly
ensure that the video controller is supported. Use of
14-34
Hardware Information
supported HP hardware will generally reduce the level
of integration effort involved.
A CD-ROM, CD-R or DVD drive is required for OpenVMS
Alpha installations, and a DVD-ROM or recordable or
rewritable DVD DVD drive is required for OpenVMS I64
installations.
CD-ROM drive compatibility information is available at:
o http://sites.inka.de/pcde/dec-cdrom-list.txt
__________________________________________________________
14.6 Where can I get more information on Alpha systems?
HP operates an AlphaServer information center at:
o http://www.hp.com/go/server
Alpha Technical information and documentation is
available at:
o ftp://ftp.compaq.com/pub/products/alphaCPUdocs/
o http://h18000.www1.hp.com/products/software/alpha-
tools/
o ftp://ftp.digital.com/pub/DEC/Alpha/systems/
o http://ftp.digital.com/pub/
Digital/info/semiconductor/literature/dsc-
library.html
o Alpha Systems Update:
http://www.compaq.com/alphaserver/fb_acu.html
Software Product Description (SPD) information,
including platform support documentation:
o http://h18000.www1.hp.com/info/spd/
OpenVMS typically uses SPD 25.01.xx, SPD 41.87.xx,
and SPD 82.35.xx.
Information on Multia hardware is available at:
o http://www.netbsd.org/Ports/alpha/multiafaq.html
14-35
Hardware Information
Information on DEC 3000 series hardware is available
at:
o http://www.phys.ufl.edu/~prescott/linux/alpha/dec3000-
sysinfo.html
o http://www.phys.ufl.edu/~prescott/linux/alpha/dec3000-
docs.html
o http://ftp.netbsd.org/pub/NetBSD/misc/dec-
docs/index.html
The NetBSD folks maintain useful Alpha hardware
information at:
o http://www.netbsd.org/Ports/alpha/models.html
__________________________________________________________
14.7 Describe Alpha instruction emulation and instruction
subsets?
The Alpha architecture is upward- and downward-
compatible, and newer instructions are emulated on
older platforms, for those cases where the compiler
is explicitly requested to generate the newer Alpha
instructions.
In particular, OpenVMS Alpha V7.1 and later include the
instruction emulation capabilities necessary for the
execution of newer Alpha instructions on older Alpha
microprocessors. (Instruction emulation capabilities
are available for user-mode application code, and
are not available to device drivers or other similar
kernel-mode code.)
Alpha instructions are available in groups (or
subsets). Obviously, there is the base instruction set
that is available on all Alpha microprocessors. Then,
the following are the current instruction extension
groups (or subsets) that are available on some of
various recent Alpha microprocessors:
o byte/word extension (BWX):
LDBU, LDWU, SEXTB, SEXTW, STB, and STW.
14-36
Hardware Information
o floating-point and square root extension (FIX):
FTOIS, FTOIT, ITOFF, ITOFS, ITOFT, SQRTF, SQRTG,
SQRTS, and SQRTT.
o count extension (CIX):
CTLZ, CTPOP, and CTTZ.
o multi-media extension (MVI):
MAXSB8, MAXSW4, MAXUB8, MAXUW4, MINSB8, MINSW4,
MINUB8, MINUW4, PERR, PKLB, PKWB, UNPKBL, and
UNPKBW.
The typical instruction subset that provides the
biggest win-and of course, your mileage may vary-is
typically the instruction set that is provided by the
EV56 and later; specifically, the byte-word instruction
subset. To select this subset, use the following:
/ARCHITECTURE=EV56/OPTIMIZE=TUNE=GENERIC
The /ARCHITECTURE controls the maximum instruction
subset that the compiler will generally use, while
the /OPTIMIZE=TUNE controls both the instruction-level
scheduling and also the instructions generated inside
loops-any code resulting from /OPTIMIZE=TUNE that is
specific to an instruction subset will be generated
only inside loops and will also be "protected" by
an AMASK-based test that permits the execution of
the proper code for the particular current Alpha
microprocessor.
Typically /OPTIMIZE=TUNE=GENERIC is the appropriate
choice for tuning, and the /ARCHITECTURE selects the
minimum target architecture for general use throughout
the generated code.
generated for later architectures and instruction
subsets will run on older Alpha systems due to the
emulation, but if /ARCHITECTURE is a significant
benefit, then the emulation might be a performance
penalty.
Please see the OpenVMS Ask The Wizard area for the
source code of a (non-privileged) tool that looks at
the instruction subsets available on the particular
Alpha microprocessor that the tool is run on. This tool
14-37
Hardware Information
demonstrates the use of the Alpha AMASK and IMPLVER
instructions.
Please see Section 10.22 and Section 14.9 for
additional details and related considerations.
__________________________________________________________
14.8 So how do I open up the DEC 3000 chassis?
After removing those two little screws, tilt the back
end of the top shell upwards-then you can remove the
lid.
__________________________________________________________
14.9 What is byte swizzling?
"Swizzling" is the term used to describe the operation
needed to do partial longword (i.e. byte or word)
accesses to I/O space on those systems that don't
support it directly. It involved shifting the offset
into an address space by 5 (or 7 for one older system),
and ORing this into the base address. It then required
the size of the operation to be ORed into the low order
bits.
That is, because the EV4 and EV5 CPUs did not bring
bits 0 and 1 off the chip, to do programmed I/O for
bytes/words, the information on the size/offset of the
transfer was encoded into the address data. The data
itself then had to be shifted into the correct "byte
lane" ; into the required offset position within a
longword transfer;
The EV56 microprocessor supports byte/word instruction
references in memory space, however only specific EV56
systems can support byte/word accesses into I/O space;
device drivers may or may not be able to utilize to
byte/word instructions to access device registers.
Further, even on an EV56 system with hardware support
for byte/word accesses into I/O space, the relevant
OpenVMS routines typically do not support byte/word
access into I/O space.
14-38
Hardware Information
Systems based on the EV6 microprocessor (with the
salient exception of the AlphaServer GS60 and
AlphaServer GS140 series, for reasons of platform
compatability) support a flat, byte addressable I/O
space.
If a device driver uses CRAM or IOC$WRITE_IO/IOC$READ_
IO, then OpenVMS will correctly process the swizzling
requirements without requiring changes the driver;
OpenVMS will transparently swizzle and unswizzle the
I/O space references, if needed for the particular
target platform. (Access and use of these routines may
or may not be feasible within the requirements for a
particular device driver, with the decision typically
based on the target performance requirements and the
expected frequency of device references and thus the
expected frequency of calls to these or other similar
routines.)
To use byte/word operations on MEMORY, you need to
tell the compiler to use the EV56 or EV6 architecture
(/ARCHITECTURE=EV56). Memory operations did not
swizzle, but the compiler would do long/quad
access, and extract/insert bytes as needed. Using
/ARCHITECTURE=EV56 allows smaller, more efficient
byte/word access logic to memory.
If the application is directly referencing I/O space
access across a range of Alpha systems such as is done
with the X Windows device drivers, then the driver will
need to know how to do swizzling for old platforms,
and byte access for new platforms. Device drivers for
new graphics controllers can specifically target and
specifically require platforms based on EV6 and later
Alpha microprocessors because of this requirement, for
instance.
Please see Section 10.22 and Section 14.7 for
additional details and related considerations.
14-39
Hardware Information
__________________________________________________________
14.10 What is the layout of the VAX floating point format?
The VAX floating point format is derived from one
of the PDP-11 FP formats, which helps explain its
strange layout. There are four formats defined: F 32-
bit single-precision, D and G 64-bit double-precision
and H 128-bit quadruple precision. For all formats,
the lowest addressed 16-bit "word" contains the sign
and exponent (and for other than H, some of the most
significant fraction bits). Each successive higher-
addressed word contains the next 16 lesser-significant
fraction bits. Bit 15 of the first word is the sign, 1
for negative, 0 for positive. Zero is represented by
a biased exponent value of zero and a sign of zero;
the fraction bits are ignored (but on Alpha, non-
zero fraction bits in a zero value cause an error.)
A value with biased exponent zero and sign bit 1 is
a "reserved operand" - touching it causes an error -
fraction bits are ignored. There are no minus zero,
infinity, denormalized or NaN values.
For all formats, the fraction is normalized and the
radix point assumed to be to the left of the MSB, hence
the following range: 0.5 less than or equal to f and
less than 1.0. The MSB, always being 1, is not stored.
The binary exponent is stored with a bias varying with
type in bits 14:n of the lowest-addressed word.
FP Exponent Exponent Mantissa (Fraction) bits,
Type Bits Bias including hidden bit
==========================================================
F 8 128 24
D 8 128 56
G 11 1024 53
H 15 16384 113
The layout for D is identical to that for F except for
32 additional fraction bits.
Example: +1.5 in F float is hex 000040C0 (fraction of
.11[base 2], biased exponent of 129)
14-40
Hardware Information
__________________________________________________________
14.11 Where can I find more info about VAX systems?
o HP provides limited VAX platform information via
links at the AlphaServer website, itself available
via:
http://www.hp.com/go/server/
o Jim Agnew maintains a MicroVAX/VAXstation FAQ at:
http://www.people.vcu.edu/~agnew/MVAX/MVAX_FAQ.HTML
o The VAXstation 3100 Owner's Guide:
http://www.whiteice.com/~williamwebb/intro/DOC-
i.html
o VAX Console information:
http://www.mcmanis.com/chuck/computers/vaxen/panels.htm
o A field guide to PDP-11 (and VAX) Q-bus and UNIBUS
modules can be found at:
http://metalab.unc.edu//pub/academic/computer-
science/history/pdp-11/hardware/field-guide.txt
o Various VAX historical information (also see
Section 2.1) can be found at:
http://telnet.hu/hamster/vax/e_index.html
__________________________________________________________
14.12 Where can I find information on NetBSD for VAX systems?
Gunnar Helliesen maintains a NetBSD VAX FAQ at
o http://vaxine.bitcon.no/
__________________________________________________________
14.13 What system disk size limit on the MicroVAX and
VAXstation 3100?
System disks larger than 1.073 gigabytes (GB)-1fffff
hexidecimal blocks - are not supported on any member of
the VAXstation 3100 series and on certain older members
of the MicroVAX 3100 series, and are not reliable
on these affected systems. (See below to identify
the affected systems-the more recent members of the
MicroVAX 3100 series systems are NOT affected.)
14-41
Hardware Information
Various of the SCSI commands used by the boot drivers
imbedded in the console PROM on all members of the
VAXstation 3100 series use "Group 0" commands, which
allow a 21 bit block number field, which allows access
to the first 1fffff hexidecimal blocks of a disk. Any
disk references past 1fffff will wrap-this wrapping
behaviour can be of particular interest when writing a
system crashdump file, as this can potentially lead
to system disk corruptions should any part of the
crashdump file be located beyond 1.073 GB.
More recent systems and console PROMs use "Group 1"
SCSI commands, which allow a 32 bit block number field.
There was a similar limitation among the oldest of
the MicroVAX 3100 series, but a console boot PROM
was phased into production and was made available for
field retrofits-this PROM upgrade allows the use of the
"Group 1" SCSI commands, and thus larger system disks.
There was no similar PROM upgrade for the VAXstation
3100 series.
Systems that are affected by this limit:
o VAXstation 3100 series, all members. No PROM upgrade
is available.
o MicroVAX 3100 models 10 and 20. No PROM upgrade is
available.
o MicroVAX 3100 models 10e and 20e. Only systems with
console VMB versions prior to V6.4 are affected. A
PROM upgrade for these specific systems is (or was
once) available.
Also see
o http://www.whiteice.com/~williamwebb/intro/DOC-
i.html
Also see Section 9.5.
14-42
Hardware Information
__________________________________________________________
14.14 What are the VAX processor (CPU) codes?
CPU: Platform:
----- ---------
KA41-A : MicroVAX 3100 Model 10 and 20
KA41-B : VAXserver 3100 Model 10 and 20
KA41-C : InfoServer
KA41-D : MicroVAX 3100 Model 10e and 20e
KA41-E : VAXserver 3100 Model 10e and 20e
KA42-A : VAXstation 3100 Model 30 and 40
KA42-B : VAXstation 3100 Model 38 and 48
KA43-A : VAXstation 3100 Model 76
KA45 : MicroVAX 3100 Model 30 and 40
KA46 : VAXstation 4000 Model 60
KA47 : MicroVAX 3100 Model 80
KA48 : VAXstation 4000 VLC
KA49-A : VAXstation 4000 Model 90/90A
KA49-B : VAXstation 4000 Model 95
KA49-C : VAXstation 4000 Model 96
KA50 : MicroVAX 3100 Model 90
KA51 : MicroVAX 3100 Model 95
KA52 : VAX 4000 Model 100
KA53 : VAX 4000 Model 105
KA54 : VAX 4000 Model 106
KA55 : MicroVAX 3100 Model 85
KA56 : MicroVAX 3100 Model 96
KA57 : VAX 4000 Model 108
KA58 : MicroVAX 3100 Model 88
KA59 : MicroVAX 3100 Model 98
KA85 : VAX 8500
KA86 : VAX 8600
KA88 : VAX 8800
KA600 : VAX 4000-50 (aka VAXbrick)
KA610 : MicroVAX I, VAXstation I (aka KD32)
KA620 : rtVAX (VAXeln)
KA62A : VAX 6000-200
KA62B : VAX 6000-300
KA630 : MicroVAX II, VAXstation II
KA640 : MicroVAX 3300, MicroVAX 3400
KA650 : VAXstation 3200, MicroVAX 3500, MicroVAX 3600, MicroVAX III
KA64A : VAX 6000-400
KA655 : MicroVAX 3800, MicroVAX 3900, MicroVAX III+
KA65A : VAX 6000-500
14-43
Hardware Information
KA660 : VAX 4000-200, VAX 4 upgrade
KA66A : VAX 6000-600
KA670 : VAX 4000-300
KA675 : VAX 4000-400
KA680 : VAX 4000-500
KA681 : VAX 4000-500A
KA690 : VAX 4000-600
KA691 : VAX 4000-605A
KA692 : VAX 4000-700A
KA693 : VAX 4000-605A
KA694 : VAX 4000-705A
KA730 : VAX-11/730
KA750 : VAX-11/750
KA780 : VAX-11/780, VAX-11/782
KA785 : VAX-11/785
KA7AA : VAX 7000-600
KA7AB : VAX 7000-700
KA7AC : VAX 7000-800
KA800 : VAXrta
KA820 : VAX 8200, VAX 8300
KA825 : VAX 8250, VAX 8350
KA865 : VAX 8650
__________________________________________________________
14.15 Where can I get software and hardware support
information?
Please contact the HP Customer Support Center. Services
and information, manuals, guides, downloads, and
various other information is available via the support
link at:
o http://www.hp.com/products/openvms/
Various hardware and system documentation is available
at:
o http://www.hp.com/go/services/
TSM (Terminal Server Manager), DEChub, DECserver, etc.
information:
o http://www.compaq.com/support/digital_networks_
archive/
14-44
Hardware Information
The owner and maintainer of current DECserver and
related hardware is DIGITAL Network Products Group
(DNPG):
o http://www.dnpg.com/
__________________________________________________________
14.16 Where can I get hardware self-maintenance support
assistance?
The HP Parts Directory and the HP Parts Reference
Guide (arguably the most direct descendents of the
HP Assisted Services program, of the Compaq Assisted
Services program, and of the now-ancient DECmailer
program) are available to customers that wish to
maintain their own system(s) (self-maintenance),
but that wish some level of assistance in acquiring
specific parts, hardware diagnostics and hardware
manuals for the system(s), and that wish to have
access to spares and module-level repairs for customer-
performed hardware module swaps:
o http://www.hp.com/go/parts/
o http://www.hp.com/buy/parts/
The HP Parts Reference Guide replaces the CAS-Catalog
and DAS-Catalog parts catalogs and related resources.
Details of the available self-maintenance programs and
services can vary by geography and by the particular
services channel(s), and current program specifics are
available via the above URLs.
__________________________________________________________
14.17 Why does my system halt when I power-cycle the console
terminal?
Various VAX and Alpha consoles are designed to process
the BREAK signal, treating it as a HALT request.
A BREAK is a deliberately-generated serial line framing
error.
When a serial line device such as a terminal
powers up (or sometimes when powering down) it can
generate framing errors. These framing errors are
indistingushable from a BREAK signal.
14-45
Hardware Information
When a BREAK is received on a serial line console
for various VAX systems-including most VAXstation,
MicroVAX, and VAX 4000 series-it is typically
interpreted as a HALT. Alpha systems will also often
process a BREAK in a similar fashion, halting the
system.
There is no uniform or generally-available way to
disable this behaviour on every VAX or Alpha system. On
some systems, BREAK processing can be disabled in favor
of [CTRL/P], or [CTRL/P] is the only way to halt the
processor.
The most common way to avoid these halts is to disable
the serial line console or to simply not power-cycle
the console terminal. There is certain important
system state information that is displayed only on
the console, OpenVMS expects to always have access to
the system console.
Also see Section 5.6.
__________________________________________________________
14.18 Can I reuse old keyboards, mice and monitors with a PC?
Older HP keyboards (those with the DIGITAL logo and
the RJ modular jacks), older HP mice (those with the
DIGITAL logo and with the RJ modular jacks, or with
a DIN connector with pins in a configuration other
than the PC-standard DIN connector pin orientation),
and older video monitors (with RGB synch-on-green
video signaling) all use signaling formats and/or
communications protocols that differ from the PC
standards, and are not (easily) interchangable nor
(easily) compatible with typical PC peripheral device
controllers. The LK201 and LK401 keyboards, the VSXXX
series mice, the VR260 and VR290 monitors, etc., are
incompatible with most PC systems and with most KVM
switches.
Newer HP (and Compaq) keyboards (those with with PC-
style DIN plugs, and the HP, Compaq or DIGITAL logo),
newer HP mice (with PC-pin DIN plugs, and the HP,
Compaq or DIGITAL logo), and newer video monitors
(multi-synch) are often interchangeable with "industry
standard" PC systems, and can often be used with
14-46
Hardware Information
most PC peripheral device controllers. LK461, LK463,
LK46W, LK471, PC7XS-CA, VRC16, VRC21, TFT-series LCD
flat-panel displays, etc., are typically reasonably
compatible with most PC systems, and will usually
perform as expected within the limits of the hardware.
(For details of CRT and LCD display compatibility,
please see Section 14.19.)
Rule of thumb: if the peripheral device component
was sold for use with the DEC 2000 (DECpc 150 AXP),
an AlphaServer series, an AlphaStation series, or a
more recent Alpha system, it will probably work with a
PC peripheral controller or with a PC-compatible KVM
switch. If the peripheral device component was sold
for use with an VT420 or older terminal, most VAX, most
VAXstation, and most Alpha systems with names in the
format DEC [four-digit-number], it probably won't work
on a PC system or with a PC-compatible KVM.
Note that the above is a general guideline, and should
not be read to indicate that any particular peripheral
device will or will not work in any particular
configuration, save for those specific configurations
the device is explicitly supported in.
Software Integrators sells a video adapter card
called Gemini P1 which will drive many of the older
HP (DIGITAL-logo) fixed-frequency monitors on a PC
system:
o http://www.si87.com/
The DIGITAL (classic 2-5-2-style) part number 29-
32549-01 converts the output from the RGB cable (3 BNC,
synch-on-green) that comes with the VAXstation 3100 and
VAXstation 4000 series to a female SVGA D connector.
You may be able to find third-party converters or
adapters (3 BNCs with synch-on-green signaling to 5
BNCs with VGA/SVGA, or to 15-pin VGA/SVGA.
This adapter will allow PC multisync monitors with
the needed frequency specifications to be used with
the VAXstation series synch-on-green video connection.
It may well also work with a VAXstation 2000 series
14-47
Hardware Information
systems, but specifics and performance of that
combination are not immediately known at this writing.
The protocol definition for the old DIGITAL keyboard
and mouse interfaces is buried at the back of the QDSS
section in the old VAXstation II manual, specifically,
in the back of the VCB02 Video Subsystem Technical
Manual (EK-104AA-TM). The keyboard wiring and protocol
is in appendix B, and occupies circa 44 pages. The
mouse is in appendix C, circa 12 pages.
Also see Section 14.19.
__________________________________________________________
14.19 Which video monitor works with which graphics controller?
To determine the answer to the "will this video monitor
or this LCD panel work with this graphics controller?"
question, please first locate the resolution(s) and the
frequencies that are possible/supported at both ends
of the video cable (on the display and on the graphics
controller, in other words), and then determine if
there are any matching settings available. If there are
multiple matches, you will need to determine which one
is most appropriate for your needs.
You will also need to determine if the video monitor
or graphics controller requires the 3 BNC signaling
with the synchronization signals on the green wire,
or the 5 BNC signaling common on many PCs, or other
connections such as the DB15 video connector or USB
connector used on various systems. (BNC signaling
is comparatively old, but prevalent with many older
hobbyist AlphaStation or VAXstation configurations.)
If there are no matches, you will likely need to change
the hardware at one or both ends of the video cable.
The refresh frequencies for many devices have been
posted to comp.os.vms and/or other newsgroups. Search
the archives for details. Also see:
o http://www.repairfaq.org/
o http://www.mirage-mmc.com/faq/
o http://www.geocities.com/SiliconValley/Foothills/4467/fixedsync.html
14-48
Hardware Information
o http://saturn.tlug.org/sunstuff/ffmonitor.html
o http://hawks.ha.md.us/hardware/monitor.html
LCD-based and plasma-based flat-panel displays are
generally compatible with all recent OpenVMS Alpha
systems and supported graphics controllers. For
best results, you should generally set the graphics
controller to match the native LCD or plasma display
resolution and (for LCD displays) also set the
controller refresh rate to 60Hz. Check your graphics
controller and your display documentation for any
device-specific requirements and/or configuration
recommendations.
Some of the older graphics controllers around do not
necessarily generate stable signals at 60 Hz, if the
controller can even generate that refresh rate; you may
end up upgrading to a less-old controller. (At least
some of the PowerStorm 3D30 and PowerStorm 4D20 series
controllers, for instance, are not necessarily the
best choice for 60 Hz operations with an LCD, based
on empirical testing with an AlphaStation XP1000,
PowerStorm 3D30, and a TFT2025 series LCD. Degraded
or mismatched signals produce degraded displays,
obviously. The newest graphics controllers compatible
with your particular system are generally better
choices here for use with LCD; the Radeon 7500 series
is a good choice for most EV6-class AlphaStation
systems, for instance.
Also see Section 14.18.
__________________________________________________________
14.20 Where can I get information on storage hardware?
Information on various HP (Compaq, DIGITAL) OpenVMS
and other disk storage hardware and controllers, and
related technical information on SCSI, device jumpers,
etc., is available at:
o http://theref.aquascape.com/
Note
the aquascape website appears to have become
unavailable, and the FAQ maintainer is unaware
14-49
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
User Contributions: |
Comment about this article, ask questions, or add new information about this topic: