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>
     &lt; #define UCHCOM_LCR1_MASK      0xAF<br>
     &lt; #define UCHCOM_LCR2_MASK      0x07<br>
     &lt; #define UCHCOM_LCR1_PARENB    0x80<br>
     &lt; #define UCHCOM_LCR2_PAREVEN   0x07<br>
     &lt; #define UCHCOM_LCR2_PARODD    0x06<br>
     &lt; #define UCHCOM_LCR2_PARMARK   0x05<br>
     &lt; #define UCHCOM_LCR2_PARSPACE  0x04<br>
     116a110,116<br>
     &gt; /*<br>
     &gt; * XXX - these magic numbers come from Linux
       (drivers/usb/serial/ch341.c).<br>
     &gt; * The manufacturer was unresponsive when asked for
       documentation.<br>
     &gt; */<br>
     &gt; #define UCHCOM_RESET_VALUE      0x501F  /* line mode?
       */<br>
     &gt; #define UCHCOM_RESET_INDEX      0xD90A  /* baud rate?
       */<br>
     &gt;<br>
     718,730d717<br>
     &lt;       usbd_status err;<br>
     &lt;       uint8_t lcr1val = 0, lcr2val = 0;<br>
     &lt;<br>
     &lt;       err = read_reg(sc, UCHCOM_REG_LCR1,
       &amp;lcr1val, UCHCOM_REG_LCR2, &amp;lcr2val);<br>
     &lt;       if (err) {<br>
     &lt;               aprint_error_dev(sc-&gt;sc_dev, "cannot
       get LCR: %s\n",<br>
     &lt;                   usbd_errstr(err));<br>
     &lt;               return EIO;<br>
     &lt;       }<br>
     &lt;<br>
     &lt;       lcr1val &amp;= ~UCHCOM_LCR1_MASK;<br>
     &lt;       lcr2val &amp;= ~UCHCOM_LCR2_MASK;<br>
     &lt;<br>
     749,762c736,737<br>
     &lt;       if (ISSET(cflag, PARENB)) {<br>
     &lt;               lcr1val |= UCHCOM_LCR1_PARENB;<br>
     &lt;               if (ISSET(cflag, PARODD))<br>
     &lt;                       lcr2val |= UCHCOM_LCR2_PARODD;<br>
     &lt;               else<br>
     &lt;                       lcr2val |= UCHCOM_LCR2_PAREVEN;<br>
     &lt;       }<br>
     &lt;<br>
     &lt;       err = write_reg(sc, UCHCOM_REG_LCR1, lcr1val,
       UCHCOM_REG_LCR2, lcr2val);<br>
     &lt;       if (err) {<br>
     &lt;               aprint_error_dev(sc-&gt;sc_dev, "cannot
       set LCR: %s\n",<br>
     &lt;                   usbd_errstr(err));<br>
     &lt;               return EIO;<br>
     &lt;       }<br>
     ---<br>
     &gt;       if (ISSET(cflag, PARENB) || ISSET(cflag,
       CSTOPB))<br>
     &gt;               return EINVAL;<br>
     787,811d761<br>
     &lt;       uint8_t lcr1val, lcr2val, pre, div, mod;<br>
     &lt;       uint16_t val=0, idx=0;<br>
     &lt;<br>
     &lt;       err = read_reg(sc, UCHCOM_REG_LCR1,
       &amp;lcr1val, UCHCOM_REG_LCR2, &amp;lcr2val);<br>
     &lt;       if (err)<br>
     &lt;               goto failed;<br>
     &lt;<br>
     &lt;       err = read_reg(sc, UCHCOM_REG_BPS_PRE, &amp;pre,
       UCHCOM_REG_BPS_DIV, &amp;div);<br>
     &lt;       if (err)<br>
     &lt;               goto failed;<br>
     &lt;<br>
     &lt;       err = read_reg(sc, UCHCOM_REG_BPS_MOD, &amp;mod,
       UCHCOM_REG_BPS_PAD, NULL);<br>
     &lt;       if (err)<br>
     &lt;               goto failed;<br>
     &lt;<br>
     &lt;       val |= (uint16_t)(lcr1val&amp;0xF0) &lt;&lt; 8;<br>
     &lt;       val |= 0x01;<br>
     &lt;       val |= (uint16_t)(lcr2val&amp;0x0F) &lt;&lt; 8;<br>
     &lt;       val |= 0x02;<br>
     &lt;       idx |= pre &amp; 0x07;<br>
     &lt;       val |= 0x04;<br>
     &lt;       idx |= (uint16_t)div &lt;&lt; 8;<br>
     &lt;       val |= 0x08;<br>
     &lt;       idx |= mod &amp; 0xF8;<br>
     &lt;       val |= 0x10;<br>
     816c766,769<br>
     &lt;       err = generic_control_out(sc, UCHCOM_REQ_RESET,
       val, idx);<br>
     ---<br>
     &gt;       err = generic_control_out(sc, UCHCOM_REQ_RESET,<br>
     &gt;                               UCHCOM_RESET_VALUE,<br>
     &gt;                               UCHCOM_RESET_INDEX);<br>
     &gt;<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

NetBSD Home
NetBSD PR Database Search

(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.