From nobody Fri Oct 8 07:40:58 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8385112D7DFF for ; Fri, 8 Oct 2021 07:41:11 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQg9L4FgJz4nvd for ; Fri, 8 Oct 2021 07:41:10 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Fri, 08 Oct 2021 09:41:08 +0200 id 00DCA808.615FF614.00014A44 Date: Fri, 8 Oct 2021 09:40:58 +0200 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: Persistent USB serial? Message-ID: <20211008094058.0c0bd17f@zeta.dino.sk> In-Reply-To: <6510e27f-29f0-37a8-37b5-3b5b4e297b65@rtems.org> References: <20211008080016.7830e3d5@zeta.dino.sk> <6510e27f-29f0-37a8-37b5-3b5b4e297b65@rtems.org> X-Mailer: Claws Mail 3.18.0git266 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HQg9L4FgJz4nvd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-2.13 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.83)[-0.832]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 8 Oct 2021 18:26:32 +1100 Chris Johns wrote: > On 8/10/21 5:00 pm, Milan Obuch wrote: > > I'd like to solicit opinions/hints for following scenario, which is > > quite common currently. > > > > There are some development and evaluation boards designed with USB > > port as power source and serial console at the same time (sometimes > > even more ports or JTAG as well). When board has power on switch, > > usually no activity is present on USB wire without board being > > powered - there is some USB-to-UART circuitry powered from board > > power source. So serial port device /dev/cuaUn et al. get created > > only after power on of the board. > > > > Problem: port number can be different depending on USB port > > enumeration or connection order. Another one: it is easy to miss > > first characters sent from the board if you are not able to write > > required command like 'cu -l /dev/cuaU9 -s 115200' quickly. > > > > Maybe it is possible to write some devd config file snippet which > > ensures consistent device naming without need of maintaining correct > > (everytime the same) order of cable connecting, but even that, this > > does not solve second problem, starting up some terminal or terminal > > like program in time. > > > > Has anybody some experience in this area who can share it? Some > > hints what to test? Do we have some pseudo serial device, which can > > be used as device argument for cu command, which can just grab the > > real USB serial when it appears on connecting the board under test? > > > > It is something I have just had to live with it and with RTEMS we > suggest using `ser2net` [1] to handle the connection. I see > consistent enumerations once connected if the USB ports are not > moved. You could then wrap the telnet connection in something that > hammers the connection as fast as you need to pick up characters. It > is not prefect but it is ok and simple to implement. > > The actual issue is usually a bug in the USB UART circuit on the > target. > > Chris > > [1] I recently raised a bug against ser2net on FreeBSD .. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258382 > I have no idea what ser2net does, I'll check what it is and how I can possibly use it. Thanks for pointer. Regards, Milan