Date: Mon, 16 Mar 2020 20:41:27 +0000 From: bmelo <bmelo@protonmail.com> To: Ian Lepore <ian@freebsd.org> Cc: "freebsd-embedded@freebsd.org" <freebsd-embedded@freebsd.org> Subject: Re: STM32 not identified Message-ID: <NZEL4RAoSG6DeXDMqVfFLE-WIE0SwV4pkQ0MhhEURnZQmbT-YlK3tgkUtnnm4ylK4q1Ai30qkM4GgKkVU8WVt6JrkzITzk6iueK_teZ3rDk=@protonmail.com> In-Reply-To: <3bfdda47d68ad3300bc12178ff9ddc939bef9d46.camel@freebsd.org> References: <bCyCGMfT-ROSVe2TXJJdJeOI3UkecbyDDrz8CTIcXPAoZwyKvYS4ZkgaQxMiXgvT7VNOTARJ0PLmbcvLU_WNxPPd578NDl0ZyZ7h_m8xSb0=@protonmail.com> <2e1b00c4213037f308417c902291e0a88c06674b.camel@freebsd.org> <PqPJsTGStXlx_9UIEWwnA7Z0ip3OgWhtZolrYRZz--dY3Wd1n9arptplfRd1LmBxQ6KA92JA7V33I6ZNrmq1oezPjb-Q3uuBZIfIzxbYziQ=@protonmail.com> <c0026f4471f409303b6cac0baa577cf49171c669.camel@freebsd.org> <lybzFIK-6d3lLjHZtLUI31RBVRZVM13ZLRXcBTIJe8DHZW2dBHv5wT4rtr0oe-5Gf3evY8l1mn9pOdCJFfrTPFiP6PKeFjS6elblV6xzvms=@protonmail.com> <7ee5309c7ba196a23e4030dbb0883525fd38f971.camel@freebsd.org> <1XBw5X1NatiMuyWhr7sMj-_NVC_2uQxwdcUvYJeSkHSq8SAGXcyabJQXQoscmfjXZ_T_22qkxfCCUvq6aIV9bkpOk6ilz_I4h-qBKNm0Fw4=@protonmail.com> <3bfdda47d68ad3300bc12178ff9ddc939bef9d46.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Done. Still not working =3D/ Sent from ProtonMail, Swiss-based encrypted email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, 16 de March de 2020 =C3=A0s 17:37, Ian Lepore <ian@freebsd.org> = wrote: > 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. > > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Ori= ginal Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90= =E2=80=90 > > > > 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=3D7] > > > > > > 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. > > > > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80= =90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80= =90=E2=80=90 > > > > > > 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=3D10] > > > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NZEL4RAoSG6DeXDMqVfFLE-WIE0SwV4pkQ0MhhEURnZQmbT-YlK3tgkUtnnm4ylK4q1Ai30qkM4GgKkVU8WVt6JrkzITzk6iueK_teZ3rDk=>