RE: VAX RPB (Restart Parameter Block)

[Kenn Humborg <kenn%linux.ie@localhost>]

> There is not that much in the Manual about this:
> 
> "4.2.1 Restart
> The restart opration searches system memory for a restart parameter block
> (RPB). Tihs data structure is construced by the VQXELN operating system or
> by the console program. If a valid RPB is found, the operating system is
> restarted at an address specified in the RPB. An internal flag indicating
> restart in progress is set to prevent repeated attempts to restart a
> failing operating system. A system restart can occur as the result of a
> processor halt."
> 
> We do have a system restart as result of a processor halt (..if I inserted
> an __asm("halt)).

The RPB isn't what you need to be looking at.  You want the CPU
to stop dead in its tracks on a HALT and drop to the console
prompt, so that you can use the console E and D commands to 
look at and modify memory.  If it's going off hunting for a 
valid RPB, then it is in the process of booting, and the state
of the machine has already been changed somewhat.

If I understand it correctly, the main design of the RPB is for
powerfail recovery.  The assumption is that main memory will
be preserved by a battery backup.  If the OS supports resuming
from powerfail, it sets up an RPB with the restart address field
pointing to the powerfail recovery code in the running OS.

On power-up, the console firmware looks for a valid RPB and jumps 
to the restart address without modifying any memory.  The OS then
has a chance to bring itself back to life.

Just before it jumps to the restart address, the firmware sets
this restart-in-progress bit somewhere.  If this bit is set on the
next restart, it doesn't jump to the RPB restart address and
performs a normal boot.  (In the KA630 and KA650, this flag
is stored in the "Console Mailbox", which is not part of RAM.
Your CPU's hardware manual might tell you where it keeps this
bit.)

You've mentioned that setting the console HALT options doesn't
seem to work.  Could it be that the non-volatile memory used for
storing it is failing, or has a dead battery?  When I rescued
a KA650-based machine, I had to replace the batteries that
powered the memory that stored the configuration data.  If you
use the SET BOOT command to change the boot device, does this
change persist across restarts/power-cycles?  Check with the 
SHOW BOOT command.

Another devious possibility might be to use the RPB mechanism...
I don't know about your firmware (I believe Mouse has disassembled
it?), but the KA650 ROM contains a full copy of an XDELTA-like
debugger.  If your ROM does too, maybe you could create a valid
RPB in RAM and point the restart address to the entrypoint of
this debugger?  

The XDELTA manual is at
http://h71000.www7.hp.com/doc/83final/4540/4540pro.html.

Hope this helps,
Kenn