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