AlphaStation 200 NVRAM Problem

[Rob Jarratt]

Brief replies as I am away for a few days now. I was able to write the LEDs ok and read the nvram. I was also able to do tests on the nvram writing all  zeroes all ones sliding zeroes and sliding ones. All tests passes. Now just need to compare my DROM with a known good one

Sent from my Windows 10 phone

From: Maciej W. Rozycki
Sent: 27 April 2016 14:47
To: General Discussion: On-Topic Posts
Subject: RE: AlphaStation 200 NVRAM Problem

On Tue, 26 Apr 2016, Robert Jarratt wrote:

> I examined the bank 8 configuration register contents using the console. It
> contained 0x0136, which suggests the cache is not valid. The base address
> register contained 0x4000.

 Both correct:

* 0x4000 << (23 - 5) => 0x100000000

* 0x0136:
  s8_Check  => 0b0    -- ECC/parity disabled 
  s8_ColSel => 0b100  -- row/column bits: 9/9
  s8_SubEna => 0b1    -- subbanks enabled
  s8_Size   => 0b1011 -- bankset size: 2MB
  s8_Valid  => 0b0    -- access disabled

Clearly the index and the data register are wired as individual subbanks 
each.

> I then went back to the console to check the bank 0 configuration register
> which gave me 0x0069, which indicates it is valid. So there is a good chance
> I am reading the right things.

 Indeed; memory controller register addresses are hardwired IIUC, so 
they're always there.  As to the bankset configuration register:

* 0x0069:
  s0_ColSel => 0b001  -- row/column bits: 12/10 or 11/11
  s0_SubEna => 0b1    -- subbanks enabled
  s0_Size   => 0b0100 -- bankset size: 64MB
  s0_Valid  => 0b1    -- access enabled

I take it it corresponds to your memory module installed.

> This I think explains why I get the machine check. While in the console I
> changed the bank 8 config register to 0x0137, and then I was able to read
> and write to the address of the flashbus index register, but it didn't
> change the LEDs when I wrote to the data register, and reading back the data
> register gave me a value I didn't write. So there is still something not

 You won't read LEDs back as it's a write-only location, a plain octal D 
flip-flop presumably.  Is it not a 74F273 that I can see right below the 
unfortunate NVRAM chip on your photo?  That would be it then.  Its outputs 
are rated 20mA each, plenty to drive LEDs without additional circuitry.

 Have you tried using your C program instead to poke at these LEDs?  SRM 
might be interfering, e.g. accessing NVRAM or maybe LEDs even between your 
commands, and consequently your data register writes issued with `deposit' 
may go elsewhere as the index register has been since changed under your 
feet.

 While experimenting with C code make sure you synchronise accesses -- 
insert `asm("mb")' or suchlike (whatever OpenVMS C compiler supports) just 
after each flashbus index or data register access and read back the index 
register before accessing the data register to avoid weak ordering effects 
in the chipsed, just as noted in the system manual.

> right, perhaps the other values in the bank 8 config register, because I
> don't know what they mean. However the base address seems correct as it's
> value is 0x4000 (the raw value in the register), and this equates to
> 0x1.000.0000 based on it being bits 19 upwards in the physical address
> space.

 Timings are documented in the chipset datasheet, though this is all 
cryptic of course as we don't know what the requirements are for flashbus.  
We could assume though that they're the same for the index and data side 
and then try to match them to the NVRAM being 70ns.  Perhaps you could 
post them too?

> I wonder if the SROM failing to read the DROM means that it does not set up
> bank 8?

 Well, but didn't it poke at LEDs?  It also tried to load DROM before 
loading SRM and PALcode from flash, both of which are on flashbus, so it 
must have got bank 8 right.  If anything it's SRM or PALcode interfering 
here probably.

  Maciej