[Solved] TT S2-6400 aktuelle Vorgehensweise?

  • Hi *,


    nachdem ich mir jetzt einen Wolf gelesen habe, aber immer noch keine definitive Aussage gefunden habe, frage ich mal direkt:


    Was ist denn die aktuell funktionierende Vorgehensweise, wenn man für ein neues System mit Linux 4.x oder 5.x den Treiber für die TT S2-6400 benötigt?

    Wo bekommt man den her und wie baut man ihn am einfachsten?


    Danke euch.

    Ciao.

    Michael.

  • Hallo,


    na ja, da gibt es keine definitive Aussage. Das hängt ganz davon ab welche Distribution Du verwendest.


    Den Treiberpatch bekommst Du hier:

    https://github.com/s-moch/linux-saa716x


    Und dann musst Du diesen Patch mit einem Kernel-Source Deiner Wahl verheiraten.


    Für verschiedene Distris gibt es auch Anleitungen hier im Forum.


    Gruß

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Danke dir!

    Ich hab hier ne openSUSE.

    Auf der 42.3 lief alles, bzw. mit deren 4.4er Kernel läuft auch noch alles.

    Mit der 15.1 und deren 4.12er Kernel bekomme ich die src.rpms nicht mehr übersetzt, was mit dem 4.4er Kernel der 42.3 noch ohne Probleme geklappt hat.

    Ich habe - meine ich - alles hier aus dem Forum schon gelesen, wenn auch vermutlich nicht abschließend verstanden 8-<


    Der Link, den du da genannt hast, verweist auf komplette Kerneltrees - für mich wäre dann der 4.12er davon richtig, gehe ich davon aus.

    Den hatte ich auch schon runter geladen, aber danach fehlt mir der nächste Step.

    Du schreibst, ich müsste "diesen Patch mit einem Kernel-Source Deiner Wahl verheiraten." - aber das heruntergeladene Paket ist doch schon ein kompletter Kerneltree!?!? Irgendwie steh ich da auf dem Schlauch 8-(

  • Zu openSUSE selbst kann ich leider nichts sagen.


    Aus dem genannten Git kannst Du sowohl einen kompletten Kernel, wie auch einen Patch für einen bestimmten Kernel laden.

    Wenn Du z.B. einen Patch für 4.12 brauchst, musst Du das so machen:

    wget -O saa716x-4.12.diff https://github.com/s-moch/linux-saa716x/compare/v4.12...saa716x-4.12.diff


    Wenn Du einen kompletten Kernel lädst und übersetzt, bekommst Du einen kompletten Vanilla-Kernel mir saa726x-Support.

    Wenn Du allerdings den Patch nimmst und den zu Deinen passenden Kernel-Sourcen dazu tust, brauchst Du nur die paar zusätzlichen Module übersetzen und zu den vorhandenen Modulen dazu kopieren, was wesentlich schneller geht.

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Die vorherige Methode, dass man ein Modul außerhalb des Kerneltrees übersetzt, existiert dann nicht mehr?

    Das war ja bei den vorherigen src.rpms das Schöne. Man hat das src.rpm installiert, hat einen rpmbuild gemacht und konnte dann ein fertiges rpm mit dem Modul installieren.

  • Die vorherige Methode, dass man ein Modul außerhalb des Kerneltrees übersetzt, existiert dann nicht mehr?

    Das kann man so nicht sagen. Es gibt eigentlich keinen Grund warum das nicht mehr gehen sollte.

    Du musst halt mal schauen, ob der Inhalt Deines src.rpm zu einem aktuellen Patch passt.

    Kernel 4.4 ist ja auch schon eine Weile her und wenn ich mich richtig erinnere, sind seit dem geringfügige Anpassungen am Treiber gemacht worden.

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • [...]

    Du musst halt mal schauen, ob der Inhalt Deines src.rpm zu einem aktuellen Patch passt.

    [...]


    Das ist dann so ca. der Punkt, wo ich aussteige 8-<

    Ich hab zu wenig Ahnung, um a) beurteilen zu können, ob das zusammenpasst und b) was ich tun müsste, wenn es denn doch passen würde.

    Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen, das in den src.rpms drin war. Die waren nur ca. 250 KB groß.

    Danke aber trotzdem für deine Antworten!


    Ciao.

    Michael.

  • .

    Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen

    Das ist eigentlich kein Problem, da der Patch hauptsächlich neue Dateien hinzufügt, Wenn Du Dein src.rpm auspackst, hast Du ja auch die saa* Dateien.


    Wenn Du z.B. in einem leeren Ordner das

    patch -p1 < saa716x-4.12.diff

    eingibst, macht er dann sowas: Das Beispiel ist für einen Kernel 5.1

    Alle Meldungen bestätigst Du einfach mit Enter.

    Hier siehst Du 1. welche Dateien er zu ändern versucht: +++ b/drivers/media/pci/Makefile und nicht findet. Die muss man sich dann separat nochmal anschauen.

    Und 2. legt er den Treiber komplett an unter drivers/media/pci/saa716x/.

    Und diese Dateien kannst Du doch einfach mit dem Inhalt Deines rpm vergleichen.


    Außerdem sollte es doch auch Fehlermeldungen beim Bauen des rpm geben, die sagen doch manchmal auch schon was aus.

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich versuch mal, ob ich da weiter komme.

    Danke nochmals!

  • Kernel 4.4 ist ja auch schon eine Weile her und wenn ich mich richtig erinnere, sind seit dem geringfügige Anpassungen am Treiber gemacht worden.

    Koennte man so sagen, exakt 95 Patches...

    Ich kann ja schlecht den Patch, der gegen einen ganzen Kerneltree laufen würde, gegen das bisschen Sourcecode werfen, das in den src.rpms drin war.

    Bitte immer nur komplette Kernel-Sourcen verwenden. Die gibt es ganz sicher auch von SuSE.


    Die letzte Anfrage, den Treiber fuer Suse zu bauen, kam von kls, siehe hier.


    Gruss,

    S:oren


  • Danke für deinen Tip.

    Ich hatte allerdings irgendwie immer noch gehofft, man könnte das Ganze außerhalb des Distro-Source-Tree so bauen wie vorher.

    Da wurde das dann als weak-update Modul installiert und wurde genutzt, selbst wenn ein neuer Kernel derselben Hauptversion installiert worden war.

    Man musste also nicht bei jedem kleinen Update wieder zu patchen und übersetzen anfangen.


    Ciao.

    Michael.

  • Es gibt keinen einfachen Weg, den Treiber ohne komplette Kernel-Sourcen zu bauen, da auch die Kernel-Header gepatcht werden muessen.


    Wer sich da ausgefeilte Skripte oder dkms-Pakete oder was-auch-immer bauen will, darf das natuerlich gerne machen, muss aber mit jeder neuen Kernel-Version damit rechnen, dass man da wieder etwas anpassen muss. Da das Herunterladen der Kernel-Sourcen + Patchen + Bauen der Module keine 10 Minuten dauert (wenn man es nicht zum ersten Mal macht), wird man m.E. die Zeit nie wieder einsparen, die man die Entwicklung solcher Spezial-Loesungen steckt. Wer aber Spass daran hat, soll es meinetwegen gerne machen. Ich kann und moechte dafuer jedenfalls keinen Support leisten, ich selbst nutze sowieso keine Distro-Kernel auf meinen VDR- und Treiber-Entwicklungs-Rechnern. Aber auch da soll jeder nehmen, was ihm/ihr gefaellt.


    Nach den Problembeschreibungen, die ich so bisher bekommen habe, haben jedenfalls viele Leute schon deutlich mehr Zeit in die Fehlersuche gesteckt, als das Herunterladen und Patchen der kompletten Kernel-Sourcen gedauert haette. Die meisten Distro-Kernel werden sowieso exakt passende Modul-Versionen fordern, evt. sogar signierte Module. Wie das bei SuSE aussieht, weiss ich allerdings nicht. Die letzte von mir genutzte SuSE-Version war 9.3 ...


    Gruss,

    S:oren

  • Alles klar, macht Sinn.

    Dann werde ich mal den Weg nehmen, den du so schön beschrieben hast.

    Thx again!

  • Ok, also:

    Bis dahin hat alles offenbar geklappt. Beim Patch kamen auch keine Abweisungen.

    "make menuconfig" habe ich mir gespart, weil ja beim "make localyesconfig" die Fragen zur saa716X schon kamen.

    Beim "make -j6 modules" hats ihn dann allerdings mit etlichen Errors zerlegt:


    Das Include-File ist allerdings da:

    find . -name tda827x.h

    ./include/config/media/tuner/tda827x.h

    ./drivers/media/tuners/tda827x.h


    Auch ein kompletter "make rpm" klappt leider nicht:


    Code
    LD      drivers/gpu/built-in.o
    make[2]: *** [Makefile:1052: drivers] Error 2
    error: Bad exit status from /var/tmp/rpm-tmp.LRG5y4 (%build)
    
    
    RPM build errors:
        Bad exit status from /var/tmp/rpm-tmp.LRG5y4 (%build)
    make[1]: *** [scripts/package/Makefile:54: rpm] Error 1
    make: *** [Makefile:1400: rpm] Error 2


    Das hat allerdings vermutlich eher was mit openSUSE als mit deinen Patches zu tun.


    Trotzdem bin ich an der Stelle mit meinem Latein am Ende 8-<


    Ciao.

    Michael.

  • Ah doch - der make rpm Abbruch hat doch auch was mit dem Patch zu tun.

    Da ist er wegen eines Fehlers beim DVB_SAA716X_BUDGET raus geflogen:


    Und siehe da, wenn ich das Modul nicht bauen lasse, klappen sowohl der "make -j6 modules" als auch der "make rpm".

  • Ne, der make rpm fliegt immer noch raus, diesmal beim Linker:


  • Finally - habs gebacken bekommen.

    Und hier meine Vorgehensweise, falls nochmals Jemand in die verlegenheit kommt - Verbesserungsvorschläge sind jederzeit willkommen:



    Das Budget-Modul lässt sich allerdings nach wie vor nicht übersetzen - das brauche ich aber auch nicht.

  • Danke, auch wenn ich's nicht brauche ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!