Connexion d'un périphérique USB-série avec un PID personnalisé à ttyUSB0 sur une carte intégrée

19

J'essaie d'obtenir un périphérique USB-série FTDI avec un PID personnalisé à attacher automatiquement (ou même manuellement) à ttyUSB% n, sans grand succès. Le VID / PID normal de l'appareil est 0403/6001. Lorsqu'il est programmé de cette façon, il fonctionne parfaitement et se fixe automatiquement à ttyUSB0 lorsqu'il est branché. Même avec le pilote recompilé pour respecter notre nouveau PID, lorsqu'il est programmé avec le ttyUSB0 personnalisé n'apparaît pas, mais il le reconnaît comme un périphérique ftdi_sio et charge le pilote.

J'ai ajouté notre PID à l'en-tête et à la source:

// in ftdi_sio_ids.h
#define FTDI_CUSTOM_PID 0xABCD // not the actual pid
// then in ftdi_sio.c
static struct usb_device_id id_table_combined [] = {
    // devices....
    { USB_DEVICE(FTDI_VID, FTDI_CUSTOM_PID) },
    // ....

Recompilé le noyau entier et reflasher le périphérique. Lorsque je branche l'appareil, j'obtiens:

usb 1-1: new full-speed USB device number 2 using at91_ohci
usbcore: registered new interface driver usbserial
usbserial: USB Serial Driver core
USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

lsusb affiche le VID / PID personnalisé correct. Le pilote semble reconnaître qu'il est censé utiliser ftdi_sio avec lui, mais ne le joint pas à ttyUSB0 comme il le ferait avec le PID non modifié. Des suggestions sur ce que je fais mal ici?

trycatch
la source
1
De quel type intégré s'agit-il? At-il UDEV? Si c'est le cas, UDEV est votre meilleur pari (et je peux vous aider avec cela).
Brian Redbeard

Réponses:

17

Vous n'avez pas besoin de modifier le noyau juste une fois; vous pouvez le remplacer.

  1. Débrancher l'appareil
  2. modprobe ftdi_sio
  3. echo 0403 6001 >/sys/bus/usb-serial/drivers/ftdi_sio/new_id
  4. Branchez l'appareil

Et votre appareil devrait fonctionner.

Votre autre alternative consiste à utiliser l' bindinterface sysfs; Je suggère d'utiliser lsusb -tpour trouver le bon chemin + interface dans ce cas.

En utilisant un exemple partiel de mon système, d'un périphérique de stockage USB (ce serait très similaire pour USB-série).

$ lsusb -t
...
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/3p, 5000M
        |__ Port 3: Dev 6, If 0, Class=Hub, Driver=hub/3p, 5000M
            |__ Port 3: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
 ...
 $ echo '4-1.3.3:1.0' >/sys/bus/usb/drivers/usb-storage/bind

Le format du numéro est: BUS-PORT(.PORT)+:1.INTERFACE. Le seul nombre qui n'est pas visible dans la sortie lsusb est le premier chiffre après les deux points; et ça a toujours été un 1dans mon expérience. Quelqu'un avec une connaissance approfondie du noyau peut probablement me dire de quoi il s'agit et fournir un contre-exemple.

robbat2
la source
A parfaitement fonctionné, merci. Doit être la réponse acceptée.
Amr Bekhit
1
Je me demande simplement: si je change d'avis et que je ne veux pas que ce vid / pid utilise le pilote ftdi_sio mais un autre, comment puis-je revenir sur cette étape?
Bram
Écrivez le vid / pid à remove_id pour annuler l'écho à new_id.
robbat2
@trycatch pouvez-vous accepter la réponse?
robbat2
1
@kay new_id / remove_id sert uniquement à supprimer les ID ajoutés dynamiquement. Si je comprends ce que vous voulez faire: vous voulez empêcher un pilote spécifique de se charger pour un périphérique.
robbat2
12

Vous n'avez pas besoin de modifier le noyau, vous pouvez automatiser le processus comme ceci:

  1. Ajoutez la ligne unique suivante à /etc/udev/rules.d/99-ftdi.rules

    ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", RUN+="/sbin/modprobe ftdi_sio" RUN+="/bin/sh -c 'echo 0403 6001 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"

  2. Redémarrez ou exécutez sudo udevadm control --reloadpour récupérer la nouvelle règle.

  3. Débrancher l'appareil.

  4. Branchez l'appareil.

Stephen
la source
1

une situation absolument similaire s'est produite avec la carte d'évaluation de SiLabs - la puce USB-UART CP2102 est fournie avec un VID / PID irrégulier:

lsusb

Bus 001 Device 002: ID 10c4:804c Cygnal Integrated Products, Inc.

problème résolu en chargeant le module cp210x et en envoyant VID / PID comme mentionné précédemment:

sudo modprobe cp210x

sudo -s

echo 10c4 804c > /sys/bus/usb-serial/drivers/cp210x/new_id

le fichier 99-cp210.rules correspondant pour l'udev ressemble à ceci:

ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="804c", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 804c > /sys/bus/usb-serial/drivers/cp210x/new_id'"

Oleg Kokorin
la source
Pour les futurs voyageurs essayant de faire fonctionner une clé HUSBZB-1, voici un fichier udev qui reliera le pilote cp210x comme mentionné ci-dessus, et liera les périphériques tty à / dev / zigbee et / dev / z-wave ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="8a2a", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 8a2a > /sys/bus/usb-serial/drivers/cp210x/new_id'" SUBSYSTEM=="tty", ATTRS{interface}=="HubZ Z-Wave Com Port", SYMLINK+="zwave" SUBSYSTEM=="tty", ATTRS{interface}=="HubZ ZigBee Com Port", SYMLINK+="zigbee"
nébuleux