=;The OpenVMS Frequently Asked Questions (FAQ)D

The OpenVMS Frequently Asked Questions (FAQ)



 r \ ^  
PreviousContentsIndex

K

14.3.5.3 What are the VAX VMB boot flag values?



mThe flags described in Table 14-3 are passed (via register R5) to Ethe OpenVMS VAX primary bootstrap image VMB.EXE. These flags control .the particular behaviour of the bootstrap.

n   # &                                                                             
Table 14-3 VAX Conversational Bootstrap Flags
Bit Mnemonic Description
 0 CONV K Conversational boot. At various points in the system boot procedure, M the bootstrap code solicits parameter and other input from the console L terminal. If DIAG is set, then the diagnostic supervisor should enter < its menu mode and prompt user for the devices to test.
 1 DEBUG K Debug. If this flag is set, OpenVMS VAX maps the code for the XDELTA A debugger into the system page tables of the running system.
 2 INIBPT L Initial breakpoint. If RPB$V_DEBUG is set, OpenVMS VAX executes a BPT 5 instruction immediately after enabling mapping.
 3 BBLOCK J Secondary boot from the boot block. Secondary bootstrap is a single 3 512-byte block, whose LBN is specified in R4.
 4 DIAG H Diagnostic boot. Secondary bootstrap is the Diagnostic Supervisor  image; the image & [SYSMAINT]DIAGBOOT.EXE.
 5 BOOBPT L Bootstrap breakpoint. Stops the primary and secondary bootstraps with @ an XDELTA breakpoint instruction prior to the memory test.
 6 HEADER J Image header. Takes the transfer address of the secondary bootstrap J image from that file's image header. If the RPB$V_HEADER bit is not H 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 J Memory test inhibit. Sets a bit in the PFN bit map for each page of / memory present. Does not test the memory.
 8 SOLICT H File name. VMB prompts for the name of a secondary bootstrap file.
 9 HALT L Halt before transfer. Executes a HALT instruction before transferring ) control to the secondary bootstrap.
 10 NOPFND K No PFN deletion (not implemented; intended to tell VMB not to read a N file from the boot device that identifies bad or reserved memory pages, H so that VMB does not mark these pages as valid in the PFN bitmap).
 11 MPM H Specifies that multi-port memory is to be used for the total EXEC E memory requirement. No local memory is to be used. This is for F tightly-coupled multi-processing. If the RPB$V_DIAG bit is also G enabled, then the Diagnostic Supervisor enters its AUTOTEST mode.
 12 USEMPM K Specifies that multi-port memory should be used in addition to local ; memory, as though both were one single pool of pages.
 13 MEMTEST J Specifies that a more extensive algorithm be used when testing main 5 memory for hardware uncorrectable (RDS) errors.
 14 FINDMEM  Requests the use of MA780 1 multiport memory if the main MS780 T memory is insufficient for booting. This is a remnant of the support  for the Q VAX-11/782 series system and its Asymmetric Multiprocessing (ASMP) W environment. Support for the VAX-11/782 and for ASMP was withdrawn with S the V5.0 release; with the advent of Symmetric Multiprocessing (SMP)  support.


FThe 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?



HThe AlphaStation series will boot without a keyboard attached. To use a Bserial terminal as the console, issue the SRM console command SET CCONSOLE SERIAL followed by the console INIT command. Once this SRM Gcommand sequence has been invoked and the CONSOLE environment variable Fis set to SERIAL, the Alpha system will use the serial terminal. (Set Cthe environment variable to GRAPHICS to select the console display !output via the graphics display.)

FThe DEC 3000 series has a jumper on the motherboard for this purpose. DVarious older Alpha workstations generally will not (automatically) Ebootstrap without a keyboard connected, due to the self-test failure 3that arises when the (missing) keyboard test fails.

CThe 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). 




HAlphaServer 4100 and derivative series platforms, and AlphaServer GS80, GGS160, and GS320 series system consoles are capable of 57600 baud. See Ethe COM2_BAUD console environment variable, and ensure that you have $current SRM firmware version loaded.

GThe AlphaStation and AlphaServer series use a PC-compatible DB9 serial connector for the COM1 and COM2F serial lines (and for the OPA0: console line, if that was configured a via SRM), please see Section 14.26 for details and pin-out.

FFor information on registering software license product authorization Kkeys (PAKs), please see Section 5.6.2.

jFor a related behaviour of DECwindows, please see Section 11.10. For Ginformation on the VAXstation alternate console mechanisms, please see 5Section 14.3.3.3.T

14.3.7 Downloading and using SRM console Firmware?



EThis section discusses downloading and using Alpha console firmware, sometimes called PALcode.b

14.3.7.1 Where can I get updated console firmware for Alpha systems?



9Firmware updates for HP Alpha systems are available from:



@The latest and greatest firmware---if updated firmware has been Hreleased after the most recent firmware CD was distributed---is located at:



CFor information on creating Alpha bootable floppies containing the @firmware, and for related tools, please see the following areas:



HThe SROM firmware loader expects an ODS-2 formatted floppy, see mkboot. DAs for which image to use, the ROM image uses a header and the file Fextension .ROM, and the SROM bootable floppy cannot use the .ROM file.

FTo 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 




nAlso see Section 14.3.7.2. For information on HP Integrity EFI firmware Eupgrades and for a sequence useful in generating CD-R or CD-RW media acontaining a firmware disk image, please see Section 14.3.11.b

14.3.7.2 How do I reload SRM firmware on a half-flash Alpha system?



CSome of the AlphaStation series systems are "half-flash" Bboxes, meaning only one set of firmware (SRM or AlphaBIOS) can be Aloaded in flash at a time. Getting back to the SRM firmware when ;AlphaBIOS (or ARC) is loaded can be a little interesting...

HThat 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.

HTo shuffle the files, copy the target SRM firmware file (as200_v7_0.exe Ais current) to a blank, initialized, FAT-format floppy under the filename A:\FWUPDATE.EXE

FFrom the AlphaBIOS Setup screen, select the Upgrade AlphaBIOS option. 3Once the firmware update utility gets going, enter:

 

"
     Apu-> update srm  1           Answer "y" to the "Are you ready...?"       Apu-> quit 




AYou'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?



GThe specific steps required vary by system. You must first ensure that Hthe particular Alpha system is supported by OpenVMS (see the SPD), that Hall core I/O components (graphics, disk controllers, etc) in the system Eare supported by OpenVMS (see the SPD), and that you have an OpenVMS Hdistribution, that you have the necessary license keys (PAKs), and that +you have the necessary SRM firmware loaded.

GA 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.J
  3. Press [F6] to get to the "Advanced CMOS Setup"  menu.H
  4. Change the "Console Selection" to "OpenVMS Console  (SRM)".H
  5. Press [F10], [F10], then [Enter]  to save your changes.
  6. Power-cycle the system.


FMost Alpha systems support loading both the AlphaBIOS/ARC console and Gthe SRM console at the same time, but systems such as the AlphaStation 255 are "half-flash"G systems and do not support the presence of both the AlphaBIOS/ARC and 6 SRM console firmware at the same time. If you have a D "half-flash" system, you must load the SRM firmware from G floppy, from a network download, or from a firmware CD-ROM. Following I the normal AlphaBIOS or ARC firmware update sequence to the APU prompt, H and then explictly select the target console. In other words, power up C the system to the AlphaBIOS or ARC console, use the supplementary D options to select the installation of new firmware (typically from B 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 




FUse the following sequence to specifically update (and load) SRM from 1AlphaBIOS/ARC on a "half-flash" system:

 

"
    Apu-> update SRM     Apu-> verify     Apu-> quit     Power-cycle the system 




AUse the following sequence to specifically update (and load) the BAlphaBIOS/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 




HOnce you have the SRM loaded, you can directly install OpenVMS or Tru64 ?UNIX on the system. Do not allow Microsoft Windows NT or other Eoperating system(s) to write a "harmless" signature to any Fdisk used by OpenVMS Alpha or OpenVMS VAX, as this will clobber a key Apart of the disk; this will overwrite the OpenVMS bootblock. (On COpenVMS Alpha and OpenVMS VAX, you can generally recover from this Fso-called "harmless" action by using the WRITEBOOT.EXE tool.

?Using OpenVMS I64 and the EFI console, the bootblock structuresHare expected to be compatible with those of Microsoft Windows and other BIntegrity 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.)

GIf you have a "full-flash" system and want to select the SRM Bconsole from the AlphaBIOS or ARC console environment, select the B"Switch to OpenVMS or Tru64 UNIX console" item from the G"set up the system" submenu. Then power-cycle the system. If Gyou 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.

fFor 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.

CInformation on enabling and using the failsafe firmware loader for Evarious systems---this tool is available only on some of the various EAlpha platforms---is available in the hardware documentation for the Gsystem. This tool is used/needed when the firmware has been corrupted, and cannot load new firmware.

FThe full list of AlphaBIOS key sequences---these sequences are needed Hwhen 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 


<

14.3.8 Console Management Options



>Options to collect multiple consoles into a single server are Eavailable, 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 DVAXcluster Console System (VCS) console management package, and has @integrated this capability into the CA management product suite.J

14.3.9 Why do my EFI Boot Aliases Fail?



GOpenVMS I64 boot aliases contain signature information referencing the Cspecific volume, meaning that the entries are specific to the disk =volume and not the disk device. This also means that certain 9operations, such as the SET BOOTBLOCK command or the RUN SYS$SETBOOT.EXE operationGthat can rewrite these volume signatures (signature or GUID values) can&render existing boot aliases unusable.

EIf your boot aliases do not function as expected, first try removing Fand re-adding them; this will resynchronize the boot aliases with the Bvolume contents. If you are using the SET BOOTBLOCK command or theERUN SYS$SETBOOT.EXE operation to rewrite the disk bootblock, you can Drequest that the current signatures (if any) be preserved, and this Fwill typically maintain the validity of your EFI console boot aliases.W

14.3.10 Can OpenVMS access the EFI console Boot Aliases?



For access to the EFI. console environment from OpenVMS I64, see theD BOOT_OPTIONS.COM command procedure, and the EFI SET, SHOW and BCFG > mechanisms. Details on these are in the System Manager's and 7 particularly in the System Manager's Utilities manual.

iFor related information on boot aliases, please see Section 14.3.5.1.P

14.3.11 Downloading and using EFI Console Firmware?



DHP Integrity EFI system firmware can be downloaded in the form of a Ebootable image master, unzipped and then burned onto CD or DVD media c(please see Section 9.7 for details of recording optical media Fdirectly on OpenVMS), and the system can then generally be booted off 6the created media to perform the EFI firmware upgrade.

FThe HP Integrity Server website is accesssable via the following URL, Fand the available services and support information there has links to Dthe available platform-specific firmware images and upgrade-related materials:



FTo use the following sequence, you will need a writable or rewritable ECD drive and software, and a blank CD-R or CD-RW disk. If you use CD Fwriter software for another platform, you will want to use the block, Bbinary, ISO or raw mode operations appropriate for the particular Achosen recording package. The following directions assume use of eOpenVMS and native CD-R capabilities, please see Section 9.7 for associated details.

    E
  1. First, you must acquire the Integrity server firmware from the A above URL. Select the platform, and navigate to the supporting H information and specifically to the Download Drivers and Software link:
  2. Select Cross operating system (BIOS, Firmware, etc.)I
  3. Locate the appropriate ISO-format firmware file. There are several F firmware file formats available and there are also various off-line 9 diagnostic images, choose the ISO-format firmware file.C
  4. Read the directions for the firmware file, then download the H ISO-format firmware (zip-compressed) file. A binary-mode FTP transfer  should be used.
  5. UnzipG the file into the corresponding .ISO data file. Somewhat confusingly, H the .ISO extension can indicate either a block-oriented raw image of a G disk, or a disk with the ISO-9660 volume structure. In this case, the H 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 anG ISO-9660 volume structure. The unzip tool is available on the OpenVMS g Freeware and elsewhere; please see Section 13.11 for details and locations.A
  6. Use CDRECORD or other available recording tool (please see e 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.E
  7. Shut the Integrity Server system down to the EFI console level.F
  8. Unload the recorded CD media from the CD-R drive, label it, and G load it into the Integrity console drive. This assuming the disk was J not generated directly on an Integrity CD-R/RW-capable drive, of course.J
  9. Using the EFI shell, display the current firmware version using the command

     

    "
    info fw 
    
    
    G

  10. Exit the EFI shell and select the boot options maintenance menu; H create a boot alias for the removable media drive for the CD; for the  newly-created firmware disk.J
  11. Boot it. Follow the directions displayed by the firmware loader and F related documentation, heeding the release notes that were reviewed earlier.5
  12. Perform a cold restart of the Integrity server.


CFor information on Alpha SRM console firmware upgrades, please see 8Section 14.3.7.m

14.4 What platforms will OpenVMS operate on?



DFor the list of boxes that are officially and formally supported by =OpenVMS Engineering, please see the OpenVMS Software Product Description (SPD).



ESometimes 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. BAlternatively, somebody (usually one or more engineers within the EOpenVMS 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.

DContrary to the assumptions of some folks, there are platform-level Bdifferences even within the VAX and within the Alpha platforms--- Fhardware-level differences that can require moderate to extensive new Bcoding 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.

ADSR is a mechanism by which OpenVMS can gather platform-specific Ginformation, and DSR is the reason why newer Alpha systems can be more Heasily and more commonly supported on older OpenVMS Alpha releases. DSR His implemented with OpenVMS Alpha code, with SRM console code, and with platform non-volatile memory.

DOpenVMS users with experience on older OpenVMS VAX releases and VAX Bhardware will recall that then-new VAX systems either required an COpenVMS VAX upgrade, or that earlier releases would mis-identified Dthen-newer VAX systems---such as the case of the VAX 7000 model 800 Cbeing (mis)identified as a VAX 7000 model 600 when bootstrapped on COpenVMS VAX V5.5-2. (This (mis)identification was the outcome of a Bdeliberate engineering effort to permit the VAX 7000 model 800 to Ebootstrap on V5.5-2; the system manager could configure the VAX 7000 Gmodel 800 to (mis)identify itself as a model 600, to permit the system Hto bootstrap on V5.5-2.) OpenVMS VAX and VAX platforms lack DSR support.

OpenVMS I64i(please see Section 14.4.5 for Intel Itanium terminology) supports a Cplatform-level feature similar to the OpenVMS Alpha DSR mechanism, based on theA ACPI interface and the byte-code interpreter implemented within G OpenVMS, within the EFI console, and particularly within non-volatile G memory located on (byte-code interpreter compliant) PCI I/O hardware. F ACPI tables provide the information that was formerly retrieved from I DSR and from the SRM, and the byte-code interpreter can (theoretically) C permit at least limited operations with (compliant) PCI hardware, A whether or not OpenVMS has a driver for the particular hardware.

DThe byte code interpreter may or may not permit operations with any Hparticular PCI hardware, and may or may not have sufficient performance Dfor local requirements, and PCI hardware may or may not include the Fnecessary ROM-based drivers in the PCI hardware non-volatile storage. D(The intent of this Intel platform-level effort is to move the host Gsoftware drivers out onto the specific PCI hardware, and to permit the Gsame byte code to operate regardless of the particular host platform.) DAt least the initial releases of OpenVMS I64 will not have Fsupport for the byte code interpreter nor for arbitrary PCI or system Ehardware, but will have support for ACPI-based system identification and system configuration.




 r Y \ ^  
PreviousNextContentsIndex