Strange Characters from Terminal

Strange Characters from Terminal

Post by Paul Egge » Mon, 10 Jul 2000 04:00:00




>I'm attempting to connect to a new (to me at least) SparcStation 1 over
>serial.  But about half way through the boot process, the text becomes
>garbled.

During the boot, SunOS 4.1.3 turns on parity generation, and that's
what makes your characters appear garbled.  Your terminal is
interpreting the top bit as part of the character (most likely ISO
Latin 1 or something like that), whereas it's just 7-bit ASCII with the
top bit being even parity.

Can you tell your terminal emulator to ignore the parity bit?  That's
perhaps the simplest fix.

I no longer have any SunOS 4.1.x machines to play with, but if memory
serves you can also tell SunOS to not generate parity during boot,
though this requires a kernel rebuild.  Also, if you can't rebuild the
kernel you can tell the login program to disable parity generation, but
this fixes the problem only starting with the login: prompt, and
messages before that will still be garbled.  (Or you could upgrade to
Solaris 7.  :-)

 
 
 

Strange Characters from Terminal

Post by jerem.. » Tue, 11 Jul 2000 04:00:00


Greetings,

I'm attempting to connect to a new (to me at least) SparcStation 1 over
serial.  But about half way through the boot process, the text becomes
garbled.  I'm using microcom, 8n1, 9600.  Here's all the information
from the terminal:

Testing Booting from: sd(0,0,0)vmunix root on sd0a fstype 4.2 Size:
1335296+219080+120232 bytes SunOS Release 4.1.3 (GENERIC) #3: Mon Jul 27
16:43:54 PDT 1992 Copyright (c) 1983-1992, Sun Microsystems, Inc. mem =
16384K (0x1000000) avail mem = 14356480 Ethernet address = 8:0:20:7:93:6b cpu
= Sun 4/60 zs0 at obio 0xf1000000 pri 12 zs1 at obio 0xf0000000 pri 12 fd0 at
obio 0xf7200000 pri 11 audio0 at obio 0xf7201000 pri 13 sbus0 at SBus slot 0
0x0 dma0 at SBus slot 0 0x400000 esp0 at SBus slot 0 0x800000 pri 3 sd0 at
esp0 target 3 lun 0 sd0: <Quantum ProDrive 105S cyl 974 alt 2 hd 6 sec 35>
le0 at SBus slot 0 0xc00000 pri 5 root on sd0a fstype 4.2 swap on sd0b fstype
spec size 86520K dump on sd0b fstype spec size 86508K
Setti????et??of?le?to?255.255.255.0?
ifco?fi?:?ioctl?(S??G??AGS?:??o??c?i?terfcele0:?No?crrier?-?tr?cei?e
r?cale?eroale??? ? le0:?AP?tie??o?t.?
o??t:??e??2??o???r:?No??c??e?ice?or???re? o??t:??i?i????e?o?:?
????r? cec?i???filete? fc?:?No??c?file?or??irector?
U???ow??error?i??reaoot?fc?.? ?
ANNG?-?file?te??e?N???aee??reo??te??re?-write.?
Ue?fc??to?fix???file?te?eroale??reaooti???te?
te?if???eroale?re?fo????wit??o??te??file?te.?
After?file?te??e?fc?'e??cle?l??o??c??reo??t?file?
te????fi?i?i??le-?er?et?e??i???"etcrc.i??le".?
-:?tt:??ot?fo???? -:???e:??ot?fo???? -:?V?S?N?:?i??ot???i?e?tifier?
-:?tt:??ot?fo???? ?? ? ??? ? Would this be because of the OS changing
the terminal properties?

It's very possible I'm having problems with the software, but I went for
microcom as it seemed easier to work with then kermit, etc.  I'm using a
null modem connector and a serial cable, both brand new, so I'd like to
then they're working fine.  Since the text is perfectly legible at
first, I'd like to think the OS is just changing some terminal
parameter, but I thought the terminal was "hardware" based, not OS.  Am
I incorrect in that thought?

I've looked around on newgroups, all unix/solaris sites I can find, but
have been unable to find anything about this, let alone much on serial
communications (I guess it's just expected that you know how...)

Any help and all help is greatly appreciated.

Thanks,

Jeremy

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

Strange Characters from Terminal

Post by Greg Andre » Tue, 11 Jul 2000 04:00:00



>Testing Booting from: sd(0,0,0)vmunix root on sd0a fstype 4.2 Size:
>1335296+219080+120232 bytes SunOS Release 4.1.3 (GENERIC) #3: Mon Jul 27
>16:43:54 PDT 1992 Copyright (c) 1983-1992, Sun Microsystems, Inc. mem =
>16384K (0x1000000) avail mem = 14356480 Ethernet address = 8:0:20:7:93:6b cpu
>= Sun 4/60 zs0 at obio 0xf1000000 pri 12 zs1 at obio 0xf0000000 pri 12 fd0 at
>obio 0xf7200000 pri 11 audio0 at obio 0xf7201000 pri 13 sbus0 at SBus slot 0
>0x0 dma0 at SBus slot 0 0x400000 esp0 at SBus slot 0 0x800000 pri 3 sd0 at
>esp0 target 3 lun 0 sd0: <Quantum ProDrive 105S cyl 974 alt 2 hd 6 sec 35>
>le0 at SBus slot 0 0xc00000 pri 5 root on sd0a fstype 4.2 swap on sd0b fstype
>spec size 86520K dump on sd0b fstype spec size 86508K
>Setti????et??of?le?to?255.255.255.0?
>ifco?fi?:?ioctl?(S??G??AGS?:??o??c?i?terfcele0:?No?crrier?-?tr?cei?e

Yes, since some of the letters come through properly (e.g. the "Setti" part
of the word "Setting", the word "ifconfig" looks good except for the "n"
and the "g"), what you have is a parity mismatch instead of a speed mismatch.

If the computer switched speeds on the RS232 port, all the characters
would be garbled.  Since some parts of words are fine while others are
garbled, it's a parity mismatch.

Here's the quick and dirty way out.  Set the port characteristics in
the boot prom to 7E1, then switch your terminal program to 7E1:

At the "ok" prompt, type:

   setenv ttya-mode 9600,7,e,1,-

and power the computer off.  Switch your terminal program to 7 data bits
and Even parity, then turn the computer back on.  Now everything should
use 7E1 from the start of the boot process to the end, and the characters
won't become garbled like that.

  -Greg
--

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::