ftdi-sio legt kein Gerät an

[Schneemann]

Hi,

Ich habe hier eine NXTCam für den Mindstorms NXT und wollte ein Programm schreiben, mit dem man die Kamera konfigurieren kann. Die Kamera wird per USB mit dem Computer verbunden. Außerdem benutzt die Kamera FTDI-8U232AM/245. D.h. ich brauche den ftdi-sio-Treiber.
Wenn ich jedoch den Treiber lade ("modprobe ftdi-sio" ist ja klar) und die Kamera verbinde, wird weder ein neues Device angelegt, noch irgendwas in dmesg ausgegeben.

Hier mal mein dmesg, wenn ich die Kamera verbinde:

usb 1-9: new full speed USB device using ohci_hcd and address 13
usb 1-9: configuration #1 chosen from 1 choice
usb 1-9: New USB device found, idVendor=0403, idProduct=abb8
usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-9: Product: NXTcam V2.0
usb 1-9: Manufacturer: mindsensors.com
usb 1-9: SerialNumber: 07RXUPIR

Hat irgendjemand eine Idee, was ich falsch mache?

 

[Gast1]

HAußerdem benutzt die Kamera FTDI-8U232AM/245. D.h. ich brauche den ftdi-sio-Treiber.

Und genau da wäre ich mir eben nicht so sicher, weil ...

Wenn ich jedoch den Treiber lade ("modprobe ftdi-sio" ist ja klar) und die Kamera verbinde, wird weder ein neues Device angelegt, noch irgendwas in dmesg ausgegeben.

Hier mal mein dmesg, wenn ich die Kamera verbinde:

usb 1-9: new full speed USB device using ohci_hcd and address 13
usb 1-9: configuration #1 chosen from 1 choice
usb 1-9: New USB device found, idVendor=0403, idProduct=abb8
usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-9: Product: NXTcam V2.0
usb 1-9: Manufacturer: mindsensors.com
usb 1-9: SerialNumber: 07RXUPIR

a) müsste das eigentlich automatisch gehen, daß udev den passenden Treiber lädt, wenn das Ding eingestöpselt wird

b) müsste sich die Device ID

usb 1-9: New USB device found, idVendor=[B]0403[/B], idProduct=[B]abb8[/B]

dann auch in einer der "alias" Zeilen von "modinfo <Modulname>" des passenden Treibers finden (einige, wenige Ausnahmen bestätigen die Regel, bei ftdi_sio gehe ich aber nicht von einer Ausnahme aus).

Ich finde diese Id jedenfalls weder im genannten Modul:

modinfo ftdi_sio |grep -i 0403 |grep -i abb8

noch in irgendeinem Modul meines derzeitigen Kernelbaums (2.6.27.29-default, openSUSE 11.1, Deine Distribution/Kernelversion hättest Du übrigens auch nennen sollen)

VENDORID=0403

DEVICEID=abb8

for i in $(find /lib/modules/`uname -r` -name "*.ko") ; do \
echo "$i" && /sbin/modinfo "$i"|grep -i "$VENDORID" |grep -i "$DEVICEID" ; \
done | while read ; do grep -B1 alias ; done

wieder.

 

[Schneemann]

Wenn ich aber im Windows-Treiber, den es für die NXTCam gibt, rumstöbere stoße ich ständig auf "FTDI FT8U232/245". Und damit meine ich nicht, dass das da einfach irgendwo steht, sondern, dass es wirklich so aussieht, als würde die NXTCam FTDI FT8U232/245 benutzen.

Hier gibt es den Windows-Treiber und noch einen Mac-Treiber, falls sich jemand selbst davon überzeugen will:
http://www.mindsensors.com/index.ph...entManager_op=viewDocument&JAS_Document_id=44

 

[Gast1]

Den Hinweis bezgl. Distribution hast Du wohl übersehen, aber im Nachhinein ist er wahrscheinlich nicht mal so wichtig, trotzdem solltest Du das Kind beim Namen nennen, vor allem Kernelversion wäre wichtig.

Warum ist es nicht entscheidend?

http://www.google.com/search?client=opera&rls=de&q=0403:abb8&sourceid=opera&ie=utf-8&oe=utf-8

Weil unter den Treffern gerade mal ein einziger mit Bezug zu Linux vorhanden ist, aber erst seit kurzem (Jo, es ist dieser Thread hier).

Normalerweise sind auch Tatsachen wie "es gibt einen Windows-/MACtreiber" meist relativ unwichtig, aber ironischerweise ist das dann wohl der einzige Hinweis, daß es eben vielleicht doch mit dem ftdi-sio klappen könnte.

Testen kann man das ganz einfach, sogar (wie ich vor kurzem gelernt habe) ohne den Treiber patchen und neu basteln zu müssen.

Eine Datei, nennen wir sie "/etc/modprobe.d/51-my-ftdi_sio.conf" mit folgendem Inhalt anlegen:

install ftdi_sio modprobe --ignore-install ftdi_sio ; /bin/echo "0403 abb8" > /sys/bus/usb/ftdi_sio/new_id

Hier heisst das Modul "ftdi_sio", also mit "_", vorher sicherheitshalber prüfen, ob es bei dir anders heisst, also mit "-" statt mit "_" und ggf. anpassen bzw. beide ausprobieren.

Sicher überprüfen kann man es, indem man dem Pfad in /sys/ folgt, weil da ist es garantiert wichtig, beim Modulnamen wird meist nicht zwischen "-" und "_" unterschieden.

Danach Kamera anstöpseln und als root:

modprobe -rv ftdi_sio

modprobe -v ftdi_sio

Wenn dann die Kamera läuft, Schwein gehabt, wenn nicht, dann zumindest prüfen, ob in der Datei "new_id" in obigem /sys/-Pfad auch wirklich die USB-ID drin steht.

Sollte das klappen, kann man Nägel mit Köpfen machen.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.
GNAH.


Warum gerade bei sowas gleich mehrere entscheidende Vertipper:

Also nochmal, und absichtlich als Neuer Beitrag (der dann eh mit rotem "Warnung, Antwort auf ...." in den vorigen reingeschoben wird, aber so wirds zumindest klar, daß ich mich vertippt hatte und nicht vielleicht noch die alte, fehlerhafte Version versucht wird).

1) Die Datei soll /etc/modprobe.d/51-my-ftdi_sio.conf heissen (nix udev, zumindest noch nicht, das kommt dann im Erfolgsfalle später).

2) Inhalt:

install ftdi_sio modprobe --ignore-install ftdi_sio ; /bin/echo "0403 abb8" > /sys/bus/usb/drivers/ftdi_sio/new_id

 

[Schneemann]

Also erstmal:

$ uname -a
Linux majestix 2.6.25.16-0.1-pae #1 SMP 2008-08-21 00:34:25 +0200 i686 athlon i386 GNU/Linux

Tut mir Leid, wenn ich mich etwas blöd anstelle, aber in /sys/bus/usb/ gibt es kein ftdi_sio und ich kann auch keinen Ordner anlegen.

 

[Gast1]

Ja, Vertipper sind heute meine Spezialität.

Eigentlich sollte es /sys/bus/usb/drivers/ftdi_sio/ sein, nur habe ich gerade herausgefunden, daß es dort keine Datei "new_id" gibt.

Aber, find hilft weiter, das Ding existiert trotzdem, aber in einem weiteren Ordner unter:

find /sys/bus/ -iname "new_id*" 
/sys/bus/pci/drivers/pcieport-driver/new_id
/sys/bus/pci/drivers/serial/new_id
/sys/bus/pci/drivers/ata_piix/new_id
/sys/bus/pci/drivers/ata_generic/new_id
/sys/bus/pci/drivers/PCI_IDE/new_id
/sys/bus/pci/drivers/uhci_hcd/new_id
/sys/bus/pci/drivers/ehci_hcd/new_id
/sys/bus/pci/drivers/r8169/new_id
/sys/bus/pci/drivers/agpgart-intel/new_id
/sys/bus/pci/drivers/jmb38x_ms/new_id
/sys/bus/pci/drivers/nvidia/new_id
/sys/bus/pci/drivers/i801_smbus/new_id
/sys/bus/pci/drivers/sdhci-pci/new_id
/sys/bus/pci/drivers/HDA Intel/new_id
/sys/bus/pci/drivers/iwlagn/new_id
/sys/bus/pci/drivers/ohci_hcd/new_id
/sys/bus/usb/drivers/usbfs/new_id
/sys/bus/usb/drivers/hub/new_id
/sys/bus/usb/drivers/uvcvideo/new_id
/sys/bus/usb/drivers/hiddev/new_id
/sys/bus/usb/drivers/usbhid/new_id
/sys/bus/usb-serial/drivers/generic/new_id
[B]/sys/bus/[COLOR="Red"]usb-serial[/COLOR]/drivers/ftdi_sio/new_id[/B]

Also den Pfad entsprechend in der 51-my-ftdi_sio.conf anpassen und dann auf ein Neues:

Modul entladen, Modul laden und sich überraschen lassen.

 

[Schneemann]

Funktioniert Danke. Ich hab jetzt ein Gerät /dev/ttyUSB0

Ich hab übringens auch mal den Vertreiber der NXTCam angeschrieben, der hat das mit dem FTDI bestätigt. Ist aber jetzt sowieso schon geklärt.

Ist das jetzt eigentlich eine langfristige Lösung oder muss ich da noch was machen?

 

[Gast1]

Funktioniert Danke. Ich hab jetzt ein Gerät /dev/ttyUSB0

Holla, da bin ich jetzt aber selbst überrascht.

Ich hab übringens auch mal den Vertreiber der NXTCam angeschrieben, der hat das mit dem FTDI bestätigt. Ist aber jetzt sowieso schon geklärt.

Also funktioniert jetzt auch das Gerät selbst und es ist nicht nur das neue device da?

Ist das jetzt eigentlich eine langfristige Lösung oder muss ich da noch was machen?

Nein, es ist _fast_ fertig, aber nun sitzt Du in der Falle, *Ätsch*, denn wenn das wirklich funktioniert, dann machen wir Nägel mit Köpfen.

Der funktionale Teil ist jetzt schnell erledigt, aber danach gibt es ne "böse" PN, You don't know, what just hit you.

(Keine Sorge, Du wirst es überleben.)

OK, nun brauchts noch eine nette, kleine udev-Regel, nennen wir sie "/etc/udev/rules.d/51-my-ftdi_sio.rules" mit Inhalt:

ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="abb8", RUN+="/sbin/modprobe ftdi_sio"

Danach sollte das Ding beim Einstöpseln automatisch aktiviert werden.

Die zweite Lösung, die dann auch das ist, was ich vorhabe, wenn der Kram damit wirklich funktioniert, gibts dann auch per PN.

 

[slackfan]

Würde jemand der Nachwelt (bzw. mir ) erklären, was hier passiert ist? Ist es richtig, dass man dem Treiber in diesem Fall erst über die new_id Pseudo-Datei beibringen musste, dass er sich um die Funktionalität des Geräts kümmern soll und das auch kann? Ist das ein Bug im Treiber oder ist das normal, weil das Gerät z.B. erst nach dem Treiber veröffentlicht wurde?

cu

 

[Schneemann]

Eventuell hat das was damit zu tun, dass FTDI seine ProductIDs sehr sehr komisch vergibt. Liegt glaub ich daran, weil dahinter ja immer ein Produkt einer anderen Firma hängt.

EDIT: Hab die NXTCam in minicom getestet. Hat funktioniert. "GV<RETURN>" liefert mir "NXTCam V2.0". Alles wo wie es sein soll. Das einzig komische war, das sie zwischendurch nicht mehr wollte und als ich das Windowsprogramm für die Kamera ausprobiert habe, gab's nen BSOD.

 

[Gast1]

Würde jemand der Nachwelt (bzw. mir ) erklären, was hier passiert ist?

Was hier passiert ist, ist eigentlich etwas ganz Triviales, es sieht nur viel komplizierter aus, vor allem weil der Lösungsweg ein anderer ist, als z.B. ich ihn bisher bei ähnlich gelagerten Problemen eingeschlagen habe (das war für mich der interessante Teil am Problem).

Ist es richtig, dass man dem Treiber in diesem Fall erst über die new_id Pseudo-Datei beibringen musste, dass er sich um die Funktionalität des Geräts kümmern soll und das auch kann?

Ja, so in etwa kann man das sagen, der Grund dafür ist aber ganz einfach, denn:

Ist das ein Bug im Treiber oder ist das normal, weil das Gerät z.B. erst nach dem Treiber veröffentlicht wurde?

Es ist so gesehen kein Bug und ob das der Grund ist, kann ich nicht sagen, aber was der Grund für die "Handarbeit" ist, kann ich Dir sagen.

Für das automatische Laden eines Moduls ist heutzutage udev zuständig und udev (oder jeder andere, vergleichbare Mechanismus) braucht ja irgendeinen Anhaltspunkt, welchen Treiber er laden soll, wenn $GERÄT angestöpselt wird.

Da es aber zu der USB ID keinen passenden Eintrag in den verfügbaren Kernelmodulen gab, ist eben auch nichts passiert.

"Früher" hätte ich mir den Treiber vorgenommen, die ID in den Quellcode reingepatcht, ein Paket gebastelt (sofern der Fragesteller irgendeine openSUSE verwendet) oder dem TE den Patch zur Verfügung gestellt, damit er dies selbst tun kann.

Der Unterschied zu hier ist, daß man mit der obigen Methode auch ohne einen gepatchten Treiber auskommt, indem man durch eine Datei bestimmte Optionen für das Laden eines Moduls mitgibt und dann noch per udev-Regel das automatische Laden verankert, das heisst, dieses mal hatte nicht ich sondern der Fragesteller die ganze Arbeit, zumindest bis hierhin.

Nicht, weil ich zu faul dazu wäre, sondern weil man so zunächst mal testen kann, ob der vermutete "Treiberkandidat" wirklich der richtige ist. Prinzipiell hätte man mit der Methode auch dafür sorgen können, daß die ID irgendeinem anderen Kernelmodul zugeordnet wird, das würde auch soweit "funktionieren", ob aber die Kamera mit z.B. einem USB WLAN-Treiber was anfangen kann, ist dann doch eher fraglich.

Und sollte das Ding denn nun wirklich mit dem ftdi_sio funktionieren, dann kommt anschliessend der zweite Schritt, der "früher" der erste gewesen wäre, nur eben dann auch "konsequent durchgezogen".

Ich werde einen Patch schreiben, der diese ID in den ftdi_sio einbindet und diesen dann auch an den entsprechenden Maintainer weitergeben, damit die Änderung hoffentlich in den Mainline Kernel aufgenommen wird und die Kamera OOTB funktioniert.

Dazu muss der Schneemann eben noch einen Funktionstest machen, denn neues Device /dev/tty0USB ist zwar schön, aber reicht leider noch nicht aus.

Was man aber machen könnte, um vielleicht schon augenscheinliche Probleme zu sehen ist das hier:

1) Kamera abstöpseln

2)

su 

Passwort

modprobe -rv ftdi_sio #Modul entladen

tail -F /var/log/messages #"Überwachungskonsole" starten

3) Kamera einstöpseln und mal nachsehen, was einem so entgegen geworfen wird.

Greetz,

RM

P.S.

Am gepatchten Paket arbeite ich noch, da ich es für openSUSE 11.0 - 11.2 bauen will, ist da noch ein wenig Mehraufwand zu leisten.

Einen Patch wird es aber auf jeden Fall geben, denn ich habe hier noch eine weitere, "fehlende" ID auf Halde liegen, bei der der TE damals "stiften" gegangen ist, nachdem es wohl funktionierte, (sowas ärgert mich dann gewaltig, weshalb ich den Patch bis heute nicht eingereicht habe), die Frage ist nun nur noch, stehen in dem Patch eine oder zwei neue IDs drin.

 

[slackfan]

Danke für die informative Aufklärung!