From nobody Fri Oct 08 07:34:13 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 5D9E812D612B for ; Fri, 8 Oct 2021 07:34:24 +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 4HQg1W4MXxz4m5f for ; Fri, 8 Oct 2021 07:34:23 +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:34:21 +0200 id 00DCA813.615FF47D.000149AD Date: Fri, 8 Oct 2021 09:34:13 +0200 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: Persistent USB serial? Message-ID: <20211008093413.19e7acd2@zeta.dino.sk> In-Reply-To: <20211008072537.vytjzyqol5cksy5d@nerd-thinkpad.local> References: <20211008080016.7830e3d5@zeta.dino.sk> <20211008072537.vytjzyqol5cksy5d@nerd-thinkpad.local> 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: 4HQg1W4MXxz4m5f 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.831]; 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 09:25:37 +0200 Daniel Ebdrup Jensen wrote: > On Fri, Oct 08, 2021 at 08:00:16AM +0200, Milan Obuch wrote: > >Hi, > > > >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? > > > >Regards, > >Milan > > > > Hi Milan, > > There's an open review [1] for location-based unit numbering for USB, > which some of us have been using for quite some time - and while it's > not completely done, it's very useful. > > Yours, > Daniel Ebdrup Jensen > > 1: https://reviews.freebsd.org/D21886 Thanks for pointer, I'll try to evaluate. This does not give me a full solution, if I understand it right - I can have some unique name for a given USB serial port instance, but I still must write my command to attach to this port quickly in order to not miss first characters sent over this port, right? Regards, Milan