20 Jan
2019
20 Jan
'19
1:29 p.m.
From: Paul Koning
It checks if the bits 007750 are active in the parity
CSR, if so it
takes that to be an address/ECC parity CSR.
That's odd; those are the 'error address' bits. Maybe there's an
assumption
that the sweep of memory to size it will have caused a parity error from
garbage in DRAM at startup? (If so, I wonder if it would work on a machine
with all core? :-)
It figures out the CSR to memory association by going
through memory in
1 kW increments ... This should set bad parity, and it scans all the
CSRs to see which one reports an error ... If no CSR has that set, it
concludes the particular block is no-parity memory.
Oooh, pretty clever - good workaround for rhe undefined relationship between
CSR's and memory.
If I added parity support to V6, I'd be tempted to do it with a
hand-configured table - devices are all manually configured anyway in V6, so
I'd be continuing a theme... :-)
Noel
20 Jan
20 Jan
1:45 p.m.
On Jan 20, 2019, at 4:29 PM, Noel Chiappa via cctalk
<cctalk at classiccmp.org> wrote:
No, what I meant is that it distinguishes between parity memory that reports the failing
address, vs. parity memory that only reports there is something wrong. To do that, it
tests whether those bits exist. If yes, then this is "address" type parity
memory.
paul
From: Paul Koning
It checks if the bits 007750 are active in the
parity CSR, if so it
takes that to be an address/ECC parity CSR.
That's odd; those are the 'error address' bits. Maybe there's an
assumption
that the sweep of memory to size it will have caused a parity error from
garbage in DRAM at startup? (If so, I wonder if it would work on a machine
with all core? :-)
2163
days inactive
2163
days old
1 comments
2 participants
participants (2)
-
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net