> -----Original Message----- > From: Maciej W. Rozycki [mailto:[email protected]] > Sent: 01 August 2017 19:38 > To: [email protected] > Cc: 'General Discussion: On-Topic and Off-Topic Posts' > <[email protected]> > 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
