When it came time to chose a "marketing name" for the Alpha AXP line, the company was in a quandary. The internal "code name" for the project, Alpha, was widely known and would seem the ideal choice, but it was already in common use by a number of other companies and could not be trademarked. A well-known "name search" firm was hired and was asked to come up with two lists of possible names. The first list was intended to evoke the feeling of "extension to VAX", while the second list was to suggest "not a VAX". Unfortunately, none of the choices offered were any good; for example, "VAX 2000" was found on the first list while the second list contained "MONDO" (later to be used for a kids' soft drink).
Shortly before announcement, a decision was made to name the new line ARA, for Advanced RISC Architecture. However, an employee in Israel quickly pointed out that this name, if pronounced in the "obvious" manner, sounded very much like an Arabic word with decidely unfortunate connotations. Eventually, AXP was selected; the architecture would be referred to as "Alpha AXP" whereas products themselves would use just "AXP".
Use of the AXP term has been phased out in favour of using Alpha. For example, OpenVMS AXP is now called called "OpenVMS Alpha".
The following contain information on current Alpha and VAX products:
http://www.compaq.com/alphaserver/products.html
http://www.compaq.com/alphaserver/vax/
The following sites contain information on various retired VAX and
Alpha products:
http://www.compaq.com/alphaserver/archive/index.html
http://www.compaq.com/alphaserver/performance/perf_tps.html
Also see CPU2000:
http://www.spec.org/osg/cpu2000/
http://www.spec.org/osg/cpu2000/results/cpu2000.html
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/readme.html
The latest and greatest firmware - if updated firmware has been released
after the most recent firmware CD was distributed - is located at:
ftp://ftp.digital.com/pub/Digital/Alpha/firmware/interim/
Please send your comments and feedback to :
alpha_server@service.digital.com
For information on creating bootable floppies containing the firmware,
and for related tools, please see the following areas:
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkboot.txt
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkbootarc.txt
ftp://ftp.digital.com/pub/DEC/Alpha/firmware/utilities/mkntboot.txt
[Stephen Hoffman]
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
[Clair Grant]
Also see ALPHA14.
http://www.openvms.compaq.com/freeware/multia/
Instructions are included IN the kits. READ THE INSTRUCTIONS.
Some of the restrictions involved when running OpenVMS on the Multia
system include (but may well not be limited to) the following:
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:
http://home.earthlink.net/~djesys/vms/hobbyist/multia.html
http://home.earthlink.net/~djesys/vms/hobbyist/mltianot.html
http://home.earthlink.net/~djesys/vms/hobbyist/support.html
http://www.netbsd.org/Ports/alpha/multiafaq.html
[Stephen Hoffman]
[David J. Dachtera]
OpenVMS Alpha is not supported on the AlphaPC 164LX and 164SX,
though there are folks that have gotten certain of the LX series to
load SRM and bootstrap OpenVMS. (The Aspen Durango II variant.)
One problem was reported: IDE bootstraps fail; SCSI is required.
Also see ALPHA13.
Depending on the OpenVMS version and configuration, the OpenVMS Software Product Description (SPD) is available at:
http://www.compaq.com/info/spd/OpenVMS typically uses SPD 25.01.xx and/or SPD 41.87.xx.
When purchasing a system, ensure that the system itself is supported, that the system disk drive is supported or closely compatible, that the CD-ROM drive is supported or is closely compatable and that it also specifically supports 512 byte block transfers, and particularly ensure that video controller is supported. Use of supported Compaq hardware will generally reduce the level of integration effort involved.
A CD-ROM drive is required for OpenVMS Alpha installations.
[Stephen Hoffman]
http://www.compaq.com/alphaserver/Alpha Technical information and documentation is available at:
http://www.support.compaq.com/alpha-tools/documentation/current/chip-docs.html ftp://ftp.digital.com/pub/DEC/Alpha/systems/ http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-library.htmlPlatform product documentation:
http://www.compaq.com/info/spd/
http://www.digital.com/info/lists/key-server_AL.HTM
http://www.digital.com/info/lists/key-workstation_AL.HTM
Information on Multia hardware is available at:
http://www.netbsd.org/Ports/alpha/multiafaq.html
[Stephen Hoffman]
Information on current and future Alpha microprocessor designs is
also available from AlphaPowered at:
http://www.alphapowered.com/alpha_tomorrow.html
http://www.alphapowered.com/timeline.html
http://www.alphapowered.com/ev7-and-ev8.html
The NetBSD folks maintain some Alpha hardware information at:
http://www.netbsd.org/Ports/alpha/models.html
>>> 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 |
>>> SET BOOT_OSFLAGS 0,1
The specific environment variables differ by platform and by firmware version - the baseline set is established by the Alpha Architecture:
AUTO_ACTION ("BOOT", "HALT", "RESTART", any other value assumed to be HALT)
BOOT_DEV
BOOTDEF_DEV
BOOTED_DEV
BOOT_FILE
BOOTED_FILE
BOOT_OSFLAGS
BOOTED_OSFLAGS
BOOT_RESET ("ON","OFF")
DUMP_DEV
ENABLE_AUDIT ("ON", "OFF")
LICENSE
CHAR_SET
LANGUAGE
TTY_DEV.
LP_* and HP_*, and each particular
console implementation can (and often does) have various sorts
of platform-specific extensions beyond these variables...
The contents of a core set of environment variables are accessable from OpenVMS using the f$getenv lexical and the sys$getenv system service. (These calls are first documented in V7.2, but have been around for quite a while.) Access to arbitary console environment variables is rather more involved, and not directly available.
[Stephen Hoffman]
http://www.jyu.fi/~kujala/vms-in-axppci33.txtTips for using the Multia files with the AXPpci33:
[Robert Alan Byer]
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 powercycle the box to finish the process.
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.
For the list of boxes officially supported by OpenVMS, please see the OpenVMS Software Product Description (SPD).
http://www.compaq.com/info/spd/
OpenVMS typically uses SPD 25.01.xx and/or SPD 41.87.xx.
If you are very lucky, sometimes a particular unsupported Alpha box or motherboard will resemble a supported box sufficiently closely and can thus mimic that system and bootstrap. (No such family resemblances exist for the XL.) If you are exceedingly lucky, somebody here in OpenVMS Engineering will have put together a bootstrap kit - such as that for the Multia. (No Miata-like OpenVMS bootstrap kit exists for the XL.)
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.
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:
/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.
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 demonstrates the use of the Alpha AMASK and IMPLVER instructions.
The software-maintained system time can drift more, primarily due to other system activity. Typical causes of drift include extensive high-IPL code (soft memory errors, heavy activity at device IPLs, etc) that are causing the processing of the clock interrupts to be blocked.
[Felix Kreisel]
That is, because EV4 and EV5 did not bring bits 0 and 1 off the chip, to do programmed IO 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" (i.e. it's actual position within a longword).
EV56 (though not EV5) had byte/word operations, but OpenVMS did not directly support this for IO. EV6 systems (with the exception of the AlphaServer GS60 and AlphaServer GS140 series, for reasons of platform compatability) all support a flat byte addressable IO space.
If device driver uses CRAM or IOC$WRITE_IO/IOC$READ_IO, then OpenVMS will do the right thing without changing the driver - OpenVMS will swizzle and unswizzle as needed.
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 IO logic to memory. Beware: a few Alpha systems have EV56, but do not support byte/word to I/O space.
If the application is directly doing IO access across a range of Alpha systems (like the graphics servers), then the driver will need to know how to do swizzling for old platforms, and byte access for new platforms.
[Fred Kleinsorge]
A typical sequence used for switching over from the AlphaBIOS graphics console to the SRM console follows:
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 Windows NT to write a
"harmless" signature to any disk used by OpenVMS, Tru64 UNIX, or
Linux, as this will clobber a key part of the disk. (On OpenVMS,
you can generally recover from this "harmless" action by using the
WRITEBOOT tool.)
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 NTand power-cycle the system. For information on acquiring firmware, see ALPHA6. For information on OpenVMS license PAKs (for hobbyist use) see VMS9. For information on the Multia, see ALPHA8.
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.
If you have an -au series system, you can determine which IDE chip you have using the SRM console command:
SHOW CONFIGURATIONIf 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.)
| Next | Back |