Greetings and Conflagrations!


>der mouse chirped:

>>>>> putting good 4Mx36 sticks on either side of it will usually
>>>> 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.  [...] As long as both the lowest and highest
>>> ones are good, the POST seems to be happy.
>> Hmmm... another blivet in the FAQ?  IIRC, it claimed the sockets had
>> to be filled "in order"...
>
>That certainly is not the case with the one IPX I am in a position to
>easily test with.  It has 24M, 2x4+1x16, and I put the 4 in 0 and 1,
>the 16 in 3, and left 2 empty - and the POST found all 24M.  (Which
>incidentally also knocks on the head the "largest devices in lowest
>slots" theory for at least this one IPX.)


Dunno.  I just did whatever research I could before firing
them up.  And, naively followed the notes mentioned there.
Perhaps I will "play" with a machine later to see what
The Real Story is...

>>> 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...
>
>This turns out to have been flaky memory on my part.  The diag-mode


Ah, you undoubtedly need to add *PARITY*!  :>

>printout shows the whole thing.  It's when it passes the memory regions
>to the kernel that it snips out a fragment....


That would make sense.

>> As an aside, is there any dmesg(8) sort of way of getting at the prom
>> monitor's signon banner?
>
>Not AFAIK.


Bummer.  I woul dreally like to stop depending on this
damn monitor!  Too bulky to be lugging it in and out
of storage each time I need to talk to the rom monitor...

>>> (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 (!)
>
>I could see a justification, perhaps, for a minimal mini-monitor that
>could run just out of CPU registers (especially on the SPARC, which
>typically has hundreds - though not all accessible at once, for a
>mini-monitor which doesn't need to handle exceptions or interrupts it
>could be faked).


This is what I put in products -- primarily as a diagnostic tool
to let me figure out what's going on without dragging out a
logic analyzer or emulator.  So, when I first saw a "monitor"
in the SPARCs (remember, this is relatively new for me!), I
was tickled!

Then, disappointed when I realized the emphasis was not the same
as I had expected -- i.e. when I couldn't use it to tell me that
bank 0 DRAM was bad!

<shrug>  Someplace I have documentation on it.  I guess I should
make a point of reading it...

--don