Re: SparcStation 4 serial console

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [...speculation...questions...]
> the SS4 and SS20 both have on-board video,

You've got a cg14?  Nice!  (What does the SS4 have onboard?  It's been
too long since I worked with one.)

> the SS10 has a card in it.  All 3 have no video, no keyboard
> connected.  Shouldn't serial console be fall-back when no keyboard is
> detected?

Yes, in general the ROMs will fall back to serial console when no
keyboard is present.  (The kernel uses the ROM's console spec in my
experience, but, even if that's changed in the versions you're using,
you should get serial console for OBP at least.)

> On my SS20 I see:
> output-device=screen
> input-device=keyboard

> I have the same on my SS4.

Okay, so that's not it.

What do they have diag-switch? set to?  I think if diag-switch? is set
true then OBP will talk to ttyb regardless of the ordinary console
setting, so if you're using the B connector on your Y cable and the '10
and '20 have diag-switch? set true but the '4 doesn't that might have
some relevance.

Also, what are ttya-mode and ttyb-mode?  In general, the wrong baud
rate just produces baud barf.  But, if the mismatch is extreme enough,
you can get nothing but 0x00 or 0xff octets, which might look like no
output.

Another possibility is that the serial output driver on the '4 is
fried.  If you boot it and write to the serial ports from NetBSD, do
you get any output?

> I tried setting input and output  device both to ttya, but no avail.
> I end up with a black screen if I attach a monitor... so the
> parameters do something, but not what I expect.. seems like serial is
> somehow dead/different.

That sounds like what I'd expect if the output driver is dead: no video
init but still no output.  Try using ttyb instead (and the other arm of
the Y cable), maybe?  If the output driver is dead, it's moderately
likely the other port is fine.

> Luckily I still have the 113W3 cable, even if the LCD Monitor doesn't
> properly sync the size like the old CRTs, so the last line is
> missing... but enough to test and boot.

Yes, that's one of my beefs with flatscreens.

In the old days, the computer chose the video output signal parameters
and the monitor had to adapt (or, if it couldn't, at least indicate
that fact somehow, such as by displaying a synthetic "input out of
range" screen).  Now, the monitor declares (via EDID, I think the name
is) what video signals it can handle, and the computer is expected to
generate one of them.

This, of course, produces interoperability fails in both directions.
(While it is not, strictly, connected to the switch to flatscreens, it
happened at about the same time; in my experience, the correlation "CRT
can autosync; flatscreen can't" is extremely strong.)

Of particular relevance now, old video hardware such as the cg6 and
cg14 have a very limited list of video modes they can run in.  (The
cg14 is capable of more than the ROM-provided modes, but it's still
fairly restricted as compared to the peecee video that the modern
"monitor dictates the video parameters" model seems to be expecting.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B