Topics

Linux scanning USB at boot, assign /dev/ttyUSB labels


 

Hmm.. the Microchip parts don’t seem to follow the rules. 

This is what I get when I do ls -lrats in /dev
[snip]
0 drwxrwxrwt   2 root root          40 May 31 07:13 shm
0 crw-rw----   1 root dialout 166,   0 Jun  6 18:14 ttyACM0
0 crw-rw----   1 root dialout 188,   0 Jun  6 18:14 ttyUSB0
0 crw-rw----   1 root dialout 166,   1 Jun  6 18:14 ttyACM1
0 crw-rw-rw-   1 root tty       5,   2 Jun  6 18:16 ptmx
pi@taddnode:/dev $ 

Then here is what I get in /dev/serial/by-id
pi@taddnode:/dev/serial/by-id $ ls -lrats
total 0
0 drwxr-xr-x 4 root root 80 May 31 06:17 ..
0 lrwxrwxrwx 1 root root 13 May 31 06:17 usb-Microchip_Technology_Inc._MCP2221_USB-I2C_UART_Combo-if00 -> ../../ttyACM0
0 lrwxrwxrwx 1 root root 13 May 31 06:17 usb-FTDI_UMFT234XF_FT0O47N0-if00-port0 -> ../../ttyUSB0
0 drwxr-xr-x 2 root root 80 May 31 06:17 .
pi@taddnode:/dev/serial/by-id $ 

Only one of the ttyACM ports is showing in by-id.  Is this because they can’t be distinguished from one another?  


Tadd Torborg 




On Jun 6, 2020, at 6:07 PM, Chuck M via groups.io <cam51mail@...> wrote:

Here's what I mentioned earlier today and the udev rules (need to check those myself)
Info from using command dmesg:
****
usb 1-1.3: Product: CQXIEGUirtual COM Port
usb 1-1.3: Manufacturer: CQXiEGULinzhian
usb 1-1.3: SerialNumber: 48F5673D3234

***
string used in flrig for serial port to radio:
***
/dev/serial/by-id/usb-CQXiEGULinzhian_CQXIEGUirtual_COM_Port_48F5673D3234-if00
***
The usb 1-1.nnnn can change depending on how I have stuff connected.  the string above finds it anyway.  Assuming the "-if00" after serial number is something required by the udev rules.

Hope this example helps.

Chuck
KD9DVB

On Saturday, June 6, 2020, 03:07:36 PM EDT, David Birnbaum <dbirnbau@...> wrote:


What you want is to write udev rules. There's stuff online that shows how to do it; you need two numbers for each device.  Your printout has these: MODEL_ID and VENDOR_ID.  These two hex numbers go into the udev rule which will then always assign a name of your choice for the device regardless of where it's plugged in or in what order.

dave
k2lyv


Chuck M
 

Here's what I mentioned earlier today and the udev rules (need to check those myself)
Info from using command dmesg:
****
usb 1-1.3: Product: CQXIEGUirtual COM Port
usb 1-1.3: Manufacturer: CQXiEGULinzhian
usb 1-1.3: SerialNumber: 48F5673D3234

***
string used in flrig for serial port to radio:
***
/dev/serial/by-id/usb-CQXiEGULinzhian_CQXIEGUirtual_COM_Port_48F5673D3234-if00
***
The usb 1-1.nnnn can change depending on how I have stuff connected.  the string above finds it anyway.  Assuming the "-if00" after serial number is something required by the udev rules.

Hope this example helps.

Chuck
KD9DVB

On Saturday, June 6, 2020, 03:07:36 PM EDT, David Birnbaum <dbirnbau@...> wrote:


What you want is to write udev rules. There's stuff online that shows how to do it; you need two numbers for each device.  Your printout has these: MODEL_ID and VENDOR_ID.  These two hex numbers go into the udev rule which will then always assign a name of your choice for the device regardless of where it's plugged in or in what order.

dave
k2lyv


David Birnbaum
 

What you want is to write udev rules. There's stuff online that shows how to do it; you need two numbers for each device.  Your printout has these: MODEL_ID and VENDOR_ID.  These two hex numbers go into the udev rule which will then always assign a name of your choice for the device regardless of where it's plugged in or in what order.

dave
k2lyv


 

Willem, thanks for the excellent document. 
My project involves creating an automatic management of this process for any participant in the project. 
It would be handy if the behavior of the Microchip USB serial device could be handled in a similar way to the FTDI USB interfaces.  All of the new versions of the USB NinoTNC use the Microchip USB MCP2221 so that would actually be the target for most of my attention.  It appears that the FTDI chip is pretty easy to handle using Willems document.  I may be wrong but it looks like the MCP2221 can’t be dealt with that way. 

Is there a method to kick off the scan of the bus like Linux does at boot time? 
Thanks!  

Here’s what I get when I do 
udevadm info --name=/dev/ttyUSB0
udevadm info --name=/dev/ttyUSB1

E: ID_SERIAL_SHORT=FT0O47N0
Is fabulously valuable.  

But check out:
udevadm info --name=/dev/ttyACM0
and then 
udevadm info --name=/dev/ttyACM1

pi@taddnode:~ $ udevadm info --name=/dev/ttyUSB0
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.2/1-1.5.2:1.0/ttyUSB0/tty/ttyUSB0
N: ttyUSB0
L: 0
S: serial/by-id/usb-FTDI_UMFT234XF_FT0O47N0-if00-port0
S: serial/by-path/platform-3f980000.usb-usb-0:1.5.2:1.0-port0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.2/1-1.5.2:1.0/ttyUSB0/tty/ttyUSB0
E: DEVNAME=/dev/ttyUSB0
E: MAJOR=188
E: MINOR=0
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=15064722
E: ID_VENDOR=FTDI
E: ID_VENDOR_ENC=FTDI
E: ID_VENDOR_ID=0403
E: ID_MODEL=UMFT234XF
E: ID_MODEL_ENC=UMFT234XF
E: ID_MODEL_ID=6015
E: ID_REVISION=1000
E: ID_SERIAL=FTDI_UMFT234XF_FT0O47N0
E: ID_SERIAL_SHORT=FT0O47N0
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=ftdi_sio
E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
E: ID_MODEL_FROM_DATABASE=Bridge(I2C/SPI/UART/FIFO)
E: ID_PATH=platform-3f980000.usb-usb-0:1.5.2:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_5_2_1_0
E: DEVLINKS=/dev/serial/by-id/usb-FTDI_UMFT234XF_FT0O47N0-if00-port0 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5.2:1.0-port0
E: TAGS=:systemd:

pi@taddnode:~ $ udevadm info --name=/dev/ttyUSB1
Unknown device "/dev/ttyUSB1": No such file or directory
pi@taddnode:~ $ udevadm info --name=/dev/ttyACM0
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.3/1-1.5.3:1.0/tty/ttyACM0
N: ttyACM0
L: 0
S: serial/by-id/usb-Microchip_Technology_Inc._MCP2221_USB-I2C_UART_Combo-if00
S: serial/by-path/platform-3f980000.usb-usb-0:1.5.3:1.0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.3/1-1.5.3:1.0/tty/ttyACM0
E: DEVNAME=/dev/ttyACM0
E: MAJOR=166
E: MINOR=0
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=15037823
E: ID_VENDOR=Microchip_Technology_Inc.
E: ID_VENDOR_ENC=Microchip\x20Technology\x20Inc.
E: ID_VENDOR_ID=04d8
E: ID_MODEL=MCP2221_USB-I2C_UART_Combo
E: ID_MODEL_ENC=MCP2221\x20USB-I2C\x2fUART\x20Combo
E: ID_MODEL_ID=00dd
E: ID_REVISION=0100
E: ID_SERIAL=Microchip_Technology_Inc._MCP2221_USB-I2C_UART_Combo
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:020201:0a0000:030000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=cdc_acm
E: ID_USB_CLASS_FROM_DATABASE=Miscellaneous Device
E: ID_USB_PROTOCOL_FROM_DATABASE=Interface Association
E: ID_VENDOR_FROM_DATABASE=Microchip Technology, Inc.
E: ID_PATH=platform-3f980000.usb-usb-0:1.5.3:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_5_3_1_0
E: DEVLINKS=/dev/serial/by-id/usb-Microchip_Technology_Inc._MCP2221_USB-I2C_UART_Combo-if00 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5.3:1.0
E: TAGS=:systemd:

pi@taddnode:~ $ udevadm info --name=/dev/ttyACM1
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.4/1-1.5.4:1.0/tty/ttyACM1
N: ttyACM1
L: 0
S: serial/by-id/usb-Microchip_Technology_Inc._MCP2221_USB-I2C_UART_Combo-if00
S: serial/by-path/platform-3f980000.usb-usb-0:1.5.4:1.0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5.4/1-1.5.4:1.0/tty/ttyACM1
E: DEVNAME=/dev/ttyACM1
E: MAJOR=166
E: MINOR=1
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=15002563
E: ID_VENDOR=Microchip_Technology_Inc.
E: ID_VENDOR_ENC=Microchip\x20Technology\x20Inc.
E: ID_VENDOR_ID=04d8
E: ID_MODEL=MCP2221_USB-I2C_UART_Combo
E: ID_MODEL_ENC=MCP2221\x20USB-I2C\x2fUART\x20Combo
E: ID_MODEL_ID=00dd
E: ID_REVISION=0100
E: ID_SERIAL=Microchip_Technology_Inc._MCP2221_USB-I2C_UART_Combo
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:020201:0a0000:030000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=cdc_acm
E: ID_USB_CLASS_FROM_DATABASE=Miscellaneous Device
E: ID_USB_PROTOCOL_FROM_DATABASE=Interface Association
E: ID_VENDOR_FROM_DATABASE=Microchip Technology, Inc.
E: ID_PATH=platform-3f980000.usb-usb-0:1.5.4:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_5_4_1_0
E: DEVLINKS=/dev/serial/by-id/usb-Microchip_Technology_Inc._MCP2221_USB-I2C_UART_Combo-if00 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5.4:1.0
E: TAGS=:systemd:

Tadd - KA2DEW - tadd@... — Raleigh NC



On Jun 6, 2020, at 10:57 AM, Chuck M via groups.io <cam51mail@...> wrote:

On my pi it uses a longer text string to find the radio regardless of USB assignment.  

Mobile now, will post details later today.

Chuck
KD9DVB



On Sat, Jun 6, 2020 at 10:48 AM, Tadd KA2DEW in NC via groups.io
<tadd@...> wrote:
When I start my Raspberry PI’s Linux it scans the USB bus and finds FTDI chips.  It assigns them sequential /dev/ttyUSB port numbers in order starting at 0 and based on some port-hardware-use-order.  I think if I swap two FTDI devices between two USB sockets on the Raspberry PI that it will also swap the ttyUSB number it assigns, the next time Linux boots.  I’m not sure of that.  

What I’d like to know first is, is there a way to tell the Raspberry PI to rescan the bus, assigning the ports in order again?   

The scenario is that I have several FTDI devices and they are showing as /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2.   I figure out along the way that the unit on /dev/ttyUSB0 is not needed or defective in some non-USB way so I unplug it.  I want to configure my application so it sees the remaining two USB devices.  Since I know the devices will get new numbers, probably USB0 and USB1 when the PI resets, I want to configure the app appropriate.   It would be really handy if I could get the Raspberry PI to rescan immediately, without having to bring down Linux.  

Second question… is there a description of the Raspbian Buster scheme for scanning the USB bus and assigning the ttyUSB #s? i.e. can I predict the order it will assign?  What if there is a USB hub carrying one or more of the FTDi devices. 

Third question… It would be handy to have a table associating USB chip vendors with the ttyXXXX port numbers.  I have a Microchip MCP2221 USB/serial interface and it gets a /dev/ttyACM0 assignment.  Is there a vendor to port-name association table for Linux?  Is it a Linux-specific thing? Or does it work with BSD-Unix and/or MSWindows as well? 

Fourth question…. Is there a way to force the USB assignment in a particular order based on some universal labelling technique? I found that I can obtain a serial # from genuine FTDI chips and use that to create my own ordering table.  Thanks Erech!  But it doesn’t work if the chips are fake-FTDI, and the scheme has to be completely different for the MCP2221 ports, if it is possible at all.  


Thanks for any help.
   Tadd - KA2DEW - Raleigh NC - tadd@...






Chuck M
 

On my pi it uses a longer text string to find the radio regardless of USB assignment.  

Mobile now, will post details later today.

Chuck
KD9DVB



On Sat, Jun 6, 2020 at 10:48 AM, Tadd KA2DEW in NC via groups.io
<tadd@...> wrote:
When I start my Raspberry PI’s Linux it scans the USB bus and finds FTDI chips.  It assigns them sequential /dev/ttyUSB port numbers in order starting at 0 and based on some port-hardware-use-order.  I think if I swap two FTDI devices between two USB sockets on the Raspberry PI that it will also swap the ttyUSB number it assigns, the next time Linux boots.  I’m not sure of that.  

What I’d like to know first is, is there a way to tell the Raspberry PI to rescan the bus, assigning the ports in order again?   

The scenario is that I have several FTDI devices and they are showing as /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2.   I figure out along the way that the unit on /dev/ttyUSB0 is not needed or defective in some non-USB way so I unplug it.  I want to configure my application so it sees the remaining two USB devices.  Since I know the devices will get new numbers, probably USB0 and USB1 when the PI resets, I want to configure the app appropriate.   It would be really handy if I could get the Raspberry PI to rescan immediately, without having to bring down Linux.  

Second question… is there a description of the Raspbian Buster scheme for scanning the USB bus and assigning the ttyUSB #s? i.e. can I predict the order it will assign?  What if there is a USB hub carrying one or more of the FTDi devices. 

Third question… It would be handy to have a table associating USB chip vendors with the ttyXXXX port numbers.  I have a Microchip MCP2221 USB/serial interface and it gets a /dev/ttyACM0 assignment.  Is there a vendor to port-name association table for Linux?  Is it a Linux-specific thing? Or does it work with BSD-Unix and/or MSWindows as well? 

Fourth question…. Is there a way to force the USB assignment in a particular order based on some universal labelling technique? I found that I can obtain a serial # from genuine FTDI chips and use that to create my own ordering table.  Thanks Erech!  But it doesn’t work if the chips are fake-FTDI, and the scheme has to be completely different for the MCP2221 ports, if it is possible at all.  


Thanks for any help.
   Tadd - KA2DEW - Raleigh NC - tadd@...





Willem Schreuder
 

On 6/6/20 8:48 AM, Tadd KA2DEW in NC via groups.io wrote:
What I’d like to know first is, is there a way to tell the Raspberry PI to rescan the bus, assigning the ports in order again?
Here is a solution for that problem

https://rolfblijleven.blogspot.com/2015/02/howto-persistent-device-names-on.html

It works on most Linux distro's, but there are a few quirks between distros so may need some tweaking.


--
================================================================
Dr. Willem A. Schreuder, President, Principia Mathematica
Address: 445 Union Blvd, Suite 230, Lakewood, CO 80228, USA
Tel: (303) 716-3573 Email: Willem.Schreuder@...


 

When I start my Raspberry PI’s Linux it scans the USB bus and finds FTDI chips.  It assigns them sequential /dev/ttyUSB port numbers in order starting at 0 and based on some port-hardware-use-order.  I think if I swap two FTDI devices between two USB sockets on the Raspberry PI that it will also swap the ttyUSB number it assigns, the next time Linux boots.  I’m not sure of that.  

What I’d like to know first is, is there a way to tell the Raspberry PI to rescan the bus, assigning the ports in order again?   

The scenario is that I have several FTDI devices and they are showing as /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2.   I figure out along the way that the unit on /dev/ttyUSB0 is not needed or defective in some non-USB way so I unplug it.  I want to configure my application so it sees the remaining two USB devices.  Since I know the devices will get new numbers, probably USB0 and USB1 when the PI resets, I want to configure the app appropriate.   It would be really handy if I could get the Raspberry PI to rescan immediately, without having to bring down Linux.  

Second question… is there a description of the Raspbian Buster scheme for scanning the USB bus and assigning the ttyUSB #s? i.e. can I predict the order it will assign?  What if there is a USB hub carrying one or more of the FTDi devices. 

Third question… It would be handy to have a table associating USB chip vendors with the ttyXXXX port numbers.  I have a Microchip MCP2221 USB/serial interface and it gets a /dev/ttyACM0 assignment.  Is there a vendor to port-name association table for Linux?  Is it a Linux-specific thing? Or does it work with BSD-Unix and/or MSWindows as well? 

Fourth question…. Is there a way to force the USB assignment in a particular order based on some universal labelling technique? I found that I can obtain a serial # from genuine FTDI chips and use that to create my own ordering table.  Thanks Erech!  But it doesn’t work if the chips are fake-FTDI, and the scheme has to be completely different for the MCP2221 ports, if it is possible at all.  


Thanks for any help.
   Tadd - KA2DEW - Raleigh NC - tadd@...