From nobody Fri Oct 8 07:26:32 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 409FD12D4E93 for ; Fri, 8 Oct 2021 07:26:50 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from nsstlmta19p.bpe.bigpond.com (nsstlmta19p.bpe.bigpond.com [203.38.21.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQfrn3sVgz4kb1 for ; Fri, 8 Oct 2021 07:26:49 +0000 (UTC) (envelope-from chrisj@rtems.org) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep19p-svc.bpe.nexus.telstra.com.au with ESMTP id <20211008072638.IYTE6690.nsstlfep19p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Fri, 8 Oct 2021 18:26:38 +1100 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvtddrudelledguddufecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucenucfjughrpefkffggfgfuvfhfhfhojggtgfesthejredttdefjeenucfhrhhomhepvehhrhhishculfhohhhnshcuoegthhhrihhsjhesrhhtvghmshdrohhrgheqnecuggftrfgrthhtvghrnhepkeehudegveejuedvkeeiieelleeijeeugeektefhfeeiveefgeelgfefueeugfdtnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecukfhppedufeelrddufedtrddvgeehrddvtddtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepmhgrihhlrdgtohhnthgvmhhpohhrrghrhidrnhgvthdrrghupdhinhgvthepudefledrudeftddrvdeghedrvddttddpmhgrihhlfhhrohhmpegthhhrihhsjhesrhhtvghmshdrohhrghdprhgtphhtthhopehfrhgvvggsshguqdhhrggtkhgvrhhsseguihhnohdrshhkpdhrtghpthhtohepfhhrvggvsghsugdqhhgrtghkvghrshesfhhrvggvsghsugdrohhrgh X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean Received: from mail.contemporary.net.au (139.130.245.200) by smtp.telstra.com (5.8.716.02) id 610B5E210D62B58D; Fri, 8 Oct 2021 18:26:37 +1100 Received: from [10.10.11.2] ([10.10.11.2]) (authenticated bits=0) by mail.contemporary.net.au (8.15.2/8.15.2) with ESMTPSA id 1987QWJn094995 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 8 Oct 2021 18:26:34 +1100 (EST) (envelope-from chrisj@rtems.org) Message-ID: <6510e27f-29f0-37a8-37b5-3b5b4e297b65@rtems.org> Date: Fri, 8 Oct 2021 18:26:32 +1100 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: Persistent USB serial? Content-Language: en-AU To: Milan Obuch , freebsd-hackers@freebsd.org References: <20211008080016.7830e3d5@zeta.dino.sk> From: Chris Johns Organization: https://www.rtems.org/ In-Reply-To: <20211008080016.7830e3d5@zeta.dino.sk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-104.9 required=2.7 tests=ALL_TRUSTED,BAYES_00, NICE_REPLY_A,USER_IN_WELCOMELIST,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on corb.contemporary.net.au X-Rspamd-Queue-Id: 4HQfrn3sVgz4kb1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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