| Previous | \Contents | ^Index |
F The following flags are passed (via register R5) to the OpenVMS Alpha D primary bootstrap image APB.EXE. These flags control the particular behaviour of the bootstrap:
|
" BOOT -FL root,flags |
|
" bit description : --- ---------------------------------------------- . 0 CONV Conversational bootstrap 4 1 DEBUG Load SYSTEM_DEBUG.EXE (XDELTA) Q 2 INIBPT Stop at initial system breakpoints if bit 1 set (EXEC_INIT) ? 3 DIAG Diagnostic bootstrap (loads diagboot.exe) E 4 BOOBPT Stop at bootstrap breakpoints (APB and Sysboot) G 5 NOHEADER Secondary bootstrap does not have an image header ) 6 NOTEST Inhibit memory test 9 7 SOLICIT Prompt for secondary bootstrap file A 8 HALT Halt before transfer to secondary bootstrap * 9 SHADOW Boot from shadow set ( 10 ISL LAD/LAST bootstrap 2 11 PALCHECK Disable PAL rev check halt B 12 DEBUG_BOOT Transfer to intermediate primary bootstrap , 13 CRDFAIL Mark CRD pages bad B 14 ALIGN_FAULTS Report unaligned data traps in bootstrap A 15 REM_DEBUG Allow remote high-level language debugger A 16 DBG_INIT Enable verbose boot messages in EXEC_INIT N 17 USER_MSGS Enable subset of verbose boot messages (user messages) 1 18 RSM Boot is controlled by RSM 4 19 FOREIGN Boot involves a foreign disk |
F If you want to set the boot flags "permanently" use the SET BOOT_FLAGS command, e.g.
|
" " >>> SET BOOT_OSFLAGS 0,1 |
D The following flags are passed (via register R5) to the OpenVMS VAX D primary bootstrap image VMB.EXE. These flags control the particular behaviour of the bootstrap:
F The exact syntax is console-specific, recent VAX consoles tend to use the following:
|
" >>> BOOT/R5:flags @ Bit Meaning @ --- ------- N @ 0 RPB$V_CONV @ Conversational boot. At various points in the @ system boot procedure, the bootstrap code @ solicits parameter and other input from the @ console terminal. If the DIAG is also on then @ the diagnostic supervisor should enter "MENU" @ mode and prompt user for the devices to test. @ 1 RPB$V_DEBUG @ Debug. If this flag is set, VMS maps the code @ for the XDELTA debugger into the system page @ tables of the running system. @ @ 2 RPB$V_INIBPT @ Initial breakpoint. If RPB$V_DEBUG is set, VMS @ executes a BPT instruction immediately after @ enabling mapping. ? @ 3 RPB$V_BBLOCK @ Secondary boot from the boot block. Secondary @ bootstrap is a single 512-byte block, whose LBN @ is specified in R4. @ @ 4 RPB$V_DIAG @ Diagnostic boot. Secondary bootstrap is image @ called [SYSMAINT]DIAGBOOT.EXE. @ @ 5 RPB$V_BOOBPT @ Bootstrap breakpoint. Stops the primary and @ secondary bootstraps with a breakpoint @ instruction before testing memory. @ 6 RPB$V_HEADER @ Image header. Takes the transfer address of the @ secondary bootstrap image from that file's @ image header. If RPB$V_HEADER is not set, @ transfers control to the first byte of the @ secondary boot file. @ @ 7 RPB$V_NOTEST @ Memory test inhibit. Sets a bit in the PFN bit @ map for each page of memory present. Does not @ test the memory. @ @ 8 RPB$V_SOLICT @ File name. VMB prompts for the name of a @ secondary bootstrap file. @ @ 9 RPB$V_HALT @ Halt before transfer. Executes a HALT @ instruction before transferring control @ to the secondary bootstrap. @ @ 10 RPB$V_NOPFND @ No PFN deletion (not implemented; intended to @ tell VMB not to read a file from the boot device @ that identifies bad or reserved memory pages, @ so that VMB does not mark these pages as valid @ in the PFN bitmap). @ @ 11 RPB$V_MPM @ Specifies that multi-port memory is to be used @ for the total EXEC memory requirement. No local @ memory is to be used. This is for tightly-coupled @ multi-processing. If the DIAG is also on, then @ the diagnostic supervisor enters "AUTOTEST" mode. @ @ 12 RPB$V_USEMPM @ Specifies that multi-port memory should be used in @ addition to local memory, as though both were one @ single pool of pages. @ @ 13 RPB$V_MEMTEST @ Specifies that a more extensive algorithm be used @ when testing main memory for hardware @ uncorrectable (RDS) errors. @ @ 14 RPB$V_FINDMEM @ Requests use of MA780 memory if MS780 is @ insufficient for booting. Used for 11/782 @ installations. @ F <31:28> RPB$V_TOPSYS @ Specifies the top level directory number for @ system disks with multiple systems. |
H The AlphaStation series will boot without a keyboard attached. To use a B serial terminal as the console, issue the SRM console command SET C CONSOLE SERIAL followed by the console INIT command. Once this SRM G command sequence has been invoked and the CONSOLE environment variable F is set to SERIAL, the Alpha system will use the serial terminal. (Set C the environment variable to GRAPHICS to select the console display ! output via the graphics display.)
F The DEC 3000 series has a jumper on the motherboard for this purpose. D Various older Alpha workstations generally will not (automatically) E bootstrap without a keyboard connected, due to the self-test failure 3 that arises when the (missing) keyboard test fails.
C 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). |
H AlphaServer 4100 and derivative series platforms, and AlphaServer GS80, G GS160, and GS320 series system consoles are capable of 57600 baud. See E the COM2_BAUD console environment variable, and ensure that you have $ current SRM firmware version loaded.
G The AlphaStation and AlphaServer series use a PC-compatible DB9 serial connector for the COM1 and COM2 F serial lines (and for the OPA0: console line, if that was configured a via SRM), please see Section 14.27 for details and pin-out.
F For information on registering software license product authorization K keys (PAKs), please see Section 5.6.2.
j For a related behaviour of DECwindows, please see Section 11.10. For G information on the VAXstation alternate console mechanisms, please see 5 Section 14.3.3.3. T 14.3.7 Downloading and using SRM console Firmware?
E This 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?
9 Firmware updates for HP Alpha systems are available from:
@ The latest and greatest firmware---if updated firmware has been H released after the most recent firmware CD was distributed---is located at:
C For information on creating Alpha bootable floppies containing the @ firmware, and for related tools, please see the following areas:
H The SROM firmware loader expects an ODS-2 formatted floppy, see mkboot. D As for which image to use, the ROM image uses a header and the file F extension .ROM, and the SROM bootable floppy cannot use the .ROM file.
F 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 |
n Also see Section 14.3.7.2. For information on HP Integrity EFI firmware I upgrades, please see Section 14.3.10. b 14.3.7.2 How do I reload SRM firmware on a half-flash Alpha system?
C Some of the AlphaStation series systems are "half-flash" B boxes, meaning only one set of firmware (SRM or AlphaBIOS) can be A loaded in flash at a time. Getting back to the SRM firmware when ; AlphaBIOS (or ARC) is loaded can be a little interesting...
H 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.
H To shuffle the files, copy the target SRM firmware file (as200_v7_0.exe A is current) to a blank, initialized, FAT-format floppy under the filename A:\FWUPDATE.EXE
F From the AlphaBIOS Setup screen, select the Upgrade AlphaBIOS option. 3 Once the firmware update utility gets going, enter:
|
" Apu-> update srm 1 Answer "y" to the "Are you ready...?" Apu-> quit |
A 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?
G The specific steps required vary by system. You must first ensure that H the particular Alpha system is supported by OpenVMS (see the SPD), that H all core I/O components (graphics, disk controllers, etc) in the system E are supported by OpenVMS (see the SPD), and that you have an OpenVMS H distribution, that you have the necessary license keys (PAKs), and that + you have the necessary SRM firmware loaded.
G A typical sequence used for switching over from the AlphaBIOS graphics # console to the SRM console follows:
F Most Alpha systems support loading both the AlphaBIOS/ARC console and G the 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 |
F Use the following sequence to specifically update (and load) SRM from 1 AlphaBIOS/ARC on a "half-flash" system:
|
" Apu-> update SRM Apu-> verify Apu-> quit Power-cycle the system |
A Use the following sequence to specifically update (and load) the B 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 |
H 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 E operating system(s) to write a "harmless" signature to any F disk used by OpenVMS Alpha or OpenVMS VAX, as this will clobber a key A part of the disk; this will overwrite the OpenVMS bootblock. (On C OpenVMS Alpha and OpenVMS VAX, you can generally recover from this F so-called "harmless" action by using the WRITEBOOT.EXE tool.
? Using OpenVMS I64 and the EFI console, the bootblock structures H are expected to be compatible with those of Microsoft Windows and other B 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.)
G If you have a "full-flash" system and want to select the SRM B console 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 G 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.
f 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.
C Information on enabling and using the failsafe firmware loader for E various systems---this tool is available only on some of the various E Alpha platforms---is available in the hardware documentation for the G system. This tool is used/needed when the firmware has been corrupted, and cannot load new firmware.
F The full list of AlphaBIOS key sequences---these sequences are needed H when using an LK-series keyboard with AlphaBIOS, as AlphaBIOS expects a PC-style keyboard:
|
" F1 Ctrl/A F2 Ctrl/B F3 Ctrl/C F4 Ctrl/D F5 Ctrl/E F6 Ctrl/F F7 Ctrl/P F8 Ctrl/R F9 Ctrl/T F10 Ctrl/U Insert Ctrl/V Delete Ctrl/W Backspace Ctrl/H Escape Ctrl/[ Return Ctrl/M LineFeed Ctrl/J & (Plus) + upselect (some systems) ( (Minus) - downselect (some systems) TAB down arrow SHIFT+TAB up arrow |
> Options to collect multiple consoles into a single server are E available, with both hardware options and software packages that can + provide advanced features and capabilities.
= Some of the available console management options for OpenVMS:
? Computer Associates is the owner of what was once known as the D VAXcluster 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?
G OpenVMS I64 boot aliases contain signature information referencing the C specific volume, meaning that the entries are specific to the disk = volume and not the disk device. This also means that certain 9 operations, such as the SET BOOTBLOCK command or the RUN SYS$SETBOOT.EXE operation G that can rewrite these volume signatures (signature or GUID values) can & render existing boot aliases unusable.
E If your boot aliases do not function as expected, first try removing F and re-adding them; this will resynchronize the boot aliases with the B volume contents. If you are using the SET BOOTBLOCK command or the E RUN SYS$SETBOOT.EXE operation to rewrite the disk bootblock, you can D request that the current signatures (if any) be preserved, and this F will typically maintain the validity of your EFI console boot aliases. P 14.3.10 Downloading and using EFI Console Firmware?
D HP Integrity EFI system firmware can be downloaded in the form of a E bootable image master, unzipped and then burned onto CD or DVD media f (please see Section 9.7 for details of recording optical media on F OpenVMS), and the system can then generally be booted off the created * media to perform the EFI firmware upgrade.
F The HP Integrity Server website is accesssable via the following URL, F and the available services and support information there has links to D the available platform-specific firmware images and upgrade-related materials:
C For information on Alpha SRM console firmware upgrades, please see 8 Section 14.3.7. m 14.4 What platforms will OpenVMS operate on?
D For the list of boxes that are officially and formally supported by = OpenVMS Engineering, please see the OpenVMS Software Product Description (SPD).
E 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. B Alternatively, somebody (usually one or more engineers within the E 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.
D Contrary to the assumptions of some folks, there are platform-level B differences even within the VAX and within the Alpha platforms--- F hardware-level differences that can require moderate to extensive new B 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.
A DSR is a mechanism by which OpenVMS can gather platform-specific G information, and DSR is the reason why newer Alpha systems can be more H easily and more commonly supported on older OpenVMS Alpha releases. DSR H is implemented with OpenVMS Alpha code, with SRM console code, and with platform non-volatile memory.
D OpenVMS users with experience on older OpenVMS VAX releases and VAX B hardware will recall that then-new VAX systems either required an C OpenVMS VAX upgrade, or that earlier releases would mis-identified D then-newer VAX systems---such as the case of the VAX 7000 model 800 C being (mis)identified as a VAX 7000 model 600 when bootstrapped on C OpenVMS VAX V5.5-2. (This (mis)identification was the outcome of a B deliberate engineering effort to permit the VAX 7000 model 800 to E bootstrap on V5.5-2; the system manager could configure the VAX 7000 G model 800 to (mis)identify itself as a model 600, to permit the system H to bootstrap on V5.5-2.) OpenVMS VAX and VAX platforms lack DSR support.
OpenVMS I64 i (please see Section 14.4.5 for Intel Itanium terminology) supports a C platform-level feature similar to the OpenVMS Alpha DSR mechanism, based on the A 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.
D The byte code interpreter may or may not permit operations with any H particular PCI hardware, and may or may not have sufficient performance D for local requirements, and PCI hardware may or may not include the F necessary ROM-based drivers in the PCI hardware non-volatile storage. D (The intent of this Intel platform-level effort is to move the host G software drivers out onto the specific PCI hardware, and to permit the G same byte code to operate regardless of the particular host platform.) D At least the initial releases of OpenVMS I64 will not have F support for the byte code interpreter nor for arbitrary PCI or system E hardware, but will have support for ACPI-based system identification and system configuration.
| Previous | YNext | \Contents | ^Index |