From nobody Fri Oct 08 14:20:23 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 DEA1C12DD529 for ; Fri, 8 Oct 2021 14:20:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQr2445dMz4XVP for ; Fri, 8 Oct 2021 14:20:28 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1633702827; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=sOGAbVyRKJ0WRypaLf7ib6LlSMvG5kQPKPV0PGg6S/AQOncebPw1HtzqKc+jrVeBVjp1R8xEZ0gXs wsC+VsL7mJOt9AkbYuAnkcc+o0311SQLlF4Y3IzGnx457qdpDEkbava03jb7r3B/ZHAYbr9J6T8uuB MXE09j6IVO6LoVsJBezzC/Ujktw1WNip8eallq5j8NhY/X0U/8R7WabTxYygCICMhcw1x8WjjkBF/f r/VhQbvjuTyLP4mzVO1zGeUv7LYg2eQK+4UPlS3np6IkqqlDc0JnNPQelCrDh4lqzuleS2njS8K5sU iNfCvv+X4YtVUwEsi0y8qSOLwJfrh/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=i8TVUjKoiXGFY1qKe1p93IIHKsz4kKv9uWLXZNkaDkc=; b=t2BUEdL8MiZwOwgyyGuTmPce4ARkIbueY70ObSARs9KpWxa8U2E8vhrCtBnC0estadYsuvEr2yYyC 6SkyqOsTuBAvVMgXsqeKh5L0spQX6KrKxl+/CrZRKK1wN9W+oXvMPdH7/Drg+x+jc6M9ktEbYSySfg d65RQFDIi+VTJQPSz5Zzg3c2pFtOFK0WMpcvsQ3vpvRG/TlR0nxWSvjyIEtWQr6jm4wEKzBlQOTlQq 1aFe3V/01oDGS76cmGsAAcxKVPCf/MEm7TU8Cflbf+H0IEX30tek7AInH9md1beMizQg3kpNcs9jSk Axo4GAEAIQmxud0Fm/GkHM1LNDUwdlg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=24.8.225.114; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=i8TVUjKoiXGFY1qKe1p93IIHKsz4kKv9uWLXZNkaDkc=; b=vAmf6MSWCoECnZo7f7/DthK0mCqJC1BfJUow7C7dKoB8iHrMktLbdEfR4vMsqF8hbEBkJkaIpLuhR LMv97nD5YjyXy+kt39YTGB3k9ul8YpSOpjx1v36AbCg0/+2w6iVyo5icnWRsbIkxj/9NC0P0uNWYM2 wtKI6b7zI0sY6HXO1hNAAyT7QdAbqOU0B7fWLTbmFZYU6x5swfM8O8OKKrwFgSwfvWZdSi3sxfagsT 6H7wY+mnKWcwXvrgo4/z7/+ufCn38fdBI0d9M1wHyxu3q3ZPPyjd4wJEeBISETq6XglVkuaRCoQNRE yVkZQ+rueAVx5u1VFENCUDW+P/1P71A== X-Originating-IP: 24.8.225.114 X-MHO-RoutePath: aGlwcGll X-MHO-User: e0dbc496-2842-11ec-9b08-bf9d68d023b6 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-24-8-225-114.hsd1.co.comcast.net [24.8.225.114]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id e0dbc496-2842-11ec-9b08-bf9d68d023b6; Fri, 08 Oct 2021 14:20:26 +0000 (UTC) Received: from [172.22.42.84] (rev2.hippie.lan [172.22.42.84]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 198EKNvj025481; Fri, 8 Oct 2021 08:20:24 -0600 (MDT) (envelope-from ian@freebsd.org) X-Authentication-Warning: paranoia.hippie.lan: Host rev2.hippie.lan [172.22.42.84] claimed to be [172.22.42.84] Message-ID: <11af95cf3d72616823ed5ce3113b33c5154a4775.camel@freebsd.org> Subject: Re: Persistent USB serial? From: Ian Lepore To: Milan Obuch , freebsd-hackers@freebsd.org Date: Fri, 08 Oct 2021 08:20:23 -0600 In-Reply-To: <20211008080016.7830e3d5@zeta.dino.sk> References: <20211008080016.7830e3d5@zeta.dino.sk> Content-Type: text/plain; charset="ASCII" User-Agent: Evolution 3.40.3 FreeBSD GNOME Team 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-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HQr2445dMz4XVP 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 Fri, 2021-10-08 at 08:00 +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 > If the device on the other side of the usb serial adapter is already sending data when you attach the adapter to the freebsd system, you will lose data and/or get corrupted data. There is nothing you can do about it. Opening a usb-serial device involves a 100ms sleep (in usb_serial.c). For every config command sent to the device (change speed, change line parameters such as asserting DTR), there is another 100ms sleep. Because of the freebsd line config mechanisms (.init and .lock files) there is a surprising amount of config traffic that happens when you open a tty device -- it configures everything based on .init and .lock files, then the app opening the device will reconfigure everything again. For usb serial you can see all that happening with usbdump(8). A 115200 connection is roughly 11 kbytes data per second, and it takes up to a second to open a usb-serial device. The ftdi on-chip fifo is only 384 bytes on the older-generation chips (the common ones), and even on the modern H-series chips the fifo is only 2K or 4K depending on chip model. So the fifo can't hold enough data to capture everything arriving during during the open-and-config sequence. Even if it could, some of the data would have arrived at the wrong line speed and will just be garbage. -- Ian