Re: VAX RPB (Restart Parameter Block)

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

Holm Tiffe wrote:

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

I think I have found the Reference where the CPMBX Cell is located.
If I boot the primary loader with the bit 9 in the flag set to one (halt
after loading) I can examine the register contents:

>>> b/200 eza0

 83 BOOT SYS


-EZA0

2..1..0..
?06 HLT INST
    PC = 20042EB9
>>> e/n:f r0

  G 00000000  20042F75
  G 00000001  00FFEA00
  G 00000002  00001000
  G 00000003  00FFBA00
  G 00000004  00000000
  G 00000005  00000200
  G 00000006  00000002
  G 00000007  80116592
  G 00000008  00000800
  G 00000009  00001800
  G 0000000A  00001800
  G 0000000B  00000000
  G 0000000C  00000200
  G 0000000D  003EFFA0
  G 0000000E  00001800
  G 0000000F  20042EB9

and in R1 and R3 are courious looking values.
Checking the address to that r1 is pointing gives those results:
>>> e ffea00

?22 ILL REF
>>> 

with the unprotect switch I get this:
>>> sh halt
3
>>> e/u ffea00

  P 00FFEA00  001001F3
>>> set halt 0

>>> e/u ffea00

  P 00FFEA00  001001C0
>>> set halt 1

>>> e/u ffea00

  P 00FFEA00  001001D1
>>> set halt 2

>>> e/u ffea00

  P 00FFEA00  001001E2
>>> set halt 3

>>> e/u ffea00

  P 00FFEA00  001001F3

Which is showing the change of the HLT_SWX and HLT_ACT Flags above.
>>> sh mem
        01000000         
        00000000         
        00FFA600:00FFFFFF

>>>

..displays the memory, but I don't know what this means at all.
Maybe the area between 00ffa600 up to 00ffffff is that bad marked area?
The 01000000 seems to be the 16 megabytes of installed RAM (End Address?)
0 the Starting Address?

The bad marked are seems to be in the middle of the available Memory area,
is there a way to map out those pages from NetBSDs use to preserve it's
contents?

The Address ffea01 contains a 01 which is indicating the presence of an SLU
regarding the Manual. Mouse this may be the address to which the r11 in the
console code should point to:

; Send the char in r2 out console A.
   cons_A_TX: blbc    1001(r11),0x20044f32
    20044f23: bbc     $2,*$20100004,0x20044f23 ; console A status, bit
TX_RDY
    20044f2b: movl    r2,*$2010000c ; console A transmit data
    20044f32: movzbl  $1,r0
    20044f35: rsb     
; Send the char in r0 out console A.  Ignores 1001(r11) disable bit.
cons_A_TX_always: blbc    1001(r11),0x20044f4a
    20044f3b: bbc     $2,*$20100004,0x20044f3b ; console A status, bit
TX_RDY
    20044f43: movl    r0,*$2010000c ; console A transmit data
    20044f4a: rsb     

What does this blbc instruction?

Regards,

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