Re: VAX RPB (Restart Parameter Block)

[Holm Tiffe <holm%freibergnet.de@localhost>]

Kenn Humborg wrote:

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

I've already changed a small soldered in Lithium Cell, a 3,6V LTC-3PN-S2
against a socket for an CR2032, sine the original cell was empty and is
Unobtanium here in Europe.
The CR2032 has only 3V and I don't know if this is enough.
No, the entries don't persist a power-cycle, but there are 12 Dip Switches
too, thought the have something todo with the cold start behavior too..

In the Documentation the Console Mailbox is referenced, ans yes, I even
found its contents bitwise declared:

 7   6   5   4   3   2   1   0
TRG|RMT|HLT_SWX|RIP|BIP|HLT_ACT|

RIP is the Restart in Progress Flag, BIP is Bootstrap in Progress, the
HLT_SWX is the Halt Switch Field for the console action after a processor
halt what is exactly that what I wan't to know. HLT_ACT is for the Halt
Activity after the next halt

Even the Offset of 0x0 in the Scratch memory area is documented,
followinf this location comes a Byte for the Display/Console Existence, the
Boot Register, a reserved one, an SCR$A_RESTORE_CONSOLE word and an
SCR$A_SAVE_CONSOLE word.

The funny thing is again, that nowhere is to read where that Scratch Memory
Area is located.

One can read this:

4.8.1.2 System Scratch RAM
The rtVAX 300 system firmware acquires a number of pages of RAM memory at
power-on initialization. These Pages are marked "bad" in the memory bitmap
to prevent higher-level software from modifying their data
indiscriminately.
Table 4-6 lists the offsets in the scratch RAM to paramters and variables
of interrest to operating system or option ROM developers.

Maybe I can locate those cells, since Mouse dissassembled a part of the
console related routines of the ROM code and it seems to fiddle with a cell
that looks to be related to the console existence that is located in the
next byte.
I think it's quite possible that netbsd is initializing the memorya map
bits on its own and deletes all information in the bad marked area.

> 
> 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 ROM wasn't disassembled completely, we only looked for the console
driver stuff.

> 
> The XDELTA manual is at
> http://h71000.www7.hp.com/doc/83final/4540/4540pro.html.
> 
> Hope this helps,
> Kenn
> 
> 

I'll have a look at it but I don't think that it is in the ROMs.
At least the string DELTA doesn't appear in the ROM Code.


..looked at the disassembled ROM code a this moment, the Display/Console
Existence cell is only referenced trogh a pointer in R11 and I don't know
his contents..
Is there a data structure that possibly contains the location of that CMBX
Cell at programm start?

Thanks,

Holm

-- 
      Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
     Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, info%tsht.de@localhost, Fax +49 3731 74200, Mobil: 0172 8790 741