From owner-freebsd-embedded@freebsd.org Mon Mar 16 20:37:25 2020 Return-Path: Delivered-To: freebsd-embedded@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A6C0126ED85 for ; Mon, 16 Mar 2020 20:37:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48h7QY05qJz4ZZ9 for ; Mon, 16 Mar 2020 20:37:24 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1584391043; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Z0o86QjY8JGEz31ZfDsqIELXkbOJvYslwD7hYstrLsrXPqKmoj2NlNS740OFHPHClnAHaZr4ojtM5 TVjHLBJOJnSxxttMyHwFiJWImrZEdXM3VSDs0b37X6Y60mrX3qeNAw7E0VKs2PqjHqcmrRRpY/zKLg l3I4pDrDpydnPaXrzCF7H4zoQl5rYKacKEjNrz4E7p87bgfzJ0UNILFjaCe2ZR8larQBSgFk7qmGCr H6EykolDslcEVIN7Zt+jAu9xUkACkK2+j8oBcqLjACjCBmjNyD1xCMUpVfPhpHsPyz8RhIzvJUKx3I Bv15JxIp/PYBALSCwf0e+vRvlSNK+ow== 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:cc:to:from:subject:message-id:dkim-signature:from; bh=5nyCKiJxCQfbQtdOEcgSUsmWM2PUgWhtyDdX33I6Ysk=; b=SfaDE8AxwW4O0SLWNIB1JwL0Yyr4z2SjEBJXalVTJzaymvvCzrV24PSncUXqI+hw7NRoN32YY/MAH fW9vMTL25f3Mle55YW0/uOj4sgW6rBFeKCVpchZ2HZaARKGFmE/AnBZCVyH4hUHQKEHWaqqjdQ5ogd DJs3B/kN4WpyMopl9+08p3r1H0m11NqGYkVrjy+tf4M14c3vUQjq5zND+YjumOb03i18LJAYRjr+Xp f/q88Oy4LGDiXoy5nB/i8ZKRPl97J5V8tAq6BInUShUa38CN1RR9aek2gVi6eYoiHnTwyM3iv2GhVn b1v66GRGba4xlJpx1DzNPDjxMkwaqmg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; 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:cc:to:from:subject:message-id:from; bh=5nyCKiJxCQfbQtdOEcgSUsmWM2PUgWhtyDdX33I6Ysk=; b=clidETpmbViX0Zk6/ddVTVt5jeV2m7sxM/e4JFTZoUY2DsPtJ32vfTawZPLXflvSxk+f6GbA2Hcs0 Seq4bW6xCsvt/8TR+UoK9xGKmed8Hl/IwNDBUkGjWBVe7iBdgeZzy84+eQhv1eI3snsUuRAUG7x7CO 3a0q5LGfR9b+MZRQ4NszJl7hGa/BY4c2Na1NGAdWPDTBnqg0nsA1zW4NEA9tVlEeSu8sXYbAbFy5k9 3bhEenqP29/lBCTD0FkdnKGSO1aUqzoIi37bVpUG4rBAR6qGwgFgarK9IY57ostVxT4SzwDn37Mcsl UHT2cRsqeG7nsr5AxnwofAPc7rWRjrA== X-MHO-RoutePath: aGlwcGll X-MHO-User: ef03752e-67c5-11ea-9eb3-25e2dfa9fa8d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id ef03752e-67c5-11ea-9eb3-25e2dfa9fa8d; Mon, 16 Mar 2020 20:37:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 02GKbKDh069418; Mon, 16 Mar 2020 14:37:20 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <3bfdda47d68ad3300bc12178ff9ddc939bef9d46.camel@freebsd.org> Subject: Re: STM32 not identified From: Ian Lepore To: bmelo Cc: "freebsd-embedded@freebsd.org" Date: Mon, 16 Mar 2020 14:37:20 -0600 In-Reply-To: <1XBw5X1NatiMuyWhr7sMj-_NVC_2uQxwdcUvYJeSkHSq8SAGXcyabJQXQoscmfjXZ_T_22qkxfCCUvq6aIV9bkpOk6ilz_I4h-qBKNm0Fw4=@protonmail.com> References: <2e1b00c4213037f308417c902291e0a88c06674b.camel@freebsd.org> <7ee5309c7ba196a23e4030dbb0883525fd38f971.camel@freebsd.org> <1XBw5X1NatiMuyWhr7sMj-_NVC_2uQxwdcUvYJeSkHSq8SAGXcyabJQXQoscmfjXZ_T_22qkxfCCUvq6aIV9bkpOk6ilz_I4h-qBKNm0Fw4=@protonmail.com> Content-Type: text/plain; charset="iso-2022-jp" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48h7QY05qJz4ZZ9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.03 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.95)[0.947,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-0.91)[-0.914,0] X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 20:37:25 -0000 On Mon, 2020-03-16 at 20:24 +0000, bmelo wrote: > > I don't have anything in my devfs.conf at all. So do /dev/cuaU* > > devices have the right permissions when you plug in an adapter? Do > > you > > just need to unplug/replug it to force the permissions to change? > > The permmission is actually this even replugging: > crw-rw-rw- 1 uucp dialer - 0x29f Mar 16 17:22 /dev/cuaU0 > rw-rw-rw- 1 root wheel - 0x29c Mar 16 17:22 /dev/ttyU0 > Okay, then it shouldn't be a permission problem anymore, because the whole world can open that device now. I suspect the cuaU* devices are getting created because an ftdi (or similar) usb-serial adapter is involved. But it's likely your st-util program isn't accessing cuaU*, it's probably using libusb and opening the ugen device directly. That's why my rules include these two: add path "usb/*" mode 0666 add path "usb" mode 0755 Yours has this, which looks wrong: add path 'usb/\' mode 666 probably should be usb/* -- Ian > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > On Monday, 16 de March de 2020 s 17:02, Ian Lepore > > > ian@freebsd.org > > > wrote: > > > > > > > On Mon, 2020-03-16 at 16:46 +0000, bmelo wrote: > > > > > > > > > Here is my devfs.rules: > > > > > [devfsrules_common=7] > > > > > add path 'ad[0-9]\' mode 666 > > > > > add path 'ada[0-9]\' mode 666add path 'da[0-9]\' mode 666 > > > > > add path 'acd[0-9]\' mode 666add path 'cd[0-9]\' mode 666 > > > > > add path 'cuaU[0-9]\' mode 666add path 'mmcsd[0-9]\' mode 666 > > > > > add path 'pass[0-9]\' mode 666add path 'xpt[0-9]\' mode 666 > > > > > add path 'ugen[0-9]\' mode 666add path 'usbctl' mode 666 > > > > > add path 'usb/\' mode 666 > > > > > add path 'ttyU[0-9]\' mode 666add path 'lpt[0-9]\' mode 666 > > > > > add path 'ulpt[0-9]\' mode 666add path 'unlpt[0-9]\' mode 666 > > > > > add path 'fd[0-9]\' mode 666add path 'uscan[0-9]\' mode 666 > > > > > add path 'video[0-9]\' mode 666add path 'tuner[0-9]' mode 666 > > > > > add path 'dvb/\' mode 666add path 'cx88*' mode 0660 > > > > > add path 'iicdev*' mode 0660 > > > > > add path 'uvisor[0-9]*' mode 0660 > > > > > > > > I suspect the escaped wildcards are causing a problem, try > > > > using > > > > "cuaU*" instead of "cuaU[0-9]\*" (and likewise for all the > > > > rules, I > > > > don't think there is any device that puts a literal * in the > > > > devfs > > > > name). > > > > -- Ian > > > > > > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > > > On Monday, 16 de March de 2020 s 13:23, Ian Lepore > > > > > ian@freebsd.org > > > > > wrote: > > > > > > > > > > > On Mon, 2020-03-16 at 12:23 +0000, bmelo via freebsd- > > > > > > embedded > > > > > > wrote: > > > > > > > > > > > > > Hi, I have a STM32 Nucleo board and installed stlink from > > > > > > > ports > > > > > > > here. > > > > > > > But all the time I run st-util command I get the message: > > > > > > > WARN usb.c: Couldn't find any ST-Link/V2 devices > > > > > > > The Nucleo creates cuaU0 and ttyU0 in /dev. It seems like > > > > > > > a > > > > > > > permission problem, but I have no idea how to fix that. I > > > > > > > already > > > > > > > tried to edit /etc/devfs.rules and the problem persists. > > > > > > > /dev/cuaU0 > > > > > > > is uucp:dialer and ttyU0 is root:wheel. > > > > > > > Any idea? > > > > > > > > > > > > You didn't saywhat you tried with devfs.rules. This is what > > > > > > I > > > > > > use > > > > > > (because I am the only user of this machine, so security is > > > > > > not > > > > > > a > > > > > > problem; these might not be good for a shared machine): > > > > > > [localrules=10] > > > > > > add path "ttyU*" mode 0666 > > > > > > add path "cuaU*" mode 0666 > > > > > > add path "ugen*" mode 0666 > > > > > > add path "usb/*" mode 0666 > > > > > > add path "usb" mode 0755 > > > > > > -- Ian > > >