Need consistent physical usb port to have same usb number

[stephenatuic]

I am working on a pi 3 project that interfaces with multiple usb serial devices. The problem I have is that on reboot it assigns all 4 ports in a different order so the code gets messed up when one port becomes /dev/ttyUSB0 when it was /dev/tty/USB2 or something like that. The usual fix online is to use udev to assign a device a usb port number, but the issue in my case is that I need to be able to use a potentially infinite amount of devices. To make this project work I need to be able to plug any of my devices into the top left port and have it assigned /dev/tty/USB0, bottom left /dev/tty/USB1, and so on and so forth. Does anyone know of any way to do this? Simple solutions would be great, but even something complicated like buying 4 usb female to usb female plugs that would simply exist as extension cables but be able to be assigned a serial number in udev would be appreciated. Ideally I would like to do this with the minimum number of parts possible but I am open to any suggestions.

[FTrevorGowen]

I am working on a pi 3 project that interfaces with multiple usb serial devices. The problem I have is that on reboot it assigns all 4 ports in a different order so the code gets messed up when one port becomes /dev/ttyUSB0 when it was /dev/tty/USB2 or something like that. ...

Is that happening with all the devices plugged in on boot or are you plugging (some) in after boot? IIRC, with things like USB flash drives, the (similar) sda, sdb etc. storage device "link" would depend upon which flash drive was plugged into which port and did not change on reboot. However, for other devices, I might expect it to do so, depending on which device/port combo responds fastest during USB enumeration. I'm no expert on that however, and, hopefully, someone else will be able to advise better.
Trev.

[stephenatuic]

I am working on a pi 3 project that interfaces with multiple usb serial devices. The problem I have is that on reboot it assigns all 4 ports in a different order so the code gets messed up when one port becomes /dev/ttyUSB0 when it was /dev/tty/USB2 or something like that. ...

Is that happening with all the devices plugged in on boot or are you plugging (some) in after boot? IIRC, with things like USB flash drives, the (similar) sda, sdb etc. storage device "link" would depend upon which flash drive was plugged into which port and did not change on reboot. However, for other devices, I might expect it to do so, depending on which device/port combo responds fastest during USB enumeration. I'm no expert on that however, and, hopefully, someone else will be able to advise better.
Trev.

All the devices are usb serial devices. My most common configuration is multiple usb to serial converter cables so the speed is quite similar and results in different /dev/ttyUSBx assignments. My issue is I have code that assigns what serial data is sent out of which port so I need to be able to plug a device to the top left and have it send serial data out the top left usb port. I would also need to be able to swap 2 cables and always have it sending the same serial data out the top left and the same serial data out the bottom left regardless of which cable is plugged in and what order they are plugged in, while keeping it consistent when rebooted.

[FTrevorGowen]

...
All the devices are usb serial devices. My most common configuration is multiple usb to serial converter cables so the speed is quite similar and results in different /dev/ttyUSBx assignments.
...

Unless the devices report some unique id during the enumeration process I suspect that what you want to happen may not be possible. It may help if you post the reports of lsusb, lsusb -t** and usb-devices for a typical setup.
Trev.
** Eg. see such for the USB-to-serial Adapter types I've tried out:
https://www.cpmspectrepi.uk/raspberry_p ... pters.html

[John Public]

A workaround for dealing with changing USB? naming is that you have a small C program that does a

Code: Select all

system("dmesg | grep usb > /whatever/some.txt")

and then you open the "/whatever/some.txt" file and parse what usb is used for what and apply that for the rest of your program.

[stephenatuic]

A workaround for dealing with changing USB? naming is that you have a small C program that does a

Code: Select all

system("dmesg | grep usb > /whatever/some.txt")

and then you open the "/whatever/some.txt" file and parse what usb is used for what and apply that for the rest of your program.

How would you identify the physical port in the .txt file? If I say wanted to assign /dev/tty/USB0 as the top left usb port on the raspberry pi what would that look like in the .txt file?

[FTrevorGowen]

A workaround for dealing with changing USB? naming is that you have a small C program that does a

Code: Select all

system("dmesg | grep usb > /whatever/some.txt")

and then you open the "/whatever/some.txt" file and parse what usb is used for what and apply that for the rest of your program.

How would you identify the physical port in the .txt file? If I say wanted to assign /dev/tty/USB0 as the top left usb port on the raspberry pi what would that look like in the .txt file?

I haven't looked at dmesg dumps much, but the output of lsusb -t (re-directed to a text file) might also provide useful info. including what, AFAIK, is the port number - some examples here:
https://www.cpmspectrepi.uk/raspberry_p ... Trees.html
Trev.

[Paeryn]

You might be able to use the symklink in /dev/serial/by-path/, for a USB serial it should be listed as something like:

Code: Select all

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.*:1.0-port0

Where * is the port it is connected to. On my RPi3 the numbers are :-
2 - Top USB next to the ethernet port
3 - Bottom USB next to the ethernet port
4 - Top USB furthest from the ethernet port
5 - Bottom USB furthest from the ethernet port.

Port 1 of the hub is the built-in ethernet port.

Other models of RPi may be wired up differently, if so then all bets are off.

[stephenatuic]

You might be able to use the symklink in /dev/serial/by-path/, for a USB serial it should be listed as something like:

Code: Select all

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.*:1.0-port0

Where * is the port it is connected to. On my RPi3 the numbers are :-
2 - Top USB next to the ethernet port
3 - Bottom USB next to the ethernet port
4 - Top USB furthest from the ethernet port
5 - Bottom USB furthest from the ethernet port.

Port 1 of the hub is the built-in ethernet port.

Other models of RPi may be wired up differently, if so then all bets are off.

This seems to be exactly what I am looking for but I am having troubles implementing it. I am following the guide on this page
http://superuser.com/questions/536478/h ... -addresses
to set up my symlink

I created a udev file called /etc/udev/rules.d/serial-symlinks.rules like so

Code: Select all

sudo nano /etc/udev/rules.d/serial-symlinks.rules

and filled it with this

Code: Select all

SUBSYSTEM=="tty", ENV{ID_PATH}=="platform-3f980000-usb-usb-0:1.2:1.0-port0", SYMLINK+="ttyNTMS"

Unfortunately when I do
udevadm info /dev/ttyNTMS
it is unable to recognize it and it cannot open that connection when I use that as my port instead of /dev/ttyUSB0

Is there anything inherently obviously wrong about how I am entering the new udev rule?

[Paeryn]

I created a udev file called /etc/udev/rules.d/serial-symlinks.rules like so

Code: Select all

sudo nano /etc/udev/rules.d/serial-symlinks.rules

and filled it with this

Code: Select all

SUBSYSTEM=="tty", ENV{ID_PATH}=="platform-3f980000-usb-usb-0:1.2:1.0-port0", SYMLINK+="ttyNTMS"

Unfortunately when I do
udevadm info /dev/ttyNTMS
it is unable to recognize it and it cannot open that connection when I use that as my port instead of /dev/ttyUSB0

Is there anything inherently obviously wrong about how I am entering the new udev rule?

Is the ID_PATH correct? I gave that as a nearest guess based on other devices but it might be slightly different (I don't have a USB serial device to check with).
You'll need to unplug and replug the device before it will show up.

Also, rules files are normally prefixed by a two digit number and hyphen as they are processed in alphabetical order. Your rules file as-is will be processed last (in this case that should be ok as no other rules file will be depending on values you set and all needed values from other rules will have been processed).

[stephenatuic]

Sorry for the long time between posts but things came up that put this project by the wayside for some time. I am back where I left off and have checked several more things. The path is correct as checked by typing in

Code: Select all

udevadm info /dev/tty/USB0

when a device is plugged into port 2 of the raspberry pi. I have tried reloading the rules with

Code: Select all

udevadm control --reload-rules

and then checking

Code: Select all

udevadm test -a add $(udevadm info -q path -n /dev/ttyUSB0 )

to see if there was any change. I have tried the file with numbers and a dash prefacing it using low and high numbers. I also tried all of these things with a rule file in /lib/udev/rules.d as well. No matter what is attempted it does not fail on syntax in the udev rules, but when referencing /dev/ttyNTMS it is unable to recognize it in any way. At this point I feel I must have written the udev rule wrong and /dev/ttyNTMS is not linking to any tty device plugged into port 2 like the tutorial I followed stated but I am unsure how to change the rule to make it link successfully so that when I open a serial port on /dev/ttyNTMS it just opens a port using the device on the physical port 2 of the raspberry pi. If anyone has any ideas on how to configure the udev correctly or any other ideas on how to accomplish my original physical port assignment goal please let me know.

[Paeryn]

Looking at what you put earlier, you have a mistake in the ID_PATH, it should be a fullstop before the first usb not a dash

and filled it with this

Code: Select all

SUBSYSTEM=="tty", ENV{ID_PATH}=="platform-3f980000-usb-usb-0:1.2:1.0-port0", SYMLINK+="ttyNTMS"

That should be

Code: Select all

SUBSYSTEM=="tty", ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.2:1.0-port0", SYMLINK+="ttyNTMS"

[stephenatuic]

Looking at what you put earlier, you have a mistake in the ID_PATH, it should be a fullstop before the first usb not a dash

and filled it with this

Code: Select all

SUBSYSTEM=="tty", ENV{ID_PATH}=="platform-3f980000-usb-usb-0:1.2:1.0-port0", SYMLINK+="ttyNTMS"

That should be

Code: Select all

SUBSYSTEM=="tty", ENV{ID_PATH}=="platform-3f980000.usb-usb-0:1.2:1.0-port0", SYMLINK+="ttyNTMS"

Unfortunately that error was from me copying it into the forums and not from copying it into the udev rules file. that dash was a dot for all previous testing. I think it must be a problem with how I am writing the rule.

[stephenatuic]

I feel the udev rule could also be written correctly but it is my lack of understanding of how to use the new simulink that is the issue. I am currently trying to use

Code: Select all

ls - l /dev/ttyNTMS

and

Code: Select all

udevadm info /dev/ttyNTMS

to determine if the symlink was successful. Is there a correct way I can check this symlink and its functionality in some actual code where I open a serial port on /dev/ttyNTMS and it always opens that port on the assigned usb port?

[Paeryn]

Using the symlink is just like using the actual device, if you open /dev/ttyNTMS then whatever that ultimately links to will be opened.
What is /dev/ttyNTMS being created as (the result of ls -l /dev/ttyNTMS)? I would expect it to be /dev/ttyUSB0 (or whichever number it is).

If you have a rule file in both /lib/udev/rules.d/ and /etc/udev/rules.d/ with the same name then the one in /etc/udev/rules.d/ will be used, the other will be ignored.

[stephenatuic]

Using the symlink is just like using the actual device, if you open /dev/ttyNTMS then whatever that ultimately links to will be opened.
What is /dev/ttyNTMS being created as (the result of ls -l /dev/ttyNTMS)? I would expect it to be /dev/ttyUSB0 (or whichever number it is).

If you have a rule file in both /lib/udev/rules.d/ and /etc/udev/rules.d/ with the same name then the one in /etc/udev/rules.d/ will be used, the other will be ignored.

The result of ls -l /dev/ttyNTMS is simply

Code: Select all

ls: cannot access /dev/ttyNTMS: No such file or directory

It would seem the symlink is not actually being successful but I cant quite tell why. I am trying

Code: Select all

udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0)

for more information but I am unsure how to use it to change the udev rule so the symlink actually creates.

[Paeryn]

If the symlink isn't created then the rule didn't trigger.

Try a modified version, hopefully it's a bit more forgiving.

Code: Select all

KERNEL=="ttyUSB*", KERNELS=="1-1.2", SYMLINK+="ttyNTMS"

You need to unplug and replug the device to trigger udev to run it's rules again, just getting info won't do it. (I think you can tell udevadm to act as though a device has just been plugged in but I can't test it right now).

[stephenatuic]

If the symlink isn't created then the rule didn't trigger.

Try a modified version, hopefully it's a bit more forgiving.

Code: Select all

KERNEL=="ttyUSB*", KERNELS=="1-1.2", SYMLINK+="ttyNTMS"

You need to unplug and replug the device to trigger udev to run it's rules again, just getting info won't do it. (I think you can tell udevadm to act as though a device has just been plugged in but I can't test it right now).

This was almost exactly it. I couldnt use the first part as that assigned it to apply the symlink only if it was on usb0 or usb1, but removing that portion gave me exactly what I needed.

Code: Select all

 KERNELS=="1-1.2", SYMLINK+="ttyNTMS"

and to test I restarted with

Code: Select all

sudo /etc/init.d/udev restart

and then checked

Code: Select all

ls /dev/t* -la

and /dev/ttyNTMS only shows up when an item is plugged into physical port 2. You have been an absolute lifesaver on this. Thanks for all of your help.

[Paeryn]

The KERNEL=="ttyUSB*" should make sure it really is a ttyUSB device. If you don't limit it then it will apply to any device being plugged into that port regardless of whether it's a ttyUSB device (not good if you plug something else in there).

[stephenatuic]

My bad I assumed the * was just meant for me to input the number, did not realise that that was the correct syntax to use. I have added it in and made a rule for each port that if a ttyUSB device is plugged in it will recognize it and symlink it to ttyNTMS1, ttyNTMS2,.... Now it does not catch the mouse and keyboard when they are plugged in which is good. Thanks for the heads up.

[Paeryn]

Sorry, I should've made that clearer originally. Glad it's working now.

[fruitsandpieces]

Hi,

to put you in situation: I need the raspberry pi to have more than one USB before powering it on, and I want to tell it which of the usb ports should correspond to the usb which contains '/root', so I've tried your approach as I thought it would be the solution.

I've got /root content on a USB drive and /boot content on a SD card.

When cmdline.txt points to /dev/sda1 as root, tests after booting (only one usb drive plugged) with the pysical usb ports work ok.

However, when cmdline.txt points to '/dev/whatever_specified_in_udev_rule' the system keeps waiting for '/dev/whatever_specified_in_udev_rule' during boot.

Could you give me a hand to solve this?

thanks in advance.

[Paeryn]

Hi,

to put you in situation: I need the raspberry pi to have more than one USB before powering it on, and I want to tell it which of the usb ports should correspond to the usb which contains '/root', so I've tried your approach as I thought it would be the solution.

I've got /root content on a USB drive and /boot content on a SD card.

When cmdline.txt points to /dev/sda1 as root, tests after booting (only one usb drive plugged) with the pysical usb ports work ok.

However, when cmdline.txt points to '/dev/whatever_specified_in_udev_rule' the system keeps waiting for '/dev/whatever_specified_in_udev_rule' during boot.

Could you give me a hand to solve this?

thanks in advance.

Are you sure you meant "/root"? That is the user root's home directory...

You can't use any name you assigned in your udev rules as your filesystem hasn't yet been mounted (since you are defining where the filesystem is) so no parsing of your custom udev rules can have taken place at this point.

I think you should be using either the UUID or PARTUUID of the partition containing your root filesystem (replacing xxx with the corresponding UUID or PARTUUID depending on which you are using), e.g.

Code: Select all

root=PARTUUID=xxx
root=UUID=xxx

The UUID and/or PARTUUID can be found using

Code: Select all

sudo blkid

[fruitsandpieces]

Are you sure you meant "/root"? That is the user root's home directory...

Ouch, I meant the whole filesystem, which is specified in cmdline.txt, "root=xxx"

I think you should be using either the UUID or PARTUUID of the partition containing your root filesystem (replacing xxx with the corresponding UUID or PARTUUID depending on which you are using), e.g.

Is there any other way you can specify the physical port, rather than a unique identifier which depends on the USB you insert?
I'd like it to be ... no matter how many usb drives are connected, go find the filesystem in whichever is connected to usb_port_1, for example.

many thanks

[fruitsandpieces]

For the moment I will label the usb-drives with a very specific name, and then specify it in cmdline.txt: root=LABEL=LABEL_NAME

I've followed from here ( viewtopic.php?f=66&t=105868 ).

Code: Select all

sudo nano /boot/config.txt # add initramfs initrd.sda
mkinitramfs -o /boot/initrd.sda #create

Update /boot/cmdline.txt to:

Code: Select all

dwc_otg.lpm_enable=0 console=tty1  root=LABEL=LABEL_NAME  rootfstype=ext4 elevator=deadline rootwait rootdelay=5 
sudo nano /etc/fstab #modify to:

Code: Select all

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
#/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
LABEL=LABEL_NAME /     ext4    defaults,noatime       0 1  

That would do for now, however I'm still curious to find out, as each port has a number internally...