[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: VAX RPB (Restart Parameter Block)
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
> 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
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
The funny thing is again, that nowhere is to read where that Scratch Memory
Area is located.
One can read this:
188.8.131.52 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
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
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
> The XDELTA manual is at
> Hope this helps,
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
Is there a data structure that possibly contains the location of that CMBX
Cell at programm start?
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
Main Index |
Thread Index |