AlphaStation 200 NVRAM Problem

[Robert Jarratt]

> -----Original Message-----
> From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Maciej
> W. Rozycki
> Sent: 26 April 2016 21:02
> To: General Discussion: On-Topic Posts <cctech at classiccmp.org>
> Subject: RE: AlphaStation 200 NVRAM Problem
> 
> On Tue, 26 Apr 2016, Robert Jarratt wrote:
> 
> > >  One possibility is SRM unmaps them when it takes over from SROM,
> > > for safety maybe -- so as not to let one corrupt flash by accident
> > > easily
> > (BTW, I do
> > > recommend write-protecting flash with its jumper for these
> > > experiments -- with DROM not working correctly and hence no way to
> > > load SRM from a floppy you'd be doomed if flash broke too).  The
> > > symptoms should look like ones you've got, though of course plain
> > > poking at the wrong area would
> > look
> > > the same.
> >
> >
> > I will check for unmapping, but I get a machine check when I write
> > code running in OpenVMS that attempts to write to the same physical
> location.
> > This assumes my code is correct of course, which is what I was trying
> > to verify by using the console.
> 
>  Well, the symptoms appear consistent then (I thought in OpenVMS you got
> a freeze), so I suspect my guess about unmapping is right.
> 
> > This makes me wonder if the problem is that the DROM is getting the
> > same errors. But I am not sure if that can be true because then the
> > DROM would not be able to write to the diagnostic LEDs either (and the
> > SROM wouldn't be able to load the DROM, presumably).
> 
>  Correct -- if you do get a machine check as early as accessing the index
> register, then it looks like the glue logic for flashbus doesn't respond
to a
> write cycle (there's no decoding enabled for the address requested) and
you
> get a bus timeout/abort.  Given that at this point you are only about to
select
> a particular device on flashbus it would equally happen for any, including
the
> LEDs.  Unless there is a timing requirement for the data register to see
an
> access soon enough after an index write or a bus error happens -- which I
> highly doubt given the crudeness of the logic (i.e. even the read/write
signal
> is explicit rather than decoded from the data register access bus cycle).
> 
> > >  You could check if flashbus is mapped by peeking at bank 8 memory
> > > controller registers and seeing if the contents provide the
> > > necessary
> > wiring
> > > (in particular if bit #0 aka `s8_Valid' in the 16-bit word at
> > > 0x180000b00 is 1).  These registers are listed in the same manual --
> > > with
> > a
> > > further reference to the (rather fat) memory controller manual.  If
> > > not,
> > then
> > > you'd have to set them yourself.  There could be PALcode entry
> > > points to access flashbus too I suppose, although regrettably my
> > > Alpha-fu is not so deep as to know this offhand.
> >
> >
> > I need to understand more about the Alpha architecture to understand
> > this, but I will check. All I can say is that I did try to read the
> > bank 8 base address register and I did get a value, but I didn't
> > undertand what it meant. Will do some reading.
> 
>  OK, just shout if you find yourself lost.
> 


I just got some very interesting results.

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.

So I booted VMS and modified my code to read the same locations.  Pleasingly
the code read back the same values. Which I hope means my code is correct.

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.

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

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

Regards

Rob