Reset NVRAM on DECstation 5000/240
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
> 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
> > > 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
> various sources, including reverse engineering. The bigmax IOASIC IRQ bit
> recall only mentioned in an Ultrix error log processing utility, though
> 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
> the KN03 mainboard specifically:
> Interpreted along with:
> 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
> 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
> 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
> be a pain do disassemble to reach some of its caps. Also check for the
> overheating condition, reported at bit #4 in the IOASIC interrupt status
> 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.
More information about the cctalk