Treiber für die TechnoTrend Premium S2-6400 lässt sich unter Fedora 24 mit Kernel 4.6.x nicht kompilieren

  • Nur mal so ganz unbedarft nachgefragt: Ist es für Euch keine Option, 'n Versuch zu starten, den Treiber in Mainline zu pushen?

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • +1 Bitte den kompletten Patch von S:oren nach Mainline. Sehr gute Idee.

  • Beim Kompilieren auf dem Kernel 4.15.3 mit gcc (GCC) 7.3.1 bekomme ich nun folgende Fehlermeldung:

    gibt dazu schon eine Abhilfe ?

    Gruß Marco


    HW: TeVii S471 S/S2, TT6400-S2
    SW: Fedora 31, kernel-5.4.2-300.fc31.x86_64, vdr-2.4.1-2.fc31.x86_64

  • Hallo,


    ich bin auf den Kernel- 4.16.3-300.fc28.x86_64 umgestiegen, da ich unter Fedora28 vdr paketieren muss.

    Dazu habe ich saa716x-4.16 runter geladen und das Makefile entsprechend angepasst.


    Die Fedora spezifischen Header-Dateien kopiere ich wie gewohnt nach /usr/include/linux


    Beim Kompilieren bekomme ich die folgende Fehlermeldung:


    Die Header-Datei existiert aber:

    ll /usr/include/linux/mb86a16.h

    -rw-r--r-- 1 root root 2315 20. Apr 13:43 /usr/include/linux/mb86a16.h


    Hat jemand eine Abhilfe hier ?

    Gruß Marco


    HW: TeVii S471 S/S2, TT6400-S2
    SW: Fedora 31, kernel-5.4.2-300.fc31.x86_64, vdr-2.4.1-2.fc31.x86_64

    The post was edited 3 times, last by marco ().

  • Die Header-Datei existiert aber:


    ll /usr/include/linux/stv6110x.h

    -rw-r--r-- 1 root root 2315 20. Apr 13:43 /usr/include/linux/stv6110x.h

    Das mag schon sein.


    Wer lesen kann, ist klar im Vorteil.8)


    Quote

    /saa716x_budget.c:36:10: fatal error: mb86a16.h: No such file or directory



    Gruß

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • Dann ist die Datei nicht im Suchpfad beim Übersetzen.

    In saa716x_budget.c ab Zeile 36 steht doch


    #include "mb86a16.h"

    #include "stv6110x.h"

    #include "stv090x.h"


    Dann kopiere doch die fehlenden Dateien mal in den Ordner wo die saa716x* Dateien stehen oder schreibe bei den #include den gesamten Pfad mit rein oder schreibe das mal so:

    #include <linux/mb86a16.h>


    Gruß

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • habe jetzt die Dateien


    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/media/dvb-frontends/mb86a16.h

    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/media/dvb-frontends/stv6110x.h

    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/media/dvb-frontends/stv090x.h

    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/media/dvb-frontends/zl10353.h

    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/media/dvb-frontends/tda1004x.h

    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/media/tuners/tda827x.h

    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/media/tuners/tda8290.h

    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/media/tuners/tda18271.h

    kernel-4.16.fc28/linux-4.16.3-300.fc28.x86_64/drivers/drivers/media/dvb-frontends/isl6423.h


    nach /usr/local/src/powARman-v4l-dvb-saa716x-3b9fce66666a/linux/drivers/media/common/saa716x kopiert

    und erhalte nun diese Fehlermeldungen:


    Gruß Marco


    HW: TeVii S471 S/S2, TT6400-S2
    SW: Fedora 31, kernel-5.4.2-300.fc31.x86_64, vdr-2.4.1-2.fc31.x86_64

    The post was edited 1 time, last by marco ().

  • Wie hast Du denn das unter Fedora 27 kompiliert. Da wäre es ja dann auch schon nicht gegangen.


    Fedora 28 habe ich noch nicht, aber bei mir ist zusätzlich noch folgender Patch aktiv:


    Gruß

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • Mit Fedora27 war die Vorgehensweise wie hier beschrieben.


    Für Fedora28 habe ich diesen Zweig genommen:

    https://github.com/s-moch/linu…vers/media/common/saa716x


    hier fehlt aber in der Header-Datei saa716x_ff.h die Typendefinition für osd_raw_cmd_s

    daher habe ich die saa716x_ff.h aus dem Verzeichnis mit dem ich Fedora27 kompiliert habe, kopiert.

    Nun lässt sich der Treiber auch wieder kompilieren.



    Gibt es hierzu ein klare Vorgehensweise, oder muss da immer was angepasst werden ?

    Gruß Marco


    HW: TeVii S471 S/S2, TT6400-S2
    SW: Fedora 31, kernel-5.4.2-300.fc31.x86_64, vdr-2.4.1-2.fc31.x86_64

    The post was edited 2 times, last by marco ().

  • Hab ich das jetzt richtig gelesen:

    Ihr nehmt den powarman-hg-Treiber, dann irgendwas aus meinem Repo, mixt das in einen irgendwie komischen Vendor-Kernel und wundert euch, wenn nichts zusammen passt?


    Bei linux-4.16 wurden die dvb-include-files verschoben, wie man leicht aus dem letzten Commit entnehmen kann. Da muss natuerlich auch der Patch fuer die osd.h auf die verschobene Datei angewendet werden. Deshalb gibt es ja die diversen Branches in meinem Repository, nicht nur immer mal einen Patch zusaetzlich.


    Also: entweder nimmt man den entsprechenden Branch aus meinem Repo direkt, oder erzeugt damit ein diff zu dem entsprechenden vanilla-Kernel und wendet diesen Gesamt-Patch dann auf seinen bevorzugten Vendor-Kernel an. Alles andere ist in meinen Augen Unfug. Natuerlich darf jeder auch Dateien von Hand hin und her kopieren, Zeit verplempern und sich dann wundern, warum nichts kompiliert...


    Gruss,

    S:oren

  • Hallo S:oren,


    so schlimm, wie es hier scheint, ist es nicht. Natürlich nehme ich die Dinge aus Deinem Repo. Allerdings übersetzte ich den Kernel immer out-of-tree, ich will ja nicht bei jedem Kernelupdate den ganzen Kernel neu übersetzen.

    Das eigentliche Problem unter Fedora ist, das nicht alle Header-Files, die zum Übersetzen notwendig sind, in den Kernel-devel-Packages vorhanden sind. Man muss die sich also bei jedem Kernel-Update Fedora-spezifisch neu besorgen. Leider wendet Fedora gegenüber dem vanilla-Kernel doch recht viele zusätzliche Patche an, und man muss dann schauen, das das immer alles passt.

    In welchem Verzeichnis die fehlenden Headerfiles dann landen, ist dann ja erst einmal egal, wenn sie beim Übersetzen gefunden werden.

    Das mit dem Patch oben ist auch so ein Ding. Hier müsste ich jedes mal die osd.h im Kernel-tree patchen, also habe ich es da untergebracht, wo es längerfristig Bestand hat.


    Also Alles Gut und der Aufwand ist für mich auch überschaubar.


    Gruß

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • Naja, viele Wege fuehren nach Rom, und "There's more than one way to do it" (nicht nur in Perl) ;-) .


    Warum nicht einfach die kompletten Fedora-Kernel-Sourcen holen, den o.g. Komplettpatch darauf anwenden, Fedora-Config hinlegen, dann ein 'make localyesconfig', 'make menuconfig' -> diesen Treiber als Modul aktivieren, 'make -j4 modules; make modules_install'? Vorbereitungsaufwand 2 Minuten, Compileaufwand ein paar Sekunden, immer alles aktuell und passend. Oder was klappt da bei Fedora wieder nicht?


    Gruss,

    S:oren

  • Du hast natürlich recht. So geht es sicher auch. Vor vielen Jahren habe ich schon mal fleissig Kernel kompiliert, da hat das noch ewig gedauert. Wo das dann nicht mehr nötig war, habe ich das aus meinem Gehirn gestrichen...:)


    Ich weiss, Du meinst nur die Module übersetzen, alles Andere dauert ja immer noch.

    Wenn dann die 4.16 offiziell bei Fedora verfügbar ist, werde ich das mal testen. Mal sehen, wie sich das macht.


    Gruß

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • Durch das localyesconfig wird ja fast nichts mehr als Modul konfiguriert, es gibt evt. ganz wenige Ausnahmen. Das anschliessende 'make modules' hat dann quasi nichts mehr zu tun und baut fast nur den vorher von Hand als Modul aktivierten Treiber.


    Wenn's wirklich ausserhalb des Kernels gebaut werden soll: jasminj hatte angeboten, den Treiber in ihr media-build aufzunehmen, wenn jemand ganz lieb bittet. Vielleicht steht das Angebot noch.


    Gruss,

    S:oren

  • Ja, media-build ist auch so ein Stichwort. Mit dem alten media-build-experimetal hatte ich auch schon verschiedene Erfahrungen, sehr durchwachsen.


    Den media-build vom jasminj habe ich bisher noch nicht weiter verfolgt. Die Frage ist halt immer, wie zeitnah da die Unterstützung für aktuelle Kernel einfliesst. Ausserdem muss meine 2.TV-Karte, die mittlerweile direkt vom Kernel unterstützt wird, auch weiterhin funktionieren.


    Um nochmal auf Fedora zurück zu kommen. Man könnte sich halt fragen, warum Fedora, ja das ist historisch bedingt und woran man sich gewöhnt hat ...


    Bei Fedora ist es so, das man da immer sehr nahe am aktuellen Kernel ist. Meist bekommt man in der Distribution mit dem Minor-Release 2 einen aktuellen Kernel. D.h. der Kernel 4.16.2 wird sicherlich demnächst ausgeliefert.

    Und dann gibt es meist wöchentlich eines neues Minor-Release.


    Der zeitliche Aufwand sollte also minimal sein um meine Hardware am Leben zu erhalten.

    Im Moment, mit der aktuellen Lösung, sieht es so aus, das mein build-script für die TT6400-Treiber fertig ist, wenn bei einem Kernel-Update das zfs-dkms fertig ist. Also keinerlei Zeitverzug.


    Einen zusätzliche Aufwand habe ich in der Regel nur wenn ein Major-Release Wechsel, wie jetzt von 4.15 auf 4.16, ansteht. Dann muss ich einmalig die Header-Dateien updaten und schauen, was sich ggfls. im Repo getan hat. Also so ca. 4x im Jahr.

    Ich bin sicherlich für jede Verbesserung offen, eine alternative Vorgehensweise muss sich aber daran messen.


    Nachdem ich nochmal über den Ansatz mit den Kernel-sourcen nachgedacht habe, auch hier nochmal ein Beispiel wie es ablaufen würde:

    Bei Fedora bekommt man keine fertigen Kernel-sourcen. Man bekommt ein Sourcepaket, das den vanilla-Kernel und eine Patch-Sammlung plus ein Buildscript für rpmbuild enthält. Man muss sich also als ersten Schritt die aktuellen Fedora-Kernelsourcen erstellen und danach kann dann alles weitere erfolgen und das bei jedem Kernelupdate...


    Am liebsten wäre es mir, ich hätte ein dkms-Paket nur für die TT6400-Treiber. Ich weiss jetzt nicht, ob es schon so was gibt, das auch immer den aktuellen Kernel zeitnah unterstützt. Alles Andere am System sollte dabei unverändert bleiben. Dann würde sich für mich der Aufwand auf 4x pro Jahr Header-Update und Repo-sync beschränken. Die Minor-Release-Updates könnten dann automatisch erfolgen.


    Gruß

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • So, ich habe gerade gesehen, das die Sourcen für den Fedora-Kernel 4.16.3 (ist diesmal der Erste 4.16) im Testing-Repo stehen und habe das mal testweise durchgespielt.

    Naja, es ist etwas mehr Aufwand, wenn ich es aber noch vernünftig in ein Script bekomme, doch überschaubar.


    Den Gesamtpatch habe ich erst einmal aus einem localen git-clone erstellt. Lieber wäre es mir, den Patch aus Deinem git remote zu erstellen. Da fehlt mir aber noch der entscheidende Hinweis. Soweit bin ich schon mal gekommen:


    https://github.com/torvalds/li…f=split&name=saa716x-4.16


    Wie bekomme ich den da nun einen Patch draus?


    Gruß

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3