Hallo zusammen, ich habe ein Problem mit der Erkennung eines Serial<>USB Wandlers. Wird das Geraet ohne geloeteten EEProm angestoepselt, also OHNE PRIVATE VendorID / ProductID, dann wird es erkannt und ftdi_sio geladen: [ohne Zeilenumbruch zur besseren Uebersicht] usb 2-1: new full speed USB device using uhci_hcd and address 3 usb 2-1: new device found, idVendor=0403, idProduct=6001 usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1: Product: USB <-> Serial usb 2-1: Manufacturer: FTDI usb 2-1: configuration #1 chosen from 1 choice usbcore: registered new driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for generic usbcore: registered new driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232BM usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: registered new driver ftdi_sio drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver Hier ist alles wunderbar! Jetzt stecke ich ein Geraet mit EEProm und PRIVATER VendorID / ProductID ran. usb 2-1: new full speed USB device using uhci_hcd and address 2 usb 2-1: new device found, idVendor=0403, idProduct=ff38 usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: IBS-US485 pocket USB<-->RS485/422 usb 2-1: Manufacturer: FTDI usb 2-1: SerialNumber: FT1A3X80 usb 2-1: configuration #1 chosen from 1 choice Hier wird das Geraet nicht eingebunden und ftdi_sio nicht geladen. Wo und wie erstelle ich die Regel fuer das Geraet? Bin fuer jeden Tip dankbar. Achja SuSE 10.1 MfG Th. Moritz -- Ich habe gestern schon gesagt, ich gehe heute zeitig schlafen und ich sitze heute immernoch hier, hatte ich dann eine kurze, oder eine lange Nacht? (c)ThM.
Hallo. * Montag, 18. September 2006 um 17:56 (+0200) schrieb Thomas Moritz:
Jetzt stecke ich ein Geraet mit EEProm und PRIVATER VendorID / ProductID ran.
usb 2-1: new full speed USB device using uhci_hcd and address 2 usb 2-1: new device found, idVendor=0403, idProduct=ff38 usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: IBS-US485 pocket USB<-->RS485/422 usb 2-1: Manufacturer: FTDI usb 2-1: SerialNumber: FT1A3X80 usb 2-1: configuration #1 chosen from 1 choice
Hier wird das Geraet nicht eingebunden und ftdi_sio nicht geladen. Wo und wie erstelle ich die Regel fuer das Geraet?
Du wirst vermutlich die neue ProductID (und ggfs. neue VendorID) in <kernelsource>/drivers/usb/serial/ftdi_sio.h und <kernelsource>/drivers/usb/serial/ftdi_sio.c eintragen müssen und die Module (und evtl. auch den Kernel) neu erstellen und installieren müssen. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Am Dienstag, 19. September 2006 00:08 meinte Andreas Koenecke: Hallo Andreas, besten Dank fuer Deine schnelle Antwort!
* Montag, 18. September 2006 um 17:56 (+0200) schrieb Thomas Moritz:
Jetzt stecke ich ein Geraet mit EEProm und PRIVATER VendorID / ProductID ran.
usb 2-1: new full speed USB device using uhci_hcd and address 2 usb 2-1: new device found, idVendor=0403, idProduct=ff38 usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: IBS-US485 pocket USB<-->RS485/422 usb 2-1: Manufacturer: FTDI usb 2-1: SerialNumber: FT1A3X80 usb 2-1: configuration #1 chosen from 1 choice
Hier wird das Geraet nicht eingebunden und ftdi_sio nicht geladen. Wo und wie erstelle ich die Regel fuer das Geraet?
Du wirst vermutlich die neue ProductID (und ggfs. neue VendorID) in <kernelsource>/drivers/usb/serial/ftdi_sio.h und <kernelsource>/drivers/usb/serial/ftdi_sio.c eintragen müssen und die Module (und evtl. auch den Kernel) neu erstellen und installieren müssen.
Mir war so, als haette man solche Eintraege in frueheren Versionen per HotPlug vornehmen koennen. Wenn ich mir die: /etc/hal/fdi/policy/10osvendor/80-scanner.fdi anschaue, dann sieht es doch nach so einer Moeglichkeit aus? Sollte dann der udev das Geraet nicht schon erkennen? Leider fehlt mir das noetige Verstaendnis fuer die Zusammenhaenge in dem neuen Konzept. Vielleicht denke ich jetzt auch nur voellig quer? MfG Th. Moritz -- Das beste beim Diktieren ist, dass man Worte verwenden kann, von denen man keine Ahnung hat, wie sie geschrieben werden!
Hallo Thomas. * Dienstag, 19. September 2006 um 06:54 (+0200) schrieb Thomas Moritz:
Am Dienstag, 19. September 2006 00:08 meinte Andreas Koenecke:
* Montag, 18. September 2006 um 17:56 (+0200) schrieb Thomas Moritz:
Hier wird das Geraet nicht eingebunden und ftdi_sio nicht geladen. Wo und wie erstelle ich die Regel fuer das Geraet?
Du wirst vermutlich die neue ProductID (und ggfs. neue VendorID) in <kernelsource>/drivers/usb/serial/ftdi_sio.h und <kernelsource>/drivers/usb/serial/ftdi_sio.c eintragen müssen und die Module (und evtl. auch den Kernel) neu erstellen und installieren müssen.
Mir war so, als haette man solche Eintraege in frueheren Versionen per HotPlug vornehmen koennen.
Ich bin mir bei der Sache auch nicht sicher, aber ich befürchte das Hotplug-System ist nicht das einzige Problem. Vermutlich wird auch das "ftdi_sio.ko"-Kernel-Modul anhand der Vendor- und ProductID überprüfen, ob es für das Gerät "zuständig" ist. Versuche doch einmal, bei eingesteckten "Custom-Gerät" ein manuelles 'modprobe ftdi_sio' und teste dann, ob das Gerät erkannt und angesprochen wird. Falls ja, kann man das Problem mit einer udev-Regel wahrscheinlich umgehen.
Wenn ich mir die:
/etc/hal/fdi/policy/10osvendor/80-scanner.fdi
anschaue, dann sieht es doch nach so einer Moeglichkeit aus? Sollte dann der udev das Geraet nicht schon erkennen? Leider fehlt mir das noetige Verstaendnis fuer die Zusammenhaenge in dem neuen Konzept.
UDEV habe ich ja noch einigermaßen verstanden, aber bei HAL hört es dann bei mir auch auf... Aber ich glaube nicht, dass dir obiges HAL-Beispiel hilft, das ist IMHO eine ganz andere, hardware-fernere Ebene. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Am Dienstag, 19. September 2006 21:41 meinte Andreas Koenecke: Hallo Andreas,
Ich bin mir bei der Sache auch nicht sicher, aber ich befürchte das Hotplug-System ist nicht das einzige Problem. Vermutlich wird auch das "ftdi_sio.ko"-Kernel-Modul anhand der Vendor- und ProductID überprüfen, ob es für das Gerät "zuständig" ist. Versuche doch einmal, bei eingesteckten "Custom-Gerät" ein manuelles 'modprobe ftdi_sio' und teste dann, ob das Gerät erkannt und angesprochen wird.
Hier liegt das Problem. Eigentlich ist es unverstaendlich, wieso man nicht zB.: /etc/ftdi_sio fuer solche Sachen vorsieht und beim Booten die dort eingetragenen Geraete uebernimmt. Jeder Hardware-Entwickler, der zur besseren Kennung seine eigene PID im EEprom ablegt, muss also dem (Linux)-Kunden beschreiben, wie man Kernel-Module kompiliert. TsssTsss
UDEV habe ich ja noch einigermaßen verstanden, aber bei HAL hört es dann bei mir auch auf... Aber ich glaube nicht, dass dir obiges HAL-Beispiel hilft, das ist IMHO eine ganz andere, hardware-fernere Ebene.
Auch wenn sich das eigentliche Problem damit nicht loesen laesst: Ist Dir vielleicht eine Doku bekannt, die das _Zusammenspiel_: dbus-hal-udev-kernel beschreibt? Zu jedem einzelnen Paket laesst sich was finden, aber im Zusammenhang mit udev steht dann /etc/hotplug. Die Zeiten sind ja nun vorbei. MfG Th. Moritz -- In EU-Ost steht jetzt meine Firma, das Schweizer Konto regelt die Irma. Hier in Deutschland hol' ich mein Wohngeld, man bin ich ein Held! (Zukunft?) (c)Th.M.
Hallo Thomas. * Donnerstag, 21. September 2006 um 08:14 (+0200) schrieb Thomas Moritz:
Am Dienstag, 19. September 2006 21:41 meinte Andreas Koenecke:
Versuche doch einmal, bei eingesteckten "Custom-Gerät" ein manuelles 'modprobe ftdi_sio' und teste dann, ob das Gerät erkannt und angesprochen wird.
Hier liegt das Problem. Eigentlich ist es unverstaendlich, wieso man nicht zB.: /etc/ftdi_sio fuer solche Sachen vorsieht und beim Booten die dort eingetragenen Geraete uebernimmt.
Die Map-Dateien, die 'depmod' im Modul-Verzeichnis anlegt, gehen ja schon in diese Richtung. Nur dass der Treiber nach dem Laden noch einmal anhand der IDs selbst seine "Zuständigkeit" überprüft. Und das ist IMHO auch gut so; mir wäre es gar nicht recht, wenn der (falsche) Treiber durch Setzen irgendwelcher Register mein Gerät irreparabel beschädigt...
Jeder Hardware-Entwickler, der zur besseren Kennung seine eigene PID im EEprom ablegt, muss also dem (Linux)-Kunden beschreiben, wie man Kernel-Module kompiliert. TsssTsss
Naja, es gibt ja eine Handvoll Alternativen, von der Aufnahme der IDs in den offiziellen Kernel-Baum über Mitliefern/Bereitstellen fertiger Kernel-Module bis zum eigenen Install-Skript ala NVIDIA.
Auch wenn sich das eigentliche Problem damit nicht loesen laesst: Ist Dir vielleicht eine Doku bekannt, die das _Zusammenspiel_: dbus-hal-udev-kernel beschreibt?
Nein, so eine Doku ist mir auch nicht bekannt. Ich befürchte, man muss sich das Zusammenspiel der Programme aus den einzelnen Dokumenten herausklauben... Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo Thomas. * Donnerstag, 21. September 2006 um 08:14 (+0200) schrieb Thomas Moritz:
Am Dienstag, 19. September 2006 21:41 meinte Andreas Koenecke:
Versuche doch einmal, bei eingesteckten "Custom-Gerät" ein manuelles 'modprobe ftdi_sio' und teste dann, ob das Gerät erkannt und angesprochen wird.
Hier liegt das Problem. Eigentlich ist es unverstaendlich, wieso man nicht zB.: /etc/ftdi_sio fuer solche Sachen vorsieht und beim Booten die dort eingetragenen Geraete uebernimmt. Jeder Hardware-Entwickler, der zur besseren Kennung seine eigene PID im EEprom ablegt, muss also dem (Linux)-Kunden beschreiben, wie man Kernel-Module kompiliert. TsssTsss
Vielleicht gibt es doch noch eine einfache Lösung: Ich habe gerade mit 'modinfo ftdi_sio' gesehen, dass man dem Modul wohl Vendor- und ProductID als Parameter übergeben kann. Probiere doch einmal 'modprobe ftdi_sio vendor=<Deine VendorID> product=<Deine ProductID>'. Gruß Andreas -- XMMS spielt gerade nichts... PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Am Donnerstag, 21. September 2006 20:02 meinte Andreas Koenecke: Hallo Andreas,
* Donnerstag, 21. September 2006 um 08:14 (+0200) schrieb Thomas Moritz:
Am Dienstag, 19. September 2006 21:41 meinte Andreas Koenecke:
Versuche doch einmal, bei eingesteckten "Custom-Gerät" ein manuelles 'modprobe ftdi_sio' und teste dann, ob das Gerät erkannt und angesprochen wird.
Vielleicht gibt es doch noch eine einfache Lösung: Ich habe gerade mit 'modinfo ftdi_sio' gesehen, dass man dem Modul wohl Vendor- und ProductID als Parameter übergeben kann. Probiere doch einmal 'modprobe ftdi_sio vendor=<Deine VendorID> product=<Deine ProductID>'.
Du bist ein Engel :-) So klappt es zumindest manuell! Jetzt muss ich mich also doch wieder mit udev beschaeftigen. "/etc/udev/rules.d/50-rules-default.rules" [ttyUSB*] Sieht schonmal verlockend aus :-) Also werde ich mir am Wochenende die einzelnen Dokus reinziehen und die Test-Kiste strapazieren. Nochmals besten Dank fuer Deine erfolgreiche Hilfe! MfG Th. Moritz -- Wenn die Menschen nur ueber das sprechen wuerden, was sie begreifen, dann wuerde es sehr still sein auf der Welt. (Albert Einstein)
Am Freitag, 22. September 2006 08:59 meinte Thomas Moritz:
Am Donnerstag, 21. September 2006 20:02 meinte Andreas Koenecke:
Hallo Andreas,
Vielleicht gibt es doch noch eine einfache Lösung: Ich habe gerade mit 'modinfo ftdi_sio' gesehen, dass man dem Modul wohl Vendor- und ProductID als Parameter übergeben kann. Probiere doch einmal 'modprobe ftdi_sio vendor=<Deine VendorID> product=<Deine ProductID>'.
Du bist ein Engel :-) So klappt es zumindest manuell!
Letztendes ist das aber auch nur eine halbe Sache. Beim Anstecken eines zweiten Geraetes ist schon wieder Schluss. Fazit: Eine Mail an Bill Ryder mit Product, PID und VID aller eigenen Geraete und mit dem naechsten Kernel kommt das Sorgenfrei-Paket :-) Das waere zumindest wuenschenswert. Mal sehen ob es klappt. Nochmals besten Dank fuer Deine Ausdauer und Bemuehungen! MfG Th. Moritz -- Dank Alzheimer lerne ich dauernd neue Leute kennen!
participants (2)
-
Andreas Koenecke
-
Thomas Moritz