14 Jun
2015
14 Jun
'15
12:05 a.m.
Folks,
I'm trying to resurrect a couple of Sparcstation 10 systems. Is there
anything 'funny' about the serial console settings on SS10 hardware? I
thought they always defaulted to 9600-n-8-1, but I get voluminous
gobbledygook at that, and at every other baud rate I've tried.
Both systems behave identically, so I can't assume SS10 settings are
wrong. And I *am* getting data, so I don't see how it can be the
cabling. Something strange about the terminal emulation mode required
maybe?
Thanks
Mike
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
14 Jun
14 Jun
12:56 a.m.
On Jun 14, 2015, at 12:05 AM, Mike Ross wrote:
I'm trying to resurrect a couple of Sparcstation
10 systems. Is there
anything 'funny' about the serial console settings on SS10 hardware? I
thought they always defaulted to 9600-n-8-1, but I get voluminous
gobbledygook at that, and at every other baud rate I've tried.
The SunOS 4 (and earlier) terminal driver sets the high bit. If you can see the OBP and
some of the early kernel messages, then it switches to junk, this is your problem. The
simplest thing to do is set your terminal emulator for "strip high bit".
ok
bear.
--
until further notice
1:02 a.m.
I can't even see the hardware messages at power-on; just garbage - on both
systems, at every baud rate I've tried on the emulator. Nowhere near
booting OS.
On Jun 14, 2015 7:56 PM, "r.stricklin" <bear at typewritten.org> wrote:
On Jun 14, 2015, at 12:05 AM, Mike Ross wrote:
I'm trying to resurrect a couple of
Sparcstation 10 systems. Is there
anything 'funny' about the serial console settings on SS10 hardware? I
thought they always defaulted to 9600-n-8-1, but I get voluminous
gobbledygook at that, and at every other baud rate I've tried.
The SunOS 4 (and earlier) terminal driver sets the high bit. If you can
see the OBP and some of the early kernel messages, then it switches to
junk, this is your problem. The simplest thing to do is set your terminal
emulator for "strip high bit".
ok
bear.
--
until further notice
1:45 a.m.
On Jun 14, 2015, at 1:02 AM, Mike Ross wrote:
I can't even see the hardware messages at
power-on; just garbage - on both
systems, at every baud rate I've tried on the emulator. Nowhere near
booting OS.
If you hold down STOP-D while powering on, the system will go into diag mode. It'll
show you extended diagnostics on the serial port, using 9600 8N1. This may give you extra
information about the nature of your problem.
I haven't double checked that the serial port parameters do reset in this mode, but
several other important things for sure do.
ok
bear.
--
until further notice
1:49 a.m.
I have *only* the serial console. No working keyboard/mouse/screen.
Mike
On Sun, Jun 14, 2015 at 8:45 PM, r.stricklin <bear at typewritten.org> wrote:
On Jun 14, 2015, at 1:02 AM, Mike Ross wrote:
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
I can't even see the hardware messages at
power-on; just garbage - on both
systems, at every baud rate I've tried on the emulator. Nowhere near
booting OS.
If you hold down STOP-D while powering on, the system will go into diag mode. It'll
show you extended diagnostics on the serial port, using 9600 8N1. This may give you extra
information about the nature of your problem.
I haven't double checked that the serial port parameters do reset in this mode, but
several other important things for sure do.
ok
bear.
--
until further notice
8:03 a.m.
On Jun 14, 2015, at 01:49, Mike Ross <tmfdmike at
gmail.com> wrote:
I have *only* the serial console. No working keyboard/mouse/screen.
If all else fails, do you have the means to look at the serial line with an oscilloscope?
Figuring out the port parameters that way might be easier than trying every combination of
baud, word length, parity, etc.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
8:19 a.m.
The default is 9600/8/N/1 but maybe someone messed with the default comms
parameters in OpenFirmware; have you just tried it at a bunch of different
baud rates on your terminal [emulator]? I believe sending a BREAK on ttya
is equivalent to the Stop-A from the graphics head but it's been a while
... there might also be an equivalent for Stop-D. I would suspect it's more
likely to be just in a different baud rate, than to have the number of data
bits, parity, etc modified ... but you never know ... just where I'd begin
... If you have an old serial protocol analyzer sitting around, it should
be able to figure it out pretty quickly.
Have you tried taking a peek through the service manual? It might have some
other suggestions.
The Sparc 10 was a great little machine in its day ... rock solid ... it
made an excellent, compact, light-duty server; I used to have a ton of them!
Best,
Sean
On Sun, Jun 14, 2015 at 11:03 AM, Mark J. Blair <nf6x at nf6x.net> wrote:
On Jun 14, 2015, at 01:49, Mike Ross <tmfdmike
at gmail.com> wrote:
I have *only* the serial console. No working keyboard/mouse/screen.
If all else fails, do you have the means to look at the serial line with
an oscilloscope? Figuring out the port parameters that way might be easier
than trying every combination of baud, word length, parity, etc.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
8:41 a.m.
I'm trying to resurrect a couple of Sparcstation
10 systems. Is there
anything 'funny' about the serial console settings on SS10 hardware? I
thought they always defaulted to 9600-n-8-1, but I get voluminous
gobbledygook at that, and at every other baud rate I've tried.
Both systems behave identically, so I can't assume SS10 settings are
wrong. And I *am* getting data, so I don't see how it can be the
cabling. Something strange about the terminal emulation mode required
maybe?
Did they both come from the same place? It is possible (I guess) that
parameters were changed to meet a local 'standard', and thus both
machines are configured identically, just not the normal way.
From the FAQ I've looked at, the serial port is a
DB25 with the 'A'
port on on the primary channel and the 'B' port
on the back channel.
If so, at least you've not got the classic problem of wiring up an
RS422 port and using the wrong data pin (and thus getting inverted
data, including the framing bits, which really confuses the receiver).
I don't know if it's implemented here, but the FAQ suggests that pin 24
will carry a baud rate clock. Have you tried a 'scope there? If so, what do
you see, and what frequency?
-tony
2:22 p.m.
Sorry, didn't notice I'd replied to an email rather than the list.
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
From last night:
OK I'll have to get to the bottom of this at some point, but it seems
it WAS the cable! Tried another one and, at 9600....
$$$$$ WARNING : No Keyboard Detected! $$$$$
MMU Context Table Reg Test
MMU Context Register Test
MMU TLB Bit Pattern Tests
D-Cache RAM Write/Read Test
D-Cache PTAG Write/Read Test
D-Cache STAG Write/Read Test
I-Cache RAM Write/Read Test
I-Cache PTAG Write/Read Test
I-Cache STAG Write/Read Test
EMC/SMC Control Regs Tests
How in hell a *cable* can result in garbage beats me. I would expect
data, or no data - not garbage data...
On Mon, Jun 15, 2015 at 3:41 AM, tony duell <ard at p850ug1.demon.co.uk> wrote:
I'm trying
to resurrect a couple of Sparcstation 10 systems. Is there
anything 'funny' about the serial console settings on SS10 hardware? I
thought they always defaulted to 9600-n-8-1, but I get voluminous
gobbledygook at that, and at every other baud rate I've tried.
Both systems behave identically, so I can't assume SS10 settings are
wrong. And I *am* getting data, so I don't see how it can be the
cabling. Something strange about the terminal emulation mode required
maybe?
Did they both come from the same place? It is possible (I guess) that
parameters were changed to meet a local 'standard', and thus both
machines are configured identically, just not the normal way.
From the FAQ I've looked at, the serial port is a DB25 with the 'A'
port on on the primary channel and the 'B' port on the back channel.
If so, at least you've not got the classic problem of wiring up an
RS422 port and using the wrong data pin (and thus getting inverted
data, including the framing bits, which really confuses the receiver).
I don't know if it's implemented here, but the FAQ suggests that pin 24
will carry a baud rate clock. Have you tried a 'scope there? If so, what do
you see, and what frequency?
-tony
2:28 p.m.
(Both boxes are running Linux; one is the host for my SIMH TOPS-10
system, the other for KLH TOPS-20. Now I have to figure out how to
tickle them into giving a serial port login; it seems I'd forgotten
the last time I set them up they must have been configured to go
straight into X, so now the boot ends with...
Master Resource Control: runlevel 5 has been reached
Skipped services in runlevel 5: personal-firewall.initial
personal-firewall.final
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "2" respawning too fast: disabled for 5 minutes
(repeat indefinitely)
rather than a login prompt! Grrrrrrr... one thing after another!
Thanks for help.)
Mike
On Mon, Jun 15, 2015 at 9:22 AM, Mike Ross <tmfdmike at gmail.com> wrote:
Sorry, didn't notice I'd replied to an email
rather than the list.
From last night:
OK I'll have to get to the bottom of this at some point, but it seems
it WAS the cable! Tried another one and, at 9600....
$$$$$ WARNING : No Keyboard Detected! $$$$$
MMU Context Table Reg Test
MMU Context Register Test
MMU TLB Bit Pattern Tests
D-Cache RAM Write/Read Test
D-Cache PTAG Write/Read Test
D-Cache STAG Write/Read Test
I-Cache RAM Write/Read Test
I-Cache PTAG Write/Read Test
I-Cache STAG Write/Read Test
EMC/SMC Control Regs Tests
How in hell a *cable* can result in garbage beats me. I would expect
data, or no data - not garbage data...
On Mon, Jun 15, 2015 at 3:41 AM, tony duell <ard at p850ug1.demon.co.uk> wrote:
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
I'm
trying to resurrect a couple of Sparcstation 10 systems. Is there
anything 'funny' about the serial console settings on SS10 hardware? I
thought they always defaulted to 9600-n-8-1, but I get voluminous
gobbledygook at that, and at every other baud rate I've tried.
Both systems behave identically, so I can't assume SS10 settings are
wrong. And I *am* getting data, so I don't see how it can be the
cabling. Something strange about the terminal emulation mode required
maybe?
Did they both come from the same place? It is possible (I guess) that
parameters were changed to meet a local 'standard', and thus both
machines are configured identically, just not the normal way.
From the FAQ I've looked at, the serial port is a DB25 with the 'A'
port on on the primary channel and the 'B' port on the back channel.
If so, at least you've not got the classic problem of wiring up an
RS422 port and using the wrong data pin (and thus getting inverted
data, including the framing bits, which really confuses the receiver).
I don't know if it's implemented here, but the FAQ suggests that pin 24
will carry a baud rate clock. Have you tried a 'scope there? If so, what do
you see, and what frequency?
-tony
3:15 p.m.
You never know ... I once had a network cable that would cause SS10s to
crash intermittently and refuse to boot. It was pretty consistent ... it
would fail out pretty much any unit I put in the position ... Finally I
ripped all the cabling out and started from fresh and ... the machine
plodded on as if nothing were wrong in the first place. Try to figure that
one out :O The bad cable even brought the link up!
Best,
Sean
On Sun, Jun 14, 2015 at 5:28 PM, Mike Ross <tmfdmike at gmail.com> wrote:
(Both boxes are running Linux; one is the host for my
SIMH TOPS-10
system, the other for KLH TOPS-20. Now I have to figure out how to
tickle them into giving a serial port login; it seems I'd forgotten
the last time I set them up they must have been configured to go
straight into X, so now the boot ends with...
Master Resource Control: runlevel 5 has been reached
Skipped services in runlevel 5: personal-firewall.initial
personal-firewall.final
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "2" respawning too fast: disabled for 5 minutes
(repeat indefinitely)
rather than a login prompt! Grrrrrrr... one thing after another!
Thanks for help.)
Mike
On Mon, Jun 15, 2015 at 9:22 AM, Mike Ross <tmfdmike at gmail.com> wrote:
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
Sorry, didn't notice I'd replied to an
email rather than the list.
From last night:
OK I'll have to get to the bottom of this at some point, but it seems
it WAS the cable! Tried another one and, at 9600....
$$$$$ WARNING : No Keyboard Detected! $$$$$
MMU Context Table Reg Test
MMU Context Register Test
MMU TLB Bit Pattern Tests
D-Cache RAM Write/Read Test
D-Cache PTAG Write/Read Test
D-Cache STAG Write/Read Test
I-Cache RAM Write/Read Test
I-Cache PTAG Write/Read Test
I-Cache STAG Write/Read Test
EMC/SMC Control Regs Tests
How in hell a *cable* can result in garbage beats me. I would expect
data, or no data - not garbage data...
On Mon, Jun 15, 2015 at 3:41 AM, tony duell <ard at p850ug1.demon.co.uk>
wrote:
>> I'm trying to resurrect a couple of
Sparcstation 10 systems. Is there
>> anything 'funny' about the serial console settings on SS10 hardware? I
>> thought they always defaulted to 9600-n-8-1, but I get voluminous
>> gobbledygook at that, and at every other baud rate I've tried.
>>
>> Both systems behave identically, so I can't assume SS10 settings are
>> wrong. And I *am* getting data, so I don't see how it can be the
>> cabling. Something strange about the terminal emulation mode required
>> maybe?
>
> Did they both come from the same place? It is possible (I guess) that
> parameters were changed to meet a local 'standard', and thus both
> machines are configured identically, just not the normal way.
>
> From the FAQ I've looked at, the serial port is a DB25 with the 'A'
> port on on the primary channel and the 'B' port on the back channel.
> If so, at least you've not got the classic problem of wiring up an
> RS422 port and using the wrong data pin (and thus getting inverted
> data, including the framing bits, which really confuses the receiver).
>
> I don't know if it's implemented here, but the FAQ suggests that pin 24
> will carry a baud rate clock. Have you tried a 'scope there? If so,
what
do
you see,
and what frequency?
-tony
--
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
10:05 p.m.
How in hell a *cable* can result in garbage beats me. I would expect
data, or no data - not garbage data...
Two things spring to mind :
1) Open-circuit signal ground, with the ground therefore completed by mains earth. I had a
nasty
version of that years ago, the system would work with a VT100 (at lower baud rates), but
not at all
with my Tandy M100 laptop.
2) Too much stray capacitance. Given a sensible output impedance on the driver (and there
is a
specification for this), this will round off the pulses, make narrow pulses too small, and
so on. This
is the more likely cause I think. How long was the defective cable?
-tony
10:22 p.m.
+1 to Tony for heading down the right path.
The rear DB25 serial connector is an A & B serial port combined.
Sun had/sold a special Y-splitter cable to use for the combined port.
Here is pinout information from sunhelp.org in case you want to make one for
yourself from scratch.
http://www.sunhelp.org/unix-serial-port-resources/serial-pinouts/#10.lx.link
Plan B, either someone here has one they can give/sell you, or someone from the
Sun rescue list will. Or eBay, etc.
Good Luck,
Jerry
On 06/14/15 10:41 AM, tony duell wrote:
I'm trying
to resurrect a couple of Sparcstation 10 systems. Is there
anything 'funny' about the serial console settings on SS10 hardware? I
thought they always defaulted to 9600-n-8-1, but I get voluminous
gobbledygook at that, and at every other baud rate I've tried.
Both systems behave identically, so I can't assume SS10 settings are
wrong. And I *am* getting data, so I don't see how it can be the
cabling. Something strange about the terminal emulation mode required
maybe?
Did they both come from the same place? It is possible (I guess) that
parameters were changed to meet a local 'standard', and thus both
machines are configured identically, just not the normal way.
From the FAQ I've looked at, the serial port
is a DB25 with the 'A'
port on on the primary channel and the 'B'
port on the back channel.
If so, at least you've not got the classic problem of wiring up an
RS422 port and using the wrong data pin (and thus getting inverted
data, including the framing bits, which really confuses the receiver).
I don't know if it's implemented here, but the FAQ suggests that pin 24
will carry a baud rate clock. Have you tried a 'scope there? If so, what do
you see, and what frequency?
-tony
10:24 p.m.
The rear DB25 serial connector is an A & B serial
port combined.
Sun had/sold a special Y-splitter cable to use for the combined port.
The RS232 specification allows for 2 serial channels on the DB25 connector. Most
machines only use the primary channel. and Sun were sensible enough to wire their
'2 ports on one connector' so that port A uses the primary channel pins and port
B
uses the 'back channel'. This means that if you plug a normal, minimally-wired
serial cable in (say an adapter to a PC DE9 port) you connect to port A. You only
need the splitter cable if you want to use port B
-tony
3478
days inactive
3479
days old
13 comments
6 participants
participants (6)
-
ard＠p850ug1.demon.co.uk -
bear＠typewritten.org -
nf6x＠nf6x.net -
other＠oryx.us -
scaron＠umich.edu -
tmfdmike＠gmail.com