serial input line not working

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

serial input line not working

Peer Janssen-2
I updated an alix.3c3 box from OpenBSD 4.6 release to 6.0 release
recently via bsd.rd install kernel.
This went very smoothly, except that now I can't get a serial stream via
the DB9 serial connector.

On a linux box, I do indeed receive the (geiger data) lines like these
at a speed of 9600 baud:
#513302 Timestamp: 733348928    Delta_Timestamp: 60000  Total_Impulses:
39769137        Delta_Impulses: 90
so up to the connector at the end of the cable arriving from geiger
interface the data is coming, and in can be read and stored, etc.

But on that alix box, nothing seems to arrive at the serial line. I
tried all of these (the <x> were in 0 t o5):

# cu -d -l ttyC<x> -s
9600

Connected to /dev/ttyC<x> (speed 9600)

Result: no data at all arrives. I don't see what went wrong.

Peer


# dmesg
OpenBSD 6.0 (GENERIC) #1917: Tue Jul 26 12:48:33 MDT 2016
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 499 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
real mem  = 259207168 (247MB)
avail mem = 241590272 (230MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/15/07, BIOS32 rev. 0 @ 0xfaf90
apm0 at bios0: Power Management spec V1.2 (slowidle)
pcibios0 at bios0: rev 2.1 @ 0xf0000/0xdfb4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf20/144 (7 entries)
pcibios0: bad IRQ table checksum
pcibios0: PCI BIOS has 7 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 5 10 11
pcibios0: no compatible PCI ICU found
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc0000/0x8000 0xc8000/0xa800 0xef000/0x1000!
cpu0 at mainbus0: (uniprocessor)
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:0d:b9:13:3c:30
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
32-bit 3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
maxtmp0 at iic0 addr 0x4c: lm86
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <TRANSCEND>
wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11,
CS5536 AC97
ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
audio0 at auglx0
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5,
version 1.0, legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbdprobe: reset response 0xfa
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (0e0478eff5b1b08d.a) swap on wd0b dump on wd0b


--
Peer Janssen - [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: serial input line not working

Theo de Raadt-2
> But on that alix box, nothing seems to arrive at the serial line. I
> tried all of these (the <x> were in 0 t o5):
>
> # cu -d -l ttyC<x> -s
> 9600
>
> Connected to /dev/ttyC<x> (speed 9600)

Well, because that is one of the virtual console / screen
device.  You want to use tty00.

Reply | Threaded
Open this post in threaded view
|

Re: serial input line not working

Peer Janssen-2
Am 22.09.2016 um 00:23 schrieb Theo de Raadt:
>> But on that alix box, nothing seems to arrive at the serial line. I
>> tried all of these (the <x> were in 0 t o5):
>>
>> # cu -d -l ttyC<x> -s
>> 9600
>>
>> Connected to /dev/ttyC<x> (speed 9600)
> Well, because that is one of the virtual console / screen
> device.  You want to use tty00.
Thank you. Now I get this error:

# cu -d -l tty00 -s 9600
cu: open("/dev/tty00"): Device not configured

I didn't find how to configure this/a device. Tried /etc/remote,
/etc/ttys, many man pages, Absolute OpenBSD, read about line disciplines
(but didn't find hot to configure them), etc. Also, from 5.8 on tip is
not there any more, guess it was merged with cu or so. Or are there
(more) framework change with doc lagging behind?
Anyway -- any hints?

If I understood ttys correctly, I can attach my serial logger software
(instead of getty) directly to tty00 (once I know how to configure it),
so that when the box boots, it automatically starts logging, and if the
process disappears, it restarts it. Right?

Peer


--
Peer Janssen - [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: serial input line not working

Theo de Raadt-2
> Am 22.09.2016 um 00:23 schrieb Theo de Raadt:
> >> But on that alix box, nothing seems to arrive at the serial line. I
> >> tried all of these (the <x> were in 0 t o5):
> >>
> >> # cu -d -l ttyC<x> -s
> >> 9600
> >>
> >> Connected to /dev/ttyC<x> (speed 9600)
> > Well, because that is one of the virtual console / screen
> > device.  You want to use tty00.
> Thank you. Now I get this error:
>
> # cu -d -l tty00 -s 9600
> cu: open("/dev/tty00"): Device not configured
 
Use cua00

Look -- did you read the manual page?


     -l line
           Specify the line to use.  Either of the forms like cua00 or
           /dev/cua00 are permitted.  The default is /dev/cua00.  See cua(4)
           for information on terminal devices.  Users in group ``dialer'' are
           permitted to use cua(4) devices by default.


Did you then read follow the breadcrumps to read cua(4)

?

> I didn't find how to configure this/a device. Tried /etc/remote,
> /etc/ttys, many man pages, Absolute OpenBSD, read about line disciplines
> (but didn't find hot to configure them), etc. Also, from 5.8 on tip is
> not there any more, guess it was merged with cu or so. Or are there
> (more) framework change with doc lagging behind?
> Anyway -- any hints?
>
> If I understood ttys correctly, I can attach my serial logger software
> (instead of getty) directly to tty00 (once I know how to configure it),
> so that when the box boots, it automatically starts logging, and if the
> process disappears, it restarts it. Right?

It seems you did all that, but didn't read the manual pages.

In fact, what you want is entirely the defaults:

   # cu

Reply | Threaded
Open this post in threaded view
|

Re: serial input line not working

Peer Janssen-2
Am 22.09.2016 um 04:00 schrieb Theo de Raadt:

>> Am 22.09.2016 um 00:23 schrieb Theo de Raadt:
>>>> But on that alix box, nothing seems to arrive at the serial line. I
>>>> tried all of these (the <x> were in 0 t o5):
>>>>
>>>> # cu -d -l ttyC<x> -s
>>>> 9600
>>>>
>>>> Connected to /dev/ttyC<x> (speed 9600)
>>> Well, because that is one of the virtual console / screen
>>> device.  You want to use tty00.
>> Thank you. Now I get this error:
>>
>> # cu -d -l tty00 -s 9600
>> cu: open("/dev/tty00"): Device not configured
>
> Use cua00
>
> Look -- did you read the manual page?
>
>
>      -l line
>            Specify the line to use.  Either of the forms like cua00 or
>            /dev/cua00 are permitted.  The default is /dev/cua00.  See
cua(4)
>            for information on terminal devices.  Users in group ``dialer''
are

>            permitted to use cua(4) devices by default.
>
>
> Did you then read follow the breadcrumps to read cua(4)
>
> ?
>
>> I didn't find how to configure this/a device. Tried /etc/remote,
>> /etc/ttys, many man pages, Absolute OpenBSD, read about line disciplines
>> (but didn't find hot to configure them), etc. Also, from 5.8 on tip is
>> not there any more, guess it was merged with cu or so. Or are there
>> (more) framework change with doc lagging behind?
>> Anyway -- any hints?
>>
>> If I understood ttys correctly, I can attach my serial logger software
>> (instead of getty) directly to tty00 (once I know how to configure it),
>> so that when the box boots, it automatically starts logging, and if the
>> process disappears, it restarts it. Right?
> It seems you did all that, but didn't read the manual pages.
Oh yes, I did. That's what I started with (but didn't tell so in my
first mail).
Then you sent me on the tty00 way and I tried to figure that out (and
learned certain things, like that tty and cua are kind of pairs for
rx/tx, but didn't get into the detailed details how it's attached where
internally, etc.), but to no avail.
> In fact, what you want is entirely the defaults:
>
>    # cu
Sure, it look's like a very standard thing to do, but:

# cu -d -l cua00 -s 9600
cu: open("/dev/cua00"): Device not configured
# cu
cu: open("/dev/cua00"): Device not configured

So I wonder if the device is recognized at all by the kernel when it
starts. Doesn't look like so, unless it's implied with certain devices.
(The dmesg is in my first post.)

Extract of my /etc/ttys (changed it a bit to try out tty00 without getty
getting in the way):

# name  getty                           type    status          comments
#
console "/usr/libexec/getty std.9600"   vt220   off secure
ttyC0   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC1   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC2   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC3   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC4   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC5   "/usr/libexec/getty std.9600"   vt220   on  secure
ttyC6   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC7   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC8   "/usr/libexec/getty std.9600"   vt220   off secure
ttyC9   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCa   "/usr/libexec/getty std.9600"   vt220   off secure
ttyCb   "/usr/libexec/getty std.9600"   vt220   off secure
#tty00  "/usr/libexec/getty std.9600"   unknown off
tty00   none                            unknown off
tty01   "/usr/libexec/getty std.9600"   unknown off
tty02   "/usr/libexec/getty std.9600"   unknown off
tty03   "/usr/libexec/getty std.9600"   unknown off
tty04   "/usr/libexec/getty std.9600"   unknown off

I also tried console:

# cu -d -l console -s 9600
Connected to /dev/console (speed 9600)

Seems configured at least -- but no data arrives. So still something is
missing.
Maybe some BIOS quirk, who knows.
Maybe someone on this list had a similar problem?

This is a very fresh install, I didn't update but reinstall completely.

Peer


--
Peer Janssen - [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: serial input line not working

Philip Guenther-2
In reply to this post by Peer Janssen-2
Backing up to the beginning...

On Wed, Sep 21, 2016 at 2:39 PM, Peer Janssen <[hidden email]> wrote:
> I updated an alix.3c3 box from OpenBSD 4.6 release to 6.0 release
> recently via bsd.rd install kernel.
> This went very smoothly, except that now I can't get a serial stream via
> the DB9 serial connector.

Ah, you accessed it under OpenBSD 4.6.  That raises two questions:
1) What was the dmesg when this box ran 4.6?
2) What was the exact command line you used then


> But on that alix box, nothing seems to arrive at the serial line.

The 6.0 dmesg you included doesn't include any "com" drivers that I
recognize, so it doesn't surprise me that nothing seems to work...and
thus the query about what 4.6 reported and what worked there.


Philip Guenther

Reply | Threaded
Open this post in threaded view
|

Re: serial input line not working

Darren Tucker
In reply to this post by Peer Janssen-2
On Thu, Sep 22, 2016 at 12:29 PM, Peer Janssen <[hidden email]> wrote:
> # cu -d -l cua00 -s 9600
> cu: open("/dev/cua00"): Device not configured
> # cu
> cu: open("/dev/cua00"): Device not configured

I have an ALIX 2d[something] and on it, the serial ports show up as com devices:

$ dmesg | egrep '^com'
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo

I notice that the com devices are missing from your dmesg output,
though.  Maybe it's not enabled in the BIOS?  I see
http://pcengines.ch/alix3d3.htm has "fix serial port" against the most
recent firmware version...

--
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Reply | Threaded
Open this post in threaded view
|

Re: serial input line not working [solved]

Peer Janssen-2
In reply to this post by Philip Guenther-2
Am 22.09.2016 um 04:47 schrieb Philip Guenther:

> Backing up to the beginning...
>
> On Wed, Sep 21, 2016 at 2:39 PM, Peer Janssen <[hidden email]> wrote:
>> I updated an alix.3c3 box from OpenBSD 4.6 release to 6.0 release
>> recently via bsd.rd install kernel.
>> This went very smoothly, except that now I can't get a serial stream via
>> the DB9 serial connector.
> Ah, you accessed it under OpenBSD 4.6.  That raises two questions:
> 1) What was the dmesg when this box ran 4.6?
> 2) What was the exact command line you used then
Since I riskily upgraded in-place, no chance to get back to a dmesg of
the installation which was already history.
>> But on that alix box, nothing seems to arrive at the serial line.
> The 6.0 dmesg you included doesn't include any "com" drivers that I
> recognize, so it doesn't surprise me that nothing seems to work...and
> thus the query about what 4.6 reported and what worked there.

That was indeed the problem.
The solution was to switch a setting in the BIOS which enabled the com0
port. Duh!

It was there from the beginning to see, but I didn't know certain
OpenBSD terminology yet to understand how the different levels of access
to the port were named and interact. E.g. what precisely "configured"
(as in "Device not configured") referred to, namely that it's not me who
had to do that configuring manually in whatever securelevel etc. of the
fine OpenBSD software, but that it should have been the autoconf
mecanism of the kernel which should have done it, so I searched around
without realizing, what is now obvious to me, too, that the
configuration had to take place -- manually indeed -- before OpenBSD
even got it's chance to do it's own configuration.

So, more RTFM cleared things up, and now I got a better grip on the system.
This also enabled me to get gpio working on that and other boards. Great
fun!

Thanks to all who helped! Great software!
Peer

--
Peer Janssen - [hidden email]