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
