>Geoff Adams cried out:

>>>> 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...
>
>There's no need for that...  :)
>
>The PROM can also speak to a serial console.  

Yes.  Though accessing it while NBSD is up and running is
problematic  :>  I guess I *could* ESCape to the monitor and then
"go" resume... but the idea of "pausing" the system like that
gives me the willies -- something is *boud* to go wrong!  :>

>Indeed, this is how I run all of my Suns.  (I do my X stuff on an
>SGI.  Previously, I had a couple Suns I used graphical consoles on.)

I use NCD's for most "terminals".  Less noise to conted with (fans,
disks, etc.).  Though I saw a "personal Indy" (or somesuch)
last week (funky purplish box?) that looked inviting...

>On most versions of the PROM, if you simple unplug the keyboard and plug a
>terminal into serial port A (9600 baud, 8N1), you'll see a message saying
>"Keyboard not present.  Using ttya for input and output."  

[snip]

Yes.  Been there, done that.  I have an NCD close by each SPARC
so they are the logical choices to act as serial consoles (they
have a serial port on back and you can call up a terminal
emulation via a hotkey).  A small bootstrap issue, though,
since the SPARCs are responsible for supplying the boot images
to the NCD's -- and the NCD's can't go into termnal emulation
without those boot images!  :>

There are two problems (IMO) that I have to sort out -- if possible.

One is the fact that powering off the terminal invokes thje
rom monitor (similar to STOP A?).  Obviously, I don't want 
to have to leave the terminal on 24/7 (the SPARCs run 24/7
so I can boot an NCD any time I turn an NCD on!).  And I
don't want to have to fiddle with cables, etc.  I will
explore the various "ignore-*" settings in the rom monitor
to see if any of those will solve the problem.  If not, see
if I can bias the signals in the serial cable to assume
"safe" levels when disconnected... (?)

The second problem has to do with ttys(5) and trying to support
a serial port console *and* a keyboard/framebuffer console
"automatically" (i.e. whichever is present should be the
console and the tty should be useable as a regular tty if
the keyboard is present...)  I posted a message about this
just a while ago...  there doesn't seem to be a way to trick the
system into doing this.  I suspect it is because the rom
monitor itself is present *in* the executing memory image
while NetBSD is running ?  This would explain lots of
other obserations (like why the front panel LED only blinks
if you have certain versions of frimware installed...)

>(You may find yourself blindly typing these using a Sun keyboard, with no
>monitor attached, followed by a "reset" command.  I've done that a couple
>times...  :)  Note that you can use ttyb, too, if you like.  Type "help
>system" for more information.


Hmmm... I assume using ttyb just "moves" the problems I mentioned
over to that tty, instead?  I.e. as if you had just changed the labels
on the connectors?

>Also, I don't think this was mentioned previously:  The diag output der
>Mouse and I were talking about only dumps out to the serial console, as I


Ah!

>recall.  (Although this may be PROM-version-dependant.)  Basically, you
>really ought to have a dumb terminal in your machine room.  :)


Yes, as I mentioned, I already have that -- in a fashion.
Just getting it to work *nicely* that's the problem...  :-(

Thx,
--don