Collegamento di un dispositivo seriale USB con PID personalizzato a ttyUSB0 su incorporato

Sto tentando di ottenere un dispositivo USB-seriale FTDI con un PID personalizzato da collegare automaticamente (o anche manualmente) a ttyUSB% n, senza molto successo. Il VID / PID normale del dispositivo è 0403/6001. Se programmato in questo modo, funziona perfettamente e si attacca automaticamente a ttyUSB0 quando collegato. Anche con il driver ricompilato per rispettare il nostro nuovo PID, quando programmato con quello personalizzato ttyUSB0 non appare, ma lo riconosce come dispositivo ftdi_sio e carica il driver.

Ho aggiunto il nostro PID all'intestazione e alla fonte:

// 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) },
    // ....

Ricompilato l'intero kernel e ricollegato il dispositivo. Quando collego il dispositivo ottengo:

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 mostra il VID / PID personalizzato corretto. Il driver sembra riconoscere che dovrebbe usare ftdi_sio con esso, ma non lo collega a ttyUSB0 come farebbe con il PID non modificato. Qualche suggerimento su cosa sto facendo di sbagliato qui?

— prova a prendere
fonte

Che tipo di embedded è questo? Ha UDEV? In tal caso, UDEV è la soluzione migliore (e posso aiutarti ulteriormente).

— Brian Redbeard,

Risposte:

Non è necessario modificare il kernel per farlo solo una volta; puoi ignorarlo.

Scollegare il dispositivo
modprobe ftdi_sio
echo 0403 6001 >/sys/bus/usb-serial/drivers/ftdi_sio/new_id
Collega il dispositivo

E il tuo dispositivo dovrebbe funzionare.

L'altra alternativa è utilizzare l' bindinterfaccia sysfs; Suggerisco di usare lsusb -tper capire il percorso corretto + interfaccia in quel caso.

Usando un esempio parziale del mio sistema, di un dispositivo di archiviazione USB (sarebbe molto simile per USB-seriale).

$ 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

Il formato del numero è: BUS-PORT(.PORT)+:1.INTERFACE. L'unico numero che non è visibile nell'output di lsusb è la prima cifra dopo i due punti; ed è sempre stato un 1nella mia esperienza. Qualcuno con una conoscenza più approfondita del kernel può probabilmente dirmi di cosa si tratta e fornire un contro-esempio.

— robbat2
fonte

Ha funzionato perfettamente, grazie. Dovrebbe essere la risposta accettata.

— Amr Bekhit,

Mi chiedo solo: se cambio idea e non voglio che questo video / pid utilizzi il driver ftdi_sio ma un altro, come posso ripristinare questo passaggio?

— Bram,

Scrivi vid / pid per remove_id per annullare l'eco in new_id.

— robbat2,

@trycatch puoi per favore accettare la risposta?

— robbat2,

@kay new_id / remove_id serve solo per rimuovere gli ID aggiunti dinamicamente. Se capisco cosa vuoi fare: vuoi impedire il caricamento di un driver specifico per alcuni dispositivi.

— robbat2,

Non è necessario modificare il kernel, è possibile automatizzare il processo in questo modo:

Aggiungi la seguente riga singola a /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'"
Riavvia o esegui sudo udevadm control --reloadper selezionare la nuova regola.
Scollegare il dispositivo.
Collega il dispositivo.

— Stefano
fonte

situazione assolutamente simile si è verificata con la scheda eval di SiLabs - il chip USB-UART CP2102 viene fornito con VID / PID irregolari:

lsusb

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

problema risolto caricando il modulo cp210x e inviando VID / PID come menzionato prima:

sudo modprobe cp210x

sudo -s

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

il file 99-cp210.rules corrispondente per udev appare come segue:

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
fonte

Per i futuri viaggiatori che cercano di far funzionare uno stick HUSBZB-1, ecco un file udev che collegherà il driver cp210x come menzionato sopra e collegherà i dispositivi tty a / dev / zigbee e / 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"

— nebulous