Reset NVRAM on DECstation 5000/240

Rob Jarratt robert.jarratt at ntlworld.com
Tue Aug 1 16:20:13 CDT 2017



> -----Original Message-----
> From: Maciej W. Rozycki [mailto:macro at linux-mips.org]
> Sent: 01 August 2017 19:38
> To: rob at jarratt.me.uk
> Cc: 'General Discussion: On-Topic and Off-Topic Posts'
> <cctalk at classiccmp.org>
> Subject: RE: Reset NVRAM on DECstation 5000/240
> 
> On Mon, 31 Jul 2017, Rob Jarratt wrote:
> 
> > >  It is.  Check the "DECstation/DECsystem 5000 Model 200 Series
> > > Maintenance Guide" (EK-PM38C-MG-002), available online.
> > >
> >
> > I have that manual. Having checked again I realise I should have
> > searched for "NVR" and not "NVRAM", then I would have found it!!
> 
>  Or "jumper" would do too, ;) avoiding DEC documentation peculiarities
(they
> indeed call the Dallas chip "NVR", reserving "NVRAM" for the MS02-NV
> Prestoserve SRAM memory board).


Indeed, I actually discovered it was called NVR by searching for "jumper".
That was so obvious I don't know why I didn't search for that in the first
place!!


> 
> > >  Technically it's wired to one of the 16 IOASIC external interrupt
> > > inputs,
> > which is
> > > otherwise unused.  Functionally it tells software whether the
> > > mainboard is
> > used
> > > in a 5000 or a 5900 system configuration.  I can dig out the exact
> > > details
> > if
> > > you're interested.
> >
> >
> > That would be interesting, if there is documentation that isn't
> > generally available it would be good to see it.
> 
>  Not everything has been properly documented, I've gathered information
from
> various sources, including reverse engineering.  The bigmax IOASIC IRQ bit
is I
> recall only mentioned in an Ultrix error log processing utility, though
the
> jumper itself is I believe mentioned in one of the
> 5900 manuals, available online.
> 
>  Over the years I've gathered available information in Linux kernel
headers; for
> the KN03 mainboard specifically:
> 
> <https://git.linux-
> mips.org/cgit/ralf/linux.git/tree/arch/mips/include/asm/dec/kn03.h>
> 
> Interpreted along with:
> 
> <https://git.linux-
>
mips.org/cgit/ralf/linux.git/tree/arch/mips/include/asm/dec/ioasic_addrs.h>
> 
> and knowing that in the console you need to use the MIPS KSEG1 uncached
> address space you get:
> 
> KSEG1 | (KN03_SLOT_BASE + IOASIC_IOCTL + IO_REG_SIR)
> 
> which expands to:
> 
> 0xa0000000 | (0x1f800000 + 1 * 0x00040000 + 0x110) => 0xbf840110
> 
> so to get at the interesting bits:
> 
> >>e -wx 0xbf840110
> bf840110: 0x00008802
> >>
> 
> i.e. the bigmax bit is set as for the 5000/240 (jumper present), the NVR
clear
> bit is clear (jumper absent), and the NRMOD bit is clear (jumper absent).
> There is also a TURBOchannel slot #0 option interrupt pending here for
some
> reason and the halt button is released.
> 
> > >  BTW I saw your 5000/240 web page and I'm glad that you have rescued
> > > all that fine hardware.  Also I think you don't have to worry about
> > > the H7878
> > PSU --
> > > apparently none of the caps used in that model suffers from the
> > > dreaded quaternary ammonium salt issue.
> >
> >
> > Thanks. I will create a page describing the machine in the coming
> > days, for now it will just be the blog posting. I do think there is a
> > problem with the PSU though because it will be just sitting there in
> > the console and power off, you can't turn it back on until you pull
> > out the power cord. I am going to check the caps more closely.
> 
>  Always worth doing of course, although from its arrangement the H7878
would
> be a pain do disassemble to reach some of its caps.  Also check for the
PSU
> overheating condition, reported at bit #4 in the IOASIC interrupt status
as
> examined above (with good status indicated with the bit clear).
> It may cause the PSU to eventually shut itself down.
> 
>   


Thanks for the links above and for the info on the PSU overheat. I will try
to check that when I next get the machine out. I am currently trying to fix
the DECstation 220 I have.

Regards

Rob



More information about the cctalk mailing list