Hi Greg,
In message <20110822083336.gi92...@core.byshenk.net>, Greg Byshenk
<free...@byshenk.net> writes
On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
puc0: <Oxford Semiconductor OXPCIe952 UARTs> mem
0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq
30 at device 0.0 on pci4
puc0: 2 UARTs detected
uart2: <16950 or compatible> at port 1 on puc0
uart3: <16950 or compatible> at port 2 on puc0
This indicates that the puc(4) code is working correctly - it recognises
the board, reads via one of the BARs to confirm there are two UARTs,
initialises both UARTs to 16950 mode, then hands off these ports to
uart(4).
I'll follow up tomorrow. Thanks.
Following up:
It appears that indeed, the "options COM_MULTIPORT" is unnecessary
for 9-BETA; I've rebuilt the kernel without it, and the card is
still recognized, along with the ports.
That's what I expected. The only line needed is "device puc". I have no
idea why this can't be included in GENERIC, especially as puc(4) doesn't
work as a module (no drivers are attached to the ports on the puc
board).
But all it not as it should be. I still can't set the speed on the
card.
# stty -f /dev/cuau2.init speed 115200 crtscts
stty: /dev/cuau2.init isn't a terminal
#
And setting speed on the device itself remains a no-op:
# stty -f /dev/cuau2 speed 115200 crtscts
9600
#
That said, the card -does- seem to work, at least at some level.
With the speed issue pointed out, I set the connection on the
other end to 9600, and then it works. But I'd really like it to
be faster than that (it's just a serial console, so we could
probably live with 9600, though we wouldn't like it).
If there is reason to think that this could be a 9.x issue,
then I could try going to 8.x.
My earlier instructions omitted mention of the lock, which is really
needed if you want to force a particular speed
On 8.2:
[root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 115200 crtscts' ;
stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} > /dev/null ;
stty -f ${PORT}.lock 1 ; stty -f ${PORT}
speed 115200 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb crtscts
[root@manganese ~]# cu -l cuau5
Connected
ATI4
U.S. Robotics 56K FAX EXT Settings...
B0 E1 F1 L2 M1 Q0 V1 X4 Y1
SPEED=115200 PARITY=N WORDLEN=8
DIAL=TONE OFF LINE CID=1
&A3 &B1 &C1 &D2 &H2 &I2 &K1
&M4 &N0 &R1 &S0 &T5 &U0 &Y1
S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004
S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000
S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019
S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002
S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000
S41=004 S42=000
LAST DIALLED #:
OK
~
[EOT]
[root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 38400 crtscts' ;
stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} > /dev/null ;
stty -f ${PORT}.lock 1 ; stty -f ${PORT}
speed 38400 baud;
lflags: echoe echoke echoctl
oflags: tab0
cflags: cs8 -parenb crtscts
[root@manganese ~]# cu -l cuau5
Connected
ATI4
U.S. Robotics 56K FAX EXT Settings...
B0 E1 F1 L2 M1 Q0 V1 X4 Y1
SPEED=38400 PARITY=N WORDLEN=8
DIAL=TONE OFF LINE CID=1
&A3 &B1 &C1 &D2 &H2 &I2 &K1
&M4 &N0 &R1 &S0 &T5 &U0 &Y1
S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004
S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000
S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019
S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002
S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000
S41=004 S42=000
LAST DIALLED #:
OK
~
[EOT]
This is one of my OXPCIe954 ports - the modem on that port identifies
the speed it is being talked to in the ATI4 output.
If this is a 9.x issue, it seems more likely to be in the uart(4) code -
though I haven't been following development. If you are getting nowhere
with 9.x, can you try with 8.x? stable/8 might be the best choice, as
the necessary pucdata.c changes postdates 8.2-RELEASE. That said, I
patch 8.2-RELEASE on my machine, choosing to keep things conservative.
I look forward to your feedback.
With best wishes,
David
--
David Wood
da...@wood2.org.uk
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
