USB-zu-Ethernet Adapter für ein Embedded-Linux

[[o.0]]

Hallo zusammen, heute mal wieder eine ausgefallenere Frage

Ich bin leider in der unglücklichen Lage, eine Ethernet Verbindung per USB-zu-Ethernet-Adaptern zwischen zwei eingebetteten Linux Systemen (Overo Fire Coms] auf RoboVero Extension Boards) herstellen zu müssen.

Nun gut, bei einem "richtigen" PC würde ich mir dabei wenig Sorgen machen. Allerdings gehe ich davon aus, dass Plug and Play bei so einem abgespeckten Mini-Linux wohl eher nicht funktionieren wird.

Mein bisheriger Plan ist, mir einen passenden Adapter auszusuchen. Dieser hier wäre meiner Meinung nach eine gute Wahl, da er laut Kommentaren auf einem "ASIX 88179" Chip basiert, für den es auf der Hersteller Seite Source Code zum selbstkompilieren der Treiber gibt. Eine VM mit einer funktionierenden Tool Chain fürs Cross-Compiling hätte ich auch schon zum Laufen gebracht, zumindest "Hello World" funktioniert. Meine Hoffnung war jetzt, dass ich einfach den Treiber als Kernelmodul kompilieren und aufs Board kopieren kann. Mit modprobe laden und fertig.
Scheint aber wohl nicht so einfach zu sein, denn in der Readme des Treibers steht als Hinweis folgendes:

Prepare to build the driver, you need the Linux kernel sources installed on the
build machine, and make sure that the version of the running kernel must match
the installed kernel sources. If you don't have the kernel sources, you can get
it from www.kernel.org or contact to your Linux distributor. If you don't know
how to do, please refer to KERNEL-HOWTO.

Note: Please make sure the kernel is built with one of the "Support for
Host-side, EHCI, OHCI, or UHCI" option support.

[...]

If the compilation is well, the ax88179_178a.ko will be created under the current
directory.

So, jetzt das Problem. Der Kernel wird/wurde von jemand anderem kompiliert und selbst werde ich das vermutlich nicht hinbekommen. Reicht es, wenn ich mir einfach mit uname die aktuell laufende Version des Kernel auslese, den entsprechenden Source Code von kernel.org runterlade und das compiliere? Völlig unabhängig davon, was die eigentliche Kernel-Person alles eingestellt und gepatcht hat?

Und ist diese "Host-side, EHCI, OHCI, or UHCI"-Unterstützung etwas exotisches und ich komm eh nicht um ein neu-compilieren rum oder ist das vermutlich eh aktiviert? Von dem was Google ausspuckt würde ich tippen, dass das vermutlich sinnvollerweise mit drin ist, immerhin hat jedes der Boards zwei USB Buchsen.

Oder noch besser wäre es, wenn jemand ein fertiges Kernel-Modul zur Hand hätte. Aber soviel Glück werde ich vermutlich nicht haben.. und ehrlich gesagt wüsste ich auch nicht in welchen Repos sowas rumfahren könnte

Viele Grüße

 

[antiheld84]

Das würde ich so nicht mal ansatzweise so lösen. Beide Module unterstützen SPI und UART von Haus aus, also direkt damit arbeiten oder zB.: mit einem ENC28J60 von SPI auf LAN.

 

[mensch183]

Mein bisheriger Plan ist, mir einen passenden Adapter auszusuchen. Dieser hier wäre meiner Meinung nach eine gute Wahl, da er laut Kommentaren auf einem "ASIX 88179" Chip basiert, für den es auf der Hersteller Seite Source Code zum selbstkompilieren der Treiber gibt.

Brauchst nicht mit Treibern aus dem Web rumfrickeln. Für den genannten Chip gibts Support im Mainline-Kernel. Device Drivers --> Network device support --> USB Network Adapters --> Multi-purpose USB Networking --> ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet. Das erzeugte Kernelmodul dürfte "ax88179_178a.ko" heißen.

Falls du auf einen antiken Kernel angewiesen bist: Wähle Hardware, die dieser Kernel von Haus aus unterstützt. Du hast doch freie Wahl bei der Hardware, wenn ich dich richtig verstanden habe.

 

[Kanibal]

(falls du es dennoch mit dem USB-Gerät lösen möchtest)
Deine Richtung ist schon richtig... Du brauchst halt einen Cross-Toolchain (auf ARM). Dieser musst Du noch die korrekten Linux-Headers mitgeben (PATH anpassen, chroot hilft dir da evtl.), und dann musst du das Modul dafür kompilieren und in deinen Kernel reinladen.

 

[[o.0]]

Vielen Dank schonmal für eure Antworten.

Das würde ich so nicht mal ansatzweise so lösen. Beide Module unterstützen SPI und UART von Haus aus, also direkt damit arbeiten oder zB.: mit einem ENC28J60 von SPI auf LAN.

Ja, ist eigentlich noch nicht mal suboptimal.. soll aber nunmal leider so gelöst werden

Brauchst nicht mit Treibern aus dem Web rumfrickeln. Für den genannten Chip gibts Support im Mainline-Kernel. Device Drivers --> Network device support --> USB Network Adapters --> Multi-purpose USB Networking --> ASIX AX88179/178A USB 3.0/2.0 to Gigabit Ethernet. Das erzeugte Kernelmodul dürfte "ax88179_178a.ko" heißen.

Vermutlich Kernel 3.4.9, älter eher nicht. Support sollte also eigentlich im Mainline Kernel vorhanden sein, stimmt. Allerdings müsste ich so ja auch einen neuen Kernel kompilieren, was schlecht ist, wenn ich die paar dutzend Einstellungen nicht weiß, die jemand anderes gemacht hat. Oder kann ich mir einfach "irgend einen" Kernel mit beliebigen Einstellungen kompilieren und das fertige Kernelmodul in den anderen, bereits existierenden Kernel reinladen?

Deine Richtung ist schon richtig... Du brauchst halt einen Cross-Toolchain (auf ARM). Dieser musst Du noch die korrekten Linux-Headers mitgeben (PATH anpassen, chroot hilft dir da evtl.), und dann musst du das Modul dafür kompilieren und in deinen Kernel reinladen.

Okay, wenn das geht, gut. Die Variante von mensch183 wäre aber natürlich noch mal eine Nummer einfacher, wenn ich das richtig verstanden habe.

 

[mensch183]

Vermutlich Kernel 3.4.9, älter eher nicht. Support sollte also eigentlich im Mainline Kernel vorhanden sein, stimmt.

Nicht in 3.4. Erst ab 3.9.

was schlecht ist, wenn ich die paar dutzend Einstellungen nicht weiß, die jemand anderes gemacht hat. Oder kann ich mir einfach "irgend einen" Kernel mit beliebigen Einstellungen kompilieren und das fertige Kernelmodul in den anderen, bereits existierenden Kernel reinladen?

Die .config des Kernels, in der die Einstellungen stehen, liegt bestimmt irgendwo rum. Meist direkt neben dem Kernelimage. Eventuell ist sie sogar als /proc/config.gz dem laufenden Kernel zu entlocken.

Um Module in einen Kernel anderer Version laden zu können, müssen beide Seiten mit CONFIG_MODVERSIONS gebaut worden sein. Und auch dann geht das nur, wenn sich an dem jeweiligen Interface nichts geändert hat.

 

[[o.0]]

Die .config des Kernels, in der die Einstellungen stehen, liegt bestimmt irgendwo rum. Meist direkt neben dem Kernelimage. Eventuell ist sie sogar als /proc/config.gz dem laufenden Kernel zu entlocken.

Das seh ich vermutlich erst nächste Woche, werde dann mal nachschauen, Danke.

Um Module in einen Kernel anderer Version laden zu können, müssen beide Seiten mit CONFIG_MODVERSIONS gebaut worden sein. Und auch dann geht das nur, wenn sich an dem jeweiligen Interface nichts geändert hat.

Und wenn beides die gleiche Kernel-Version ist? Geht das dann problemlos?

 

[mensch183]

Fast. Ist der Kernel ohne CONFIG_MODVERSIONS gebaut, muß auch das Modul zwingend ohne gebaut werdem. Ist der Kernel mit CONFIG_MODVERSIONS gebaut, sollte beide Arten Module funktionieren.

 

[[o.0]]

Ah, okay, vielen Dank. Dann mal abwarten wie der Kernel wirklich aussieht wenn ich ihn habe.

 

[[o.0]]

So, hat ein bisschen länger gedauert, aber ich hab mittlerweile den Kernel bekommen und zum laufen gebracht. Zum Glück hab ich auch, wie vorgeschlagen, die proc/config.gz auslesen können (siehe Anhang).

# uname -a
Linux overo 3.4.9-rt17 #3 SMP PREEMPT RT Tue Sep 10 06:41:08 PDT 2013 armv7l GNU/Linux
#
# cat config | grep MODVERSIONS
CONFIG_MODVERSIONS=y

Wie es aussieht sind auf dem jungfräulichen System weder Kernelmodule gelanden noch überhaupt vorhanden, kann das sein?

# lsmod
Module                  Size  Used by    Not tainted
#
# modprobe -l
modprobe: chdir(/lib/modules): No such file or directory

Also werd ich wohl das Kernelmodul doch aus dem Treiber des Herstellers kompilieren müssen. In der Anleitung dazu steht:

================
Prerequisites
================

Prepare to build the driver, you need the Linux kernel sources installed on the
build machine, and make sure that the version of the running kernel must match
the installed kernel sources. If you don't have the kernel sources, you can get
it from www.kernel.org or contact to your Linux distributor. If you don't know
how to do, please refer to KERNEL-HOWTO.

Note: Please make sure the kernel is built with one of the "Support for
Host-side, EHCI, OHCI, or UHCI" option support.

[...]


================
Getting Start
================

1. Extract the compressed driver source file to your template directory by the
following command:

[root@localhost template]# tar -xf DRIVER_SOURCE_PACKAGE.tar.bz2

2. Now, the driver source files should be extracted under the current directory.
Executing the following command to compile the driver:

[root@localhost template]# make

3. If the compilation is well, the ax88179_178a.ko will be created under the current
directory.

4. If you want to use modprobe command to mount the driver, executing the
following command to install the driver into your Linux:

[root@localhost template]# make install

Ich hol mir also den Sourcecode zu Kernel 3.4.9 bei kernel.org und kopier die zusammen mit den Treiber-Dateien in meine VM, in der ich die Cross-Compile-Toolchain installiert habe. Im Makefile änder ich den angegeben Compiler zu dem Cross-Compiler, lasse "make" laufen und erhalte hoffentlich dieses "ax88179_178a.ko" Kernelmodul. Dieses kopiere ich auf den Overo. Schritt 4 macht mir ein wenig Angst, da auf dem Overo-Image kein "make" installiert ist und ich somit auch kein "make install" ausführen kann. Ist das ein Problem?

Angenommen das geht trotzdem:

If you want to load the driver manually, go to the driver directory and
execute the following commands:

[root@localhost template]# modprobe usbnet
[root@localhost template]# insmod ax88179_178a.ko

Wo kommt denn in der Anleitung plötzlich das usbnet Modul her?^^ Bräuchte ich das etwa auch? Auf dem Overo gibt es ja wie oben schon gezeigt kein einziges Modul, das müsste ich also auch erstmal irgendwie herbekommen..


Die als Voraussetzung angegeben EHCI etc Einstellungen müssten ja erfüllt sein?

# cat config | grep EHCI
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_HCD_OMAP=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# cat config | grep UHCI
# cat config | grep OHCI
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB_OHCI_HCD is not set

Vielen Dank schonmal für die Geduld und Hilfe