raspbian: kernel module patchen/compilieren -> Exec format error

[Mickey Mouse]

für ein spezielles Gerät (Strom/Energie Messgerät) muss ich einen USB serial Treiber (kernel module cp210x) patchen.
leider bekomme ich das ums Verrecken nicht hin.
das Compilieren klappt soweit, aber wenn ich das modul laden möchte, bekomme ich:
modprobe: ERROR: could not insert 'cp210x': Exec format error
dmesg: [ 983.543634] cp210x: disagrees about version of symbol module_layout

ich vermute, dass meine Sourcen, die ich mir mit rpi-source besorgt habe, nicht zu meinem Kernel/System (stretch/4.19.66-v7+) passen.
auch eine neue Module.symvers (wie in dem o.g. link beschrieben per wget gesaugt) hat nicht geholfen.

ich hatte mir das so einfach vorgestellt: zum Source gehen (da hatte ich erwartet, dass man den "ganz einfach" bekommt, bzw. schon installiert ist), zcat /proc/config.gz > .config (selbst das geht nicht direkt out of the box), file patchen, make und gut
das es so ein Stress ist, "mal eben" ein Module zu patchen, hätte ich nicht gedacht...

auf der anderen Seite möchte ich mir auch nicht das ganze System kaputt spielen (läuft gerade so schön rund ) und auf den selbst kompilierten Kernel inkl. sämtlicher Module umstellen.
ach ja, testweise habe ich das usbserial Module gleich mit übernommen (muss vorher geladen werden), da passiert das gleiche (format error/disagrees).

 

[Phrasendreher]

Hej,

Was erhältst Du mit "modinfo cp210x"? Woher hast Du den Source-Code für cp210x?

In meinen apt-Quellen finde ich kein solches Modul, daher würde ich auch davon ausgehen, dass das von Dir extern bezogene Modul nicht zu dem Kernel passt.

 

[Mickey Mouse]

es existiert im plain vanilla system bereits ein Modul cp210x(.ko), das sich auch problemlos laden lässt, nur liefert das mit meiner Hardware keine Daten
dafür muss man im Source eine Abfrage einbauen und "0 Baud" auf 250000 setzen (nur so am Rande)

zumindest nach meinen Recherchen ist es ja scheinbar nicht so einfach bis hin zu unmöglich, zu einem "fertigen" Raspbian System die passenden Sourcen zu bekommen. Jedenfalls liefert eine Google Suche nach "raspbian apt-get kernel source" keine (vernünftigen) Ergebnisse, bzw. endet alles immer in dem bereits von mir verlinkten rpi-source tool, um sich die zum laufenden System passenden Sourcen von Github zu laden.
mit einem apt-get schein das nicht erledigt zu sein (sorry, ich bin da seit Jahrzehnten (und das ist NICHT übertrieben) raus und danach habe ich nur noch mit extrem anwenderfreundlichen SuSE gearbeitet, mit Yast sind das ja nur zwei drei Mausklicks...).

auf jeden Fall ist auch hier Linux irgendwie nicht mehr das was es früher mal war. Im Hauptverzeichnis gibt es zwar eine .version Datei, aber da steht nur "1" drin, ganz großes Kino, was soll denn so ein Mist?!?
laut Makefile (klar, da gehört auch die Versionsnummer rein...) hat rpi-source mir:

VERSION = 4
PATCHLEVEL = 19
SUBLEVEL = 66
EXTRAVERSION =
NAME = "People's Front"

gesaugt, mein Kernel ist:

root@raspberrypi-2:~/linux# uname -r
4.19.66-v7+

gesaugt, also ganz daneben liege ich nicht.

wie gesagt, die .config habe ich aus /proc/version.gz von dem laufenden System geholt. Erst habe ich nur das einzelne Modul compiliert, als das nicht lief alles und zur Sicherheit einmal in "make menuconfig", ohne Änderungen einmal save und dann "make all".

modinfo:
"mein"

filename:       /lib/modules/4.19.66-v7+/kernel/drivers/usb/serial/cp210x.ko
license:        GPL v2
description:    Silicon Labs CP210x RS232 serial adaptor driver
srcversion:     F699BD9407D21C3728D71FB
alias:          usb:v413Cp9500d*dc*dsc*dp*ic*isc*ip*in*
...
alias:          usb:v045Bp0053d*dc*dsc*dp*ic*isc*ip*in*
depends:        usbserial
intree:         Y
name:           cp210x
vermagic:       4.19.66-v7+ SMP mod_unload modversions ARMv7 p2v8

dmesg:

[ 2246.168892] cp210x: disagrees about version of symbol module_layout

"original"

filename:       /lib/modules/4.19.66-v7+/kernel/drivers/usb/serial/cp210x.ko
license:        GPL v2
description:    Silicon Labs CP210x RS232 serial adaptor driver
srcversion:     50F2FC1458F854DDE6A5CC8
alias:          usb:v413Cp9500d*dc*dsc*dp*ic*isc*ip*in*
...
alias:          usb:v045Bp0053d*dc*dsc*dp*ic*isc*ip*in*
depends:        usbserial
intree:         Y
name:           cp210x
vermagic:       4.19.66-v7+ SMP mod_unload modversions ARMv7 p2v8

dmesg dazu:

[ 2104.349514] usbcore: registered new interface driver cp210x
[ 2104.349566] usbserial: USB Serial support registered for cp210x

 

[Phrasendreher]

Und wenn Du mit dem mitgelieferten Treiber Dein USB-Gerät einsteckst, erhältst Du keine Ausgabe dazu mit dmesg? Oder gibt's eine Fehlermeldung?

Wie Du Deinen "eigenen" gepatcheten Treiber installieren könntest, kann ich Dir leider auch nicht sagen.

Interessante Infos zu Raspbians cp210x.ko gibt es hier (falls Du es noch nicht gelesen hattest):
https://unix.stackexchange.com/questions/299599/usb-to-serial-device-wont-assign-cp210x-driver

 

[Mickey Mouse]

mit dem "originalen" Module ist alles soweit in Ordnung (findet das Device usw.) nur die Software (FHEM) liefert damit keine Daten, dafür braucht es diesen Patch.

irgendwie nervt es mich fürchterlich an, dass es so ein Akt ist ein simples Modul zu kompilieren. Selbst wenn ich es NICHT patche sondern nur compiliere, kann ich es nicht laden.

auf der anderen Seite bin ich aber auch zu faul, mich für solchen Mist erst tief in Kernel Development einzuarbeiten um zu lernen, was es denn mit diesem ominösen Module.symvers auf sich hat. Das scheint nach allem was ich bisher zu dem Thema gefunden habe wohl das Problem zu sein.
Aber da bleibt mir wohl nichts anderes übrig, weil die üblichen Anleitungen nach dem Motto: mach' das und das (ohne auch nur ansatzweise auf das "warum" oder "wozu" einzugehen) nicht funktionieren.

es kann doch nicht sooooo schwer sein, ein Modul passend zum laufenden Kernel zu compilieren?!?
andere Leute machen das per Cross-Compiler auf einer völlig anderen Maschine und verteilen die fertigen Module im Netz (nur (noch) nicht für die aktuelle Kernel Version), da muss es doch einen Trick geben?!?

 

[Phrasendreher]

Verstehe Deinen Frust - denn ich habe selber nicht genug Zeit, mich im Detail in das Thema einzuarbeiten (obwohl ich schon lange daran interessiert bin).
Dass ich mir zum letzten Mal einen eigenen Kernel kompiliert habe, ist auch bestimmt schon deutlich über ein Jahrzehnt her (also nicht für den Raspi).

Hätte auch nicht erwartet, dass es problematisch ist, die original-Sourcen für das Modul zu bekommen; da wirst Du nun entscheiden müssen, ob Dein Projekt es wert ist, sich in die scheinbare Modul-Inkompatibilität einzuarbeiten, aber FHEM klingt schon sehr spannend.

Falls Du es hinbekommst (was ich hoffe), fänd ich es klasse, wenn Du ein How-To oder einen Erfahrungsbericht dazu verfassen würdest, auch in Hinblick auf die Hausautomation und die Einbindung externer Geräte an den Server!

 

[lokon]

Ich habe mal kurz recherchiert und ein paar potentielle Probleme identifiziert:

für ein spezielles Gerät (Strom/Energie Messgerät) muss ich einen USB serial Treiber (kernel module cp210x) patchen.

Bei Fehlermeldungen hilft es zuerst die verwendete Hardware zu benennen. Gerade bei Gerätetreibern.
Außerdem die verwendete Software / Einsatzbereich.

Vermutung: Es handelt sich um ein OWL +USB Energiemonitor

muss ich einen USB serial Treiber (kernel module cp210x) patchen.

Ich glaube hier liegt ein Fall von XY Problem vor.

dafür muss man im Source eine Abfrage einbauen und "0 Baud" auf 250000 setzen (nur so am Rande)

250000 wird vom Kernel inzwischen unterstützt - in den Kommentaren + Source steht das auch explizit in Zeile 1081 und 1033

siehe auch diesen Post (u.a. dynamisch USB Geräte unterstützen) - und lt diesem raspi forumsfaden
cm160Server.py aus dem electricowl Projekt nutzte aus "irgendwelchen" Gründen (vermutlich fehlender Support im Kernel damals) den Treiberhack . lt. sourcecode fragt er nach der baudrate 0
dies wurde vermutlich in einige andere Projekte wie FHEM übernommen.
Andere Projekte nutzen für die OWL Hardware die normale 250000 Baudrate der seriellen Schnittstelle:
Eagle-owl nutzt keine speziellen Kerneltreiber und die 250000 Baudrate (src/cm160.c Zeile 300)

Also: Änderung der Abfrage / Code im FHEM (?) ist die Lösung.
In dem einen 60_CM160.pm aus CM160.zip Zusatzmodul für FHEM geht das einfach per Schalter/Änderung im Quellcode: Kommentar entfernen und Zeile mit kommentar versehen. (Zeile 136 und 137)
Keine Ahnung welchen genauen Quellcode du wie verwendest.

 

[lokon]

PS: Die 250000 Baudrate sind mit bestimmter Hardware quasi-standardisiert (Arduino). siehe länger hier oder hier auf github - die Projekte laufen seit ~2015 mit diesen Raten. Da sollte FHEM (?)/Module das eigentlich auch hinkriegen und keinen ~6 Jahre alten Hack im Kernel benutzen

 

[Mickey Mouse]

vielen Dank für deinen Hilfe Versuch, funktioniert aber leider genauso wenig.
und Kernel Module compilieren kann ich immer noch nicht

es ist völlig egal was zusammen mit dem originalen Modul als "Wunschwert" im FHEM Modul eingetragen wird, 0, 250000, 254000 oder sogar -1, es kommt immer "connected" oder "opened" als Status (keine Fehlermeldung) aber keine Daten.
so einfach scheint das also doch nicht zu sein. Oder alle anderen sind genauso blöd wie ich, warum wird immer noch nach den patchten Kernel-Modulen für die aktuellen Kernel gesucht?!?

wenn wir jetzt schon 100% offtopic sind:
ich könnte jetzt ein weiteres Fass aufmachen und versuchen USB zu umgehen und die Funk Signale vom Sensor direkt per 433MHz Receiver zu empfangen, aber wer weiß was da wieder alles nicht funktioniert oder schief geht.
ich denke mal, dass ich es bei der Windows Software belasse, das ist mir einfach viel zu viel Stress und vor allem gibt es keine Doku und keine klare Übersicht über die Versionen. Z.B. habe ich zwei (völlig!) verschiedene 60_CM160.pm Module gefunden, die beide dieselbe Versionsnummer (1.0) aus 2012 tragen aber noch nachträglich umgestrickt wurden. Laufen tun sie (natürlich...) beide nicht.

 

[lokon]

und Kernel Module compilieren kann ich immer noch nicht

Ich habe mal auf einem "produktiv" Raspi 3B via PINN ein Raspian gebootet und konnte modifizierte Kernelmodule erstellen und installieren. Ein paar seltsame Probleme traten dabei jedoch auf.

Für Testmodule / out-of-tree Kernelmodule liefert Raspian inzwischen Kernel-Headers aus und rpi-source wird für diesen Fall nicht benötigt.
Anwendungsbeispiele: Wenn die Herstellertreiber von WLAN Sticks installiert werden sollen oder neue Hardware deren Module nicht in den Kernel integriert sind.

(Betrifft dich glaube ich nicht lt. deiner geposteten Kernel-Version)
Bekannte Bugs von rpi-source sind evtl. auf github/issues - teilweise sind Bugs noch nicht gefiled - so scheint es momentan noch keine Unterstützung für den Raspberry Pi 4 zu geben - dessen Module.symvers Datei wird nicht kopiert.

Ansonsten:

Für modifizierte in-tree Module funktioniert rpi-source

cd anderes Dir wegen Platzmangel auf rootfs>
wget https://raw.githubusercontent.com/notro/rpi-source/master/rpi-source
chmod +x rpi-source
./rpi-source --tag-update -d <anderes Dir wegen Platzmangel auf rootfs>
./rpi-source -d <anderes Dir wegen Platzmangel auf rootfs>
cd linux
nano drivers/usb/serial/cp210x.c
make prepare
make modules_prepare
make SUBDIRS=scripts/mod
make SUBDIRS=drivers/usb/serial modules
sudo insmod drivers/usb/serial/usbserial.ko
sudo insmod drivers/usb/serial/cp210x.ko

Das erstellt den Unterbaum aller usbserial Module.

Das einzelne cp210x.ko Modul aus dem Kompilat wollte er nicht laden - der Fehler war zBcp210x: disagrees about version of symbol usb_serial_generic_open
Mit sudo modprobe --dump-modversions drivers/usb/serial/cp210x.ko
und einem Vergleich zu dem originalen /lib/modules/.../cp210x.ko sieht man, dass die Felder bei den Fehlermeldungen der Symbole "usb_serial_generic_open" und anderer unterschiedlich sind.
Die alte usbserial.ko passt scheinbar nicht mehr und muss deshalb auch ersetzt werden. Eventuell liegt es daran, dass der ganze Unterbaum (SUBDIRS) kompiliert wurde und nicht nur ein Modul.
Das Insmod der neuen Module ist aber erfolgreich:

[] usbserial: USB Serial deregistering driver generic
[] usbcore: deregistering interface driver usbserial_generic
[] usbcore: registered new interface driver usbserial_generic
[] usbserial: USB Serial support registered for generic
[] usbcore: registered new interface driver cp210x
[] usbserial: USB Serial support registered for cp210x

deregistering des alten /lib/modules Treibers, registering von dem neuen Treiber via insmod

Ohne Hardware habe ich lediglich eine neue USB ID "erfunden" und in den Quelltext eingefügt - diese neue USB-ID wird im kompilierten Modul als supportet angezeigt

sudo modinfo linux/drivers/usb/serial/cp210x.ko  |grep CCCC
alias:          usb:v0FDEpCCCCd*dc*dsc*dp*ic*isc*ip*in*

Oder alle anderen sind genauso blöd wie ich, warum wird immer noch nach den patchten Kernel-Modulen für die aktuellen Kernel gesucht?!?

Weil es keine Perl/FHEM Entwickler mit dieser Hardware gibt , die das Projekt aktuell halten und die eventuell mal ohne Kernelmodifikation prüfen ob es funktioniert - ist halt Zeit+Aufwand gegenüber "Cargo Cult Programming" / "Building" - das owl-netdata greift nicht über den Kernel darauf zu also sollte mit den richtigen Serial-Einstellungen das Ding laufen.
Das CM... Modul ist nicht Bestandteil von FHEM - das wurde nie integriert und der "schnelle Hack" war für viele gut genug und ~2012 wohl notwendig.
Bzgl FHEM: Inzwischen hat Perl als Programmiersprache auch Probleme und SVN als Quellcode-Management lädt vielleicht nicht so viele zur Mitarbeit ein.

Funk Signale vom Sensor direkt per 433MHz Receiver

Die OWL Hardware via Funk scheint direkt in FHEM unterstützt - seit 2012 in TRX_WEATHER lt changeset 2125 .

ich denke mal, dass ich es bei der Windows Software belasse, das ist mir einfach viel zu viel Stress und vor allem gibt es keine Doku und keine klare Übersicht über die Versionen

Naja - es kann ja jeder im Forum schreiben, fragen und die Lösungen oder Probleme dann Dokumentieren und dort im Wiki ablegen. Oder den Quellcode auf Github und nicht nur im Forum/Blog stellen. Aus einer Vielzahl von Gründen wird dass nicht oft genug gemacht.
Die Leute könnten im FHEM Forum auch links zu dem Treibercode/Source posten - ich sehe nur keine in dem "cm160 für raspi Modul" Thread - Als nicht angemeldeter User sehe ich keine Anhänge im FHEM Forum, die mögliche Quell-Codes etc. beinhalten.