NetBSD Problem Report #49115
From www@NetBSD.org Thu Aug 14 17:10:20 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 97B79AD3E6
for <gnats-bugs@gnats.NetBSD.org>; Thu, 14 Aug 2014 17:10:20 +0000 (UTC)
Message-Id: <20140814171018.D09DFAD3E8@mollari.NetBSD.org>
Date: Thu, 14 Aug 2014 17:10:18 +0000 (UTC)
From: n54@gmx.com
Reply-To: n54@gmx.com
To: gnats-bugs@NetBSD.org
Subject: serial interface (/dev/tty*) not working
X-Send-Pr-Version: www-1.0
>Number: 49115
>Category: kern
>Synopsis: serial interface (/dev/tty*) not working
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Aug 14 17:15:00 +0000 2014
>Last-Modified: Thu Jun 11 03:20:00 +0000 2015
>Originator: Kamil Rytarowski
>Release: NetBSD-current, NetBSD-6.1.x
>Organization:
>Environment:
NetBSD, amd64
current (pre 7.0) and stable 6.1.x
>Description:
I cannot get serial connector to work on different amd64 machines.
minicom -b 115200 -D /dev/ttyU0
picocom -b 115200 /dev/ttyU0
cu -s 115200 -l /dev/ttyU0
I was trying with an USB-serial adapter.
dmesg:
uchcom0 at uhub6 port 1
uchcom0: QinHeng Electronics USB2.0-Ser!, rev 1.10/2.54, addr 2
uchcom0: CH341 detected
ucom0 at uchcom0
I was trying with a PCI card with two serial connectors (and relevant /dev/tty0 device), without success.
I was testing my embedded machine with serial and the peripherals under GNU/Linux and the device worked.
Here is a log with a working options from GNU/Linux:
picocom v1.6
port is : /dev/ttyUSB0
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv
imap is :
omap is :
emap is : crcrlf,delbs,
Reproducing it on NetBSD results at best with detaching ucom (and /dev/ttyU0) from drvlst.
Once I was trying to connect to a different device with USB-TTL connector, without any luck.
>How-To-Repeat:
1. Install NetBSD-6.1.x or current.
2. Get a PCI RS232 card or USB adapter with RS242 port
3. Get a third party machine designed to work through serial
4. Connect cables, power on
5. Try cu, picocom, minicom to establish a connection
6. Read none characters from the device.
>Fix:
Get Linux and see that the peripherals work.
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/49115: serial interface (/dev/tty*) not working
Date: Thu, 14 Aug 2014 20:46:24 +0200
On Thu, Aug 14, 2014 at 05:15:00PM +0000, n54@gmx.com wrote:
...
> 4. Connect cables, power on
> 5. Try cu, picocom, minicom to establish a connection
> 6. Read none characters from the device.
Well, it works for me (both on netbsd-6 and current), I use it a lot,
basically daily.
So we may need a bit more details from your setup - you are using the
"cu" from base (/usr/bin/cu)? Have you tried doing it as root? Can you
show the device nodes in question (i.e. ls -l /dev/ttyU0 or similar)?
Martin
From: "Kamil Rytarowski" <n54@gmx.com>
To: gnats-bugs@netbsd.org
Cc: martin@duskware.de
Subject: Re: kern/49115
Date: Thu, 14 Aug 2014 23:30:37 +0200
Hello,
At the hand I have got NetBSD current. My cu is from base (location /usr/bin/cu)
From /usr/src/usr.bin/tip:
cu.c rev. 1.21
tip.h rev. 1.33
etc
I use 'cu' as root.
At the moment I have got at hand my PPC Efika (confirmed to work on Linux) and a USB-RS232 adapter (the same).
compaq$ ls -l /dev/ttyU*
crw------- 1 uucp wheel 66, 0 Aug 14 22:30 /dev/ttyU0
crw------- 1 uucp wheel 66, 1 Aug 14 22:30 /dev/ttyU1
crw------- 1 uucp wheel 66, 2 Aug 14 22:30 /dev/ttyU2
crw------- 1 uucp wheel 66, 3 Aug 14 22:30 /dev/ttyU3
crw------- 1 uucp wheel 66, 4 Aug 14 22:30 /dev/ttyU4
crw------- 1 uucp wheel 66, 5 Aug 14 22:30 /dev/ttyU5
crw------- 1 uucp wheel 66, 6 Aug 14 22:30 /dev/ttyU6
crw------- 1 uucp wheel 66, 7 Aug 14 22:30 /dev/ttyU7
Please let us focus currently on this set-up (this adapter, driver, Efika and NetBSD-current).
In general cu works for me for a ppp modem (driver: uhso).
Thank you,
From: Martin Husemann <martin@duskware.de>
To: Kamil Rytarowski <n54@gmx.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/49115
Date: Fri, 15 Aug 2014 10:18:58 +0200
Nothing obviously wrong, as far as I can tell.
Stupid question: do other USB devices work on that machine?
Martin
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/49115: serial interface (/dev/tty*) not working
Date: Fri, 15 Aug 2014 05:15:53 +0400
On Thu, Aug 14, 2014 at 17:15:00 +0000, n54@gmx.com wrote:
> I cannot get serial connector to work on different amd64 machines.
>
> minicom -b 115200 -D /dev/ttyU0
> picocom -b 115200 /dev/ttyU0
> cu -s 115200 -l /dev/ttyU0
Shouldn't you be using dial-out device?
E.g. I use cu -l /dev/dtyU0 -s 9600 with
uplcom0 at uhub1 port 1
uplcom0: Prolific Technology Inc. USB-Serial Controller, rev 2.00/3.00, addr 2
ucom0 at uplcom0
to talk to serial consoles of my headless machines.
-uwe
From: "Kamil Rytarowski" <n54@gmx.com>
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: Re: kern/49115
Date: Sun, 17 Aug 2014 03:31:02 +0200
Hello,
Thank you for your replies.
Yes, in general USB devices work (USB Modem, USB Flash disk, USB HDD). However USB subsystem behaves unstable, but it's another issue.
Thank you for your note. Why to use /dev/dtyU*? Is it documented?
When I'm trying to use `cu -s 9600 -l /dev/dtyU0' then I get:
- in dmesg:
ucom0: detached
uchcom0: detached
uchcom0: at uhub3 port 1 (addr 2) disconnected
- in cu:
FATAL: term closed
- in picocom:
FATAL: term closed
term_exitfunc: reset failed for dev UNKNOWN: Bad file descriptor
I was trying to look for patches from other BSD:
- http://svnweb.freebsd.org/base/head/sys/dev/usb/serial/uchcom.c?view=log
- http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uchcom.c?f=h
I will try to test other BSD to know whether they will handle my device more reliable and back-port patches.
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/49115
Date: Sun, 17 Aug 2014 06:04:50 +0400
On Sun, Aug 17, 2014 at 01:45:01 +0000, Kamil Rytarowski wrote:
> Thank you for your note. Why to use /dev/dtyU*? Is it documented?
$ man 4 tty
and search for "dial-out".
> When I'm trying to use `cu -s 9600 -l /dev/dtyU0' then I get:
>
> - in dmesg:
> ucom0: detached
> uchcom0: detached
> uchcom0: at uhub3 port 1 (addr 2) disconnected
Ah, looks like a genuine driver bug, I guess.
-uwe
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: n54@gmx.com
Subject: Re: kern/49115
Date: Sun, 17 Aug 2014 09:16:34 +0200
On Sun, Aug 17, 2014 at 01:45:01AM +0000, Kamil Rytarowski wrote:
> Thank you for your note. Why to use /dev/dtyU*? Is it documented?
It depends on your exact serial wiring wether you will need it - most
embedded device only provide 3 wire serial console, so don't do
RTS/CTS, and of course there is no notion of a carrier involved. But
it is easy to fake them at the connector.
Martin
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, n54@gmx.com
Cc:
Subject: Re: kern/49115
Date: Sun, 17 Aug 2014 03:24:57 -0400
On Aug 17, 7:20am, martin@duskware.de (Martin Husemann) wrote:
-- Subject: Re: kern/49115
| The following reply was made to PR kern/49115; it has been noted by GNATS.
|
| From: Martin Husemann <martin@duskware.de>
| To: gnats-bugs@NetBSD.org
| Cc: n54@gmx.com
| Subject: Re: kern/49115
| Date: Sun, 17 Aug 2014 09:16:34 +0200
|
| On Sun, Aug 17, 2014 at 01:45:01AM +0000, Kamil Rytarowski wrote:
| > Thank you for your note. Why to use /dev/dtyU*? Is it documented?
|
| It depends on your exact serial wiring wether you will need it - most
| embedded device only provide 3 wire serial console, so don't do
| RTS/CTS, and of course there is no notion of a carrier involved. But
| it is easy to fake them at the connector.
Or emulate it in software... man ttys, look at softcar.
christos
From: "Kamil Rytarowski" <n54@gmx.com>
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: Re: kern/49115
Date: Sun, 17 Aug 2014 13:17:52 +0200
Hello,
=C2=A0
Thank you for your feedback.
I will try to research the things and in case of problems ask here.
=C2=A0
Thanks,
From: Vicente Chaves de Melo <vicente.melo.br@ieee.org>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, n54@gmx.com
Cc:
Subject: Re: kern/49115
Date: Wed, 10 Jun 2015 15:49:54 -0300
Hi Kamil,
sorry to intrude but you managed to solve this problem?
I believe I have exactly the same USB-Serial converter described in this PR.
And I couldn't make it work with NetBSD7 + tip, although run smoothly
with OpenBSD 5.7 + tip, Linux + minicom and even with Windows + putty .
In advance, thank you very much for your attention.
Vicente.
On 17/08/2014 08:20, Kamil Rytarowski wrote:
> The following reply was made to PR kern/49115; it has been noted by GNATS.
>
> From: "Kamil Rytarowski" <n54@gmx.com>
> To: gnats-bugs@gnats.netbsd.org
> Cc:
> Subject: Re: kern/49115
> Date: Sun, 17 Aug 2014 13:17:52 +0200
>
> Hello,
> =C2=A0
> Thank you for your feedback.
> I will try to research the things and in case of problems ask here.
> =C2=A0
> Thanks,
>
>
From: Kamil Rytarowski <n54@gmx.com>
To: Vicente Chaves de Melo <vicente.melo.br@ieee.org>,
gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/49115
Date: Wed, 10 Jun 2015 22:35:59 +0000
On 10.06.2015 18:49, Vicente Chaves de Melo wrote:
> Hi Kamil,
> sorry to intrude but you managed to solve this problem?
> I believe I have exactly the same USB-Serial converter described in this
> PR.
> And I couldn't make it work with NetBSD7 + tip, although run smoothly
> with OpenBSD 5.7 + tip, Linux + minicom and even with Windows + putty .
> In advance, thank you very much for your attention.
I ran out of time to test it on others than NetBSD platforms. I had
problems with Linux as well and switched to other serial.
If you like you can take this problem and backport OpenBSD enhancements
and I will test them.
When I will get a free metal to install there OpenBSD I will test it there.
From: Vicente Chaves de Melo <vicente.melo.br@ieee.org>
To: Kamil Rytarowski <n54@gmx.com>, gnats-bugs@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/49115
Date: Wed, 10 Jun 2015 23:48:24 -0300
This is a multi-part message in MIME format.
--------------090103040904040800000404
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Hello Kamil
I created the following patch to NetBSD7
based OpenBSD
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uchcom.c
Revision 1.20 that contains the following description
"It seems that there is new and old revision of CH340.
Previous uchcom(4) driver targeted old one, and new one could not work
because of uchcom_set_line_control() broke the value of
UCHCOM_REG_LCR1(0x18).
To support new CH340, uchcom_set_line_control() and uchcom_reset_chip()
have been overhauled. Current uchcom(4) does not change the value of
UCHCOM_REG_LCR1 register, it means even/odd parity mode is no longer
supported with old CH340."
dm4# cvs diff sys/dev/usb/
cvs diff: Diffing .
cvs diff: Diffing sys
cvs diff: Diffing sys/dev
cvs diff: Diffing sys/dev/usb
Index: sys/dev/usb/uchcom.c
===================================================================
RCS file: /cvsroot/src/sys/dev/usb/uchcom.c,v
retrieving revision 1.13
diff -r1.13 uchcom.c
105,111d104
< #define UCHCOM_LCR1_MASK 0xAF
< #define UCHCOM_LCR2_MASK 0x07
< #define UCHCOM_LCR1_PARENB 0x80
< #define UCHCOM_LCR2_PAREVEN 0x07
< #define UCHCOM_LCR2_PARODD 0x06
< #define UCHCOM_LCR2_PARMARK 0x05
< #define UCHCOM_LCR2_PARSPACE 0x04
116a110,116
> /*
> * XXX - these magic numbers come from Linux (drivers/usb/serial/ch341.c).
> * The manufacturer was unresponsive when asked for documentation.
> */
> #define UCHCOM_RESET_VALUE 0x501F /* line mode? */
> #define UCHCOM_RESET_INDEX 0xD90A /* baud rate? */
>
718,730d717
< usbd_status err;
< uint8_t lcr1val = 0, lcr2val = 0;
<
< err = read_reg(sc, UCHCOM_REG_LCR1, &lcr1val, UCHCOM_REG_LCR2,
&lcr2val);
< if (err) {
< aprint_error_dev(sc->sc_dev, "cannot get LCR: %s\n",
< usbd_errstr(err));
< return EIO;
< }
<
< lcr1val &= ~UCHCOM_LCR1_MASK;
< lcr2val &= ~UCHCOM_LCR2_MASK;
<
749,762c736,737
< if (ISSET(cflag, PARENB)) {
< lcr1val |= UCHCOM_LCR1_PARENB;
< if (ISSET(cflag, PARODD))
< lcr2val |= UCHCOM_LCR2_PARODD;
< else
< lcr2val |= UCHCOM_LCR2_PAREVEN;
< }
<
< err = write_reg(sc, UCHCOM_REG_LCR1, lcr1val, UCHCOM_REG_LCR2,
lcr2val);
< if (err) {
< aprint_error_dev(sc->sc_dev, "cannot set LCR: %s\n",
< usbd_errstr(err));
< return EIO;
< }
---
> if (ISSET(cflag, PARENB) || ISSET(cflag, CSTOPB))
> return EINVAL;
787,811d761
< uint8_t lcr1val, lcr2val, pre, div, mod;
< uint16_t val=0, idx=0;
<
< err = read_reg(sc, UCHCOM_REG_LCR1, &lcr1val, UCHCOM_REG_LCR2,
&lcr2val);
< if (err)
< goto failed;
<
< err = read_reg(sc, UCHCOM_REG_BPS_PRE, &pre, UCHCOM_REG_BPS_DIV,
&div);
< if (err)
< goto failed;
<
< err = read_reg(sc, UCHCOM_REG_BPS_MOD, &mod, UCHCOM_REG_BPS_PAD,
NULL);
< if (err)
< goto failed;
<
< val |= (uint16_t)(lcr1val&0xF0) << 8;
< val |= 0x01;
< val |= (uint16_t)(lcr2val&0x0F) << 8;
< val |= 0x02;
< idx |= pre & 0x07;
< val |= 0x04;
< idx |= (uint16_t)div << 8;
< val |= 0x08;
< idx |= mod & 0xF8;
< val |= 0x10;
816c766,769
< err = generic_control_out(sc, UCHCOM_REQ_RESET, val, idx);
---
> err = generic_control_out(sc, UCHCOM_REQ_RESET,
> UCHCOM_RESET_VALUE,
> UCHCOM_RESET_INDEX);
>
and now the USB-Serial converter works as we can see below:
dm4# *tip ttyU0-9600*
connected
NetBSD/amd64 (netbsd7.XXXXXXX.net) (console)
login: root
Password:
Jun 10 23:31:43 netbsd7 login: ROOT LOGIN (root) on tty console
Last login: Wed Jun 10 23:11:17 2015 on console
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 7.0_BETA (GENERIC) #0: Wed May 13 01:37:49 BRT 2015
You have new mail.
Terminal type is vt100.
We recommend that you create a non-root account and use su(1) for root
access.
netbsd7# ~
[EOT]
with the following line in the file /etc/remote:
ttyU0-9600:dv=/dev/ttyU0:br#9600:pa=none:dc:
It would be nice if someone more experienced than I can review the patch
Vicente.
On 10/06/2015 19:35, Kamil Rytarowski wrote:
> On 10.06.2015 18:49, Vicente Chaves de Melo wrote:
>> Hi Kamil,
>> sorry to intrude but you managed to solve this problem?
>> I believe I have exactly the same USB-Serial converter described in this
>> PR.
>> And I couldn't make it work with NetBSD7 + tip, although run smoothly
>> with OpenBSD 5.7 + tip, Linux + minicom and even with Windows + putty .
>> In advance, thank you very much for your attention.
> I ran out of time to test it on others than NetBSD platforms. I had
> problems with Linux as well and switched to other serial.
>
> If you like you can take this problem and backport OpenBSD enhancements
> and I will test them.
>
> When I will get a free metal to install there OpenBSD I will test it there.
> .
>
--------------090103040904040800000404
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello Kamil<br>
I created the following patch to NetBSD7<br>
based OpenBSD
<a class="moz-txt-link-freetext" href="http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uchcom.c">http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uchcom.c</a>
Revision 1.20 that contains the following description<br>
<br>
"It seems that there is new and old revision of CH340.<br>
Previous uchcom(4) driver targeted old one, and new one could not
work<br>
because of uchcom_set_line_control() broke the value of<br>
UCHCOM_REG_LCR1(0x18).<br>
<br>
To support new CH340, uchcom_set_line_control() and
uchcom_reset_chip()<br>
have been overhauled. Current uchcom(4) does not change the value of<br>
UCHCOM_REG_LCR1 register, it means even/odd parity mode is no longer<br>
supported with old CH340."<br>
<br>
dm4# cvs diff sys/dev/usb/<br>
cvs diff: Diffing .<br>
cvs diff: Diffing sys<br>
cvs diff: Diffing sys/dev<br>
cvs diff: Diffing sys/dev/usb<br>
Index: sys/dev/usb/uchcom.c<br>
===================================================================<br>
RCS file: /cvsroot/src/sys/dev/usb/uchcom.c,v<br>
retrieving revision 1.13<br>
diff -r1.13 uchcom.c<br>
105,111d104<br>
< #define UCHCOM_LCR1_MASK 0xAF<br>
< #define UCHCOM_LCR2_MASK 0x07<br>
< #define UCHCOM_LCR1_PARENB 0x80<br>
< #define UCHCOM_LCR2_PAREVEN 0x07<br>
< #define UCHCOM_LCR2_PARODD 0x06<br>
< #define UCHCOM_LCR2_PARMARK 0x05<br>
< #define UCHCOM_LCR2_PARSPACE 0x04<br>
116a110,116<br>
> /*<br>
> * XXX - these magic numbers come from Linux
(drivers/usb/serial/ch341.c).<br>
> * The manufacturer was unresponsive when asked for
documentation.<br>
> */<br>
> #define UCHCOM_RESET_VALUE 0x501F /* line mode?
*/<br>
> #define UCHCOM_RESET_INDEX 0xD90A /* baud rate?
*/<br>
><br>
718,730d717<br>
< usbd_status err;<br>
< uint8_t lcr1val = 0, lcr2val = 0;<br>
<<br>
< err = read_reg(sc, UCHCOM_REG_LCR1,
&lcr1val, UCHCOM_REG_LCR2, &lcr2val);<br>
< if (err) {<br>
< aprint_error_dev(sc->sc_dev, "cannot
get LCR: %s\n",<br>
< usbd_errstr(err));<br>
< return EIO;<br>
< }<br>
<<br>
< lcr1val &= ~UCHCOM_LCR1_MASK;<br>
< lcr2val &= ~UCHCOM_LCR2_MASK;<br>
<<br>
749,762c736,737<br>
< if (ISSET(cflag, PARENB)) {<br>
< lcr1val |= UCHCOM_LCR1_PARENB;<br>
< if (ISSET(cflag, PARODD))<br>
< lcr2val |= UCHCOM_LCR2_PARODD;<br>
< else<br>
< lcr2val |= UCHCOM_LCR2_PAREVEN;<br>
< }<br>
<<br>
< err = write_reg(sc, UCHCOM_REG_LCR1, lcr1val,
UCHCOM_REG_LCR2, lcr2val);<br>
< if (err) {<br>
< aprint_error_dev(sc->sc_dev, "cannot
set LCR: %s\n",<br>
< usbd_errstr(err));<br>
< return EIO;<br>
< }<br>
---<br>
> if (ISSET(cflag, PARENB) || ISSET(cflag,
CSTOPB))<br>
> return EINVAL;<br>
787,811d761<br>
< uint8_t lcr1val, lcr2val, pre, div, mod;<br>
< uint16_t val=0, idx=0;<br>
<<br>
< err = read_reg(sc, UCHCOM_REG_LCR1,
&lcr1val, UCHCOM_REG_LCR2, &lcr2val);<br>
< if (err)<br>
< goto failed;<br>
<<br>
< err = read_reg(sc, UCHCOM_REG_BPS_PRE, &pre,
UCHCOM_REG_BPS_DIV, &div);<br>
< if (err)<br>
< goto failed;<br>
<<br>
< err = read_reg(sc, UCHCOM_REG_BPS_MOD, &mod,
UCHCOM_REG_BPS_PAD, NULL);<br>
< if (err)<br>
< goto failed;<br>
<<br>
< val |= (uint16_t)(lcr1val&0xF0) << 8;<br>
< val |= 0x01;<br>
< val |= (uint16_t)(lcr2val&0x0F) << 8;<br>
< val |= 0x02;<br>
< idx |= pre & 0x07;<br>
< val |= 0x04;<br>
< idx |= (uint16_t)div << 8;<br>
< val |= 0x08;<br>
< idx |= mod & 0xF8;<br>
< val |= 0x10;<br>
816c766,769<br>
< err = generic_control_out(sc, UCHCOM_REQ_RESET,
val, idx);<br>
---<br>
> err = generic_control_out(sc, UCHCOM_REQ_RESET,<br>
> UCHCOM_RESET_VALUE,<br>
> UCHCOM_RESET_INDEX);<br>
><br>
<br>
and now the USB-Serial converter works as we can see below:<br>
<br>
dm4# tip ttyU0-9600<br>
connected<br>
<br>
<br>
NetBSD/amd64 (netbsd7.XXXXXXX.net) (console)<br>
<br>
login: root<br>
Password:<br>
Jun 10 23:31:43 netbsd7 login: ROOT LOGIN (root) on tty
console<br>
Last login: Wed Jun 10 23:11:17 2015 on console<br>
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002,
2003, 2004, 2005,<br>
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014<br>
The NetBSD Foundation, Inc. All rights reserved.<br>
Copyright (c) 1982, 1986, 1989, 1991, 1993<br>
The Regents of the University of California. All
rights reserved.<br>
<br>
NetBSD 7.0_BETA (GENERIC) #0: Wed May 13 01:37:49 BRT 2015<br>
<br>
You have new mail.<br>
Terminal type is vt100.<br>
We recommend that you create a non-root account and use
su(1) for root access.<br>
netbsd7# ~<br>
[EOT]<br>
<br>
with the following line in the file /etc/remote:<br>
ttyU0-9600:dv=/dev/ttyU0:br#9600:pa=none:dc:<br>
<br>
It would be nice if someone more experienced than I can review the
patch<br>
<br>
Vicente.<br>
<br>
<div class="moz-cite-prefix">On 10/06/2015 19:35, Kamil Rytarowski
wrote:<br>
</div>
<blockquote cite="mid:5578BBCF.3040704@gmx.com" type="cite">
<pre wrap="">On 10.06.2015 18:49, Vicente Chaves de Melo wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Kamil,
sorry to intrude but you managed to solve this problem?
I believe I have exactly the same USB-Serial converter described in this
PR.
And I couldn't make it work with NetBSD7 + tip, although run smoothly
with OpenBSD 5.7 + tip, Linux + minicom and even with Windows + putty .
In advance, thank you very much for your attention.
</pre>
</blockquote>
<pre wrap="">
I ran out of time to test it on others than NetBSD platforms. I had
problems with Linux as well and switched to other serial.
If you like you can take this problem and backport OpenBSD enhancements
and I will test them.
When I will get a free metal to install there OpenBSD I will test it there.
.
</pre>
</blockquote>
<br>
</body>
</html>
--------------090103040904040800000404--
From: christos@zoulas.com (Christos Zoulas)
To: Vicente Chaves de Melo <vicente.melo.br@ieee.org>,
Kamil Rytarowski <n54@gmx.com>, gnats-bugs@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/49115
Date: Wed, 10 Jun 2015 23:15:49 -0400
On Jun 10, 11:48pm, vicente.melo.br@ieee.org (Vicente Chaves de Melo) wrote:
-- Subject: Re: kern/49115
| Hello Kamil
| I created the following patch to NetBSD7
| based OpenBSD
| http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uchcom.c
| Revision 1.20 that contains the following description
|
| "It seems that there is new and old revision of CH340.
| Previous uchcom(4) driver targeted old one, and new one could not work
| because of uchcom_set_line_control() broke the value of
| UCHCOM_REG_LCR1(0x18).
|
| To support new CH340, uchcom_set_line_control() and uchcom_reset_chip()
| have been overhauled. Current uchcom(4) does not change the value of
| UCHCOM_REG_LCR1 register, it means even/odd parity mode is no longer
| supported with old CH340."
Yes, but it looks like the new driver uses more magic values. Perhaps
there is a way to reverse engineer what's going on and make it work
properly for both.
christos
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.