>>> der mouse shrieked:
>
>Hmm, that's not the verb _I_'d use :-)


Yeah, I thought of "squealed" after I had typed it... :>

>>> Yes, it is.  I've used this mode as a memory sizing tool - when I
>>> have a 72-pin stick of unknown size and width, I set diag-switch?
>>> true, pop it in, and watch the messages.
>> Oh.  I find it easier to just check the P/N's of the components on
>> the SIMM.  :>
>
>If I had suitable reference material to do likewise, I might find that
>easier myself. :-)


Ah.  One of the aspects of my "day job"  :>  Somehow can't get used to
the idea of consulting CD-ROM versions of the databooks, though.
So, lots of shelf space "wasted" with the damn things...  :-(

>>> putting good 4Mx36 sticks on either side of it will usually
>> Ah, that's worth knowing.  I.e. put the suspect SIMM in slot 1 and
>> populate slots 0 and 2 with 4M devices?
>
>Or 0 and 3, in which case you can try out two suspect sticks at the
>same time, in 1 and 2.  (Not 1 and 3 with the suspect in 2; IIRC I
>found that you _must_ have something in socket 0.)  As long as both the
>lowest and highest ones are good, the POST seems to be happy.  I


Hmmm... another blivet in the FAQ?  IIRC, it claimed the sockets
had to be filled "in order"...

>speculate that it uses very low physical addresses early on (thus the
>requirement for RAM in socket 0), and reserves some memory for its own
>purposes at the top of available RAM after sizing.  If you look at the
>addresses printed for the RAM regions when diag-switch? is true, you'll
>see that the highest nonempty socket appears to end something like
>0x2000 before it actually does.


I will try to recall checking this next time I have a monitor
attached to a box...

As an aside, is there any dmesg(8) sort of way of getting at the
prom monitor's signon banner?  I.e. to inspect the host id,
serial number, rom version, etc. from *within* NBSD?  It's
annoying to have to drag out a monitor just to see what version
ROM is in the box (though I suspect this doesn't warrant any
development effort!)  I am (slowly) learning to jot these
sorts of things down on an adhesive label affixed to the
underside of each case!

>> Isn't there any sort of rule regarding "largest devices in lowest
>> slots"?
>
>On the ELC (and I think the IPX as well, though I'm less certain) I
>haven't seen any such.  The sockets are 16M apart and each stick
>occupies either the whole of that 16M or the low 4M of it, depending on
>whether it's a 16M or 4M part.  If you put a 4M part other than last,
>this just means physical memory is noncontiguous.  I have a SIMM

OK.

>"adapter" which has four 30-pin SIMM sockets and plugs into a 72-pin
>SIMM socket; if I populate only some of the 30-pin sockets, the RAM
>fails POST (of course) - but I hacked on the SPARC /dev/mem driver to
>permit access to any <64M address even if it wasn't in the memory map
>and found that upon booting (with enough good RAM to run in, of course)
>and poking at the partially-populated adapter's space, some of the
>bytes worked and some didn't - in byte terms, the low two address bits
>select which 30-pin SIMM is used, though I daresay the underlying
>memory path is 32 bits wide with each small SIMM supplying 8 of those
>bits.  With some sockets empty, some of the bytes just didn't work.  (I
>forget whether they always read as 00, always read as ff, or what - I
>have a hazy memory of there being a case where a value recently written
>sometimes affects a value read, but only very soon after; etch run
>capacitance, maybe?)


This sort of phenomenon is typical of lightly (DC) loaded busses.
Not enough leakage current to pull the signals high fast enough,
etc.  Of course, with more and more CMOS technology, heavier
*AC* loaded busses will also tend to "linger" due to the
capacitive loading.

>>> reducing the failure mode to an error from the memory selftest.
>> Sure would be nice to know the fancy "light flash" codes on the
>> keyboard!  Had some bad 4M SIMMs in an LX (?) and couldn't even get
>> the banner/logo to appear!  :-(  But, could see that something was
>> obviously running by the patterns on the keyboard LEDs
>
>Ah, I don't know anything about that.  All my playing was done with
>serial console.  (I think diag-mode? true produces output on the serial
>port much earlier than it produces anything on the framebuffer, which
>is hardly surprising as the FORTH engine has to be up to initialize
>many framebuffers.)


This seems to be a flaw in the design.  IMHO, rom monitors
should be able to operate in the absence of memory (!)  Of course,
the OFW monitor is a bit bloated and undoubtedly *requires*
a fair amount of RAM just to wake up.  Catch-22...

It is, however, obvious that the developers *tried* to convey
some status information to the user/technician even without
the FB being operational.  The LED patterns can't be coincidental.
Of course, getting access to that nformation is probably more work
than it is worth!

Suffice it to say, however, that it is worth watching the keyboard
on a box that *appears* dead since any (repeatable) activity
there can be a clue that the box isn't *completely* dead.  As
you have suggested, it could just mean "bank 0 not working".

--don