Installation eines VDR+Plugins nativ auf CoreELEC Boxen

  • Wäre es denkbar den neuen Treiber in den 4.9er Kernel zu patchen ? Der Treiber selber ist winzig. Siehe hier

    Den Patch für den Treiber zu integrieren ist kein Problem, nur schaffe ich es irgendwie nicht, den auch bauen zu lassen.

    Unklar ist mir, an welchen Stellschrauben gedreht werden muss. Die Kernelconfig alleine reicht nicht, das Makefile im rtc Verzeichnis wird wieder überschrieben...


    Kennt sich da jemand mit aus?

  • Zabrimus: Baust Du den Kernel denn eigentlich bereits bisher komplett neu, oder übernimmst Du ihn fertig kompiliert von CoreElec?

    Falls ersteres: was ist bisher bereits anders als beim CE-Original? Ich erinnere mich dunkel an das Multidecode-Thema., was vdr für PIP braucht, aber im CE-Kernel deaktiviert ist. Ich hatte im CE-Forum vorgeschlagen, das anzuschalten, aber es wurde rundweg abgelehnt, weil kodi damit Probleme hätte.

    Ansonsten sollte der rtc-Patch m.E. im CE-Forum zur Integration nachgefragt werden.

    Oder kennst Du einen Weg, ein einzelnes Treibermodul für einen Kernel nachzukompilieren? Wobei mir jetzt auch nicht klar ist, ob RTC_DRV_MESON_VRTC fest in den Kernel kompiliert werden muss oder als Modul reicht.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Hier ist wohl der originale Kernel Patch.

    Okay. An der KConfig musste ich noch basteln. Ich habe den Patch leicht verändert drin und das Modul wird jetzt gebaut und kann auch geladen werden:

    Code
    odroid1:~ # modprobe rtc-meson-vrtc
    odroid1:~ # lsmod | grep vrtc
    rtc_meson_vrtc         16384  0

    Allerdings gibt es keinerlei Ausgaben und ich weiß auch nicht, wie ich testen kann, ob auch alles funktioniert.


    Zabrimus: Baust Du den Kernel denn eigentlich bereits bisher komplett neu, oder übernimmst Du ihn fertig kompiliert von CoreElec?

    Falls ersteres: was ist bisher bereits anders als beim CE-Original? Ich erinnere mich dunkel an das Multidecode-Thema., was vdr für PIP braucht, aber im CE-Kernel deaktiviert ist. Ich hatte im CE-Forum vorgeschlagen, das anzuschalten, aber es wurde rundweg abgelehnt, weil kodi damit Probleme hätte.

    Ansonsten sollte der rtc-Patch m.E. im CE-Forum zur Integration nachgefragt werden.

    Oder kennst Du einen Weg, ein einzelnes Treibermodul für einen Kernel nachzukompilieren? Wobei mir jetzt auch nicht klar ist, ob RTC_DRV_MESON_VRTC fest in den Kernel kompiliert werden muss oder als Modul reicht.

    Der Kernel wird neu gebaut - mit den Sourcen von CoreELEC (https://github.com/CoreELEC/linux-amlogic). Der Patch für den Multidecode bzw. die Begrenzung wurde doch schon länger entfernt. Wann und wo genau in Kodi auftreten sollen, ist mir nicht bekannt bzw. bisher nix aufgefallen.

    Der Original-Patch für den rtc benötigt zusätzlich die Konfiguration ARCH_MESON, das allerdings dann unerwünschte Nebenwirkungen hat: Der Kernel kompiliert nicht mehr, weil andere Treiber fehlschlagen.


    Mir ist nicht klar, mit welchen Fragen ich im CoreELEC Forum richtig aufgehoben bin. Die meisten Probleme tauchen im Zusammenhang mit den Änderungen in Bezug auf VDR auf. Und da werde ich wohl kaum Unterstützung erwarten können.

  • Damit solltest du ein 2. rtc device haben. Versuche mal cat /proc/driver/rtc.

    Könntest du das Modul mal hier anhängen. Dann kann ich selber mal damit testen.

    Ob mit oder ohne geladenem Modul: Die Ausgabe ändert sich nicht

    rtc-meson-vrtc.ko.zip

  • ARCH_MESON

    depends on ARCH_MULTI_V7


    Welche Architektur verwendet CoreElec?

    Hilft das evtl: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1820530


    Sonst würde ich mal Ian Armstrong fragen, den habe ich von ivtbfb (PVR350) als hilfsbereit in Erinnerung.

    ACT-620, Asrock B75 Pro3-M, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

  • Ich verwende die DTB "sm1_s905x3_4g_1gbit.dtb". Der cat des rtc von oben ist aber wohl nicht von einer Tanix. Da ist die Alarmfunktion ja schon drin.

    Code
    Bei mir sieht das so aus:
    x96:/flash # cat /proc/driver/rtc
    rtc_time        : 13:07:37
    rtc_date        : 2022-12-01
    24hr            : yes
    x96:/flash #

    Im device-tree fehlt tatsächlich noch der Eintrag für das vrtc. Kann man das nachpatchen oder muss man das dtb dafür neu compilieren.


    Habs nun gefunden. Habe mir den Eintrag in die dtb eincompiliert und nun erzeugt er ein device rtc1 wenn ich das Modul lade.

  • Ich habe meine aktuelle dtb decompiliert zu einer dts Datei. Dann habe ich da den Eintrag rtc gesucht und duch den neuen Eintrag ersetzt.

    Dann habe ich daraus wieder eine dtb Datei compiliert und als dtb.img ins /flash copiert. Und ich habe ins autostart noch ein insmod rtc-meson-vrts.ko eingebaut.


    Dann habe ich als rtc0 eine device das so aussieht wie dein cat von oben. Und wenn ich den wakealarm setze dann wird er dort auch angezeigt. So weit so gut.

    Aber wenn ich dann das device runterfahre mit systemctl shutdown dann wacht es nicht mehr auf wenn die alarmzeit triggert. :(

    Ich denke das könnte an dem bl301.bin Plob liegen der den Coprozessor steuert und der auch nach einen shutdown noch läuft (z.b. für die Wakeup IR). Der ist ja von Corelelc modifiziert für das Wakup per CEC oder GPIO. Da fehlt nun evtl. das durchreichen des Timer wakup Interrupts. Da ist dann wohl noch etwas basteln nötig, oder die DTB Definition ist noch unvollständig.


    Update:

    Das scheint wohl nur zu funktionieren wenn man das Systen in suspend fährt. Aber im Moment sagt mir systemd das suspend nicht unterstützt wird. Woran kann das denn liegen ?


    Update2:

    Nun funktioniert auch der suspend, aber immer noch kein wakeup :) Also weiter basteln.

  • Ich habe es geschafft, die dtb (zumindest für alle sm1) direkt so bauen zu lassen, daß der neue Treiber direkt nach dem Booten verwendet wird. Dabei tausche ich auch das Original rtc aus.

    Und dann habe ich das brandfrische Script von wmautner aus diesem Thread gestartet und erhalte

    und dann gewartet... lange gewartet... Und wahrscheinlich würde ich immer noch warten, denn die Box wacht nicht auf.


    Auch mit einem suspend hatte ich keinen Erfolg.


    Ich lass den dtb Patch im disabled-Status mal drin. Vielleicht findet sich noch eine Lösung.

  • So nun habe ich eine Version gebaut aber das Modul lädt nicht.


    Gibt es irgendein Kommando um den Kernel incl. Module nochmal bauen zu lassen ohne wieder 4 Stunden warten zu müssen ?

    Ich habe nur ein File im Kerneltree geändert.


    In deinem Patch fehlt ein letztes + sonst sind die Einträge

    Code
    MODULE_DESCRIPTION("Amlogic Virtual Wakeup RTC Timer driver");
    MODULE_LICENSE("GPL");

    nicht da. Und dann lädt das Modul nicht.

  • ibt es irgendein Kommando um den Kernel incl. Module nochmal bauen zu lassen ohne wieder 4 Stunden warten zu müssen ?

    Ich habe nur ein File im Kerneltree geändert.

    Versuch mal scripts/clean linux(im CoreELEC Verzeichnis) und dann neu bauen lassen. Der Kernel wird dann mitsamt den Modulen auch neu gebaut. Der Rest müsste dann eigentlich schnell durchgehen.


    In deinem Patch fehlt ein letztes + sonst sind die Einträge

    Seltsam. Den Patch habe ich direkt aus der Mailingliste übernommen und ich habe das Modul auch laden können.

  • Den Buildprozess für das Image werde ich wohl nie verstehn. Wenn ich das script/clean linux ausführe dann scheint er linux wieder zu aktualisieren aus dem GIT.

    Dann sind meine änderungen wieder weg. Editiere ich das Patch File von Zabrimus um das rtc device hinzuzufügen, dann wird das auch aus dem GIT aktualisiert bevor es ausgeführt wird.

    Und in dem linux verzeichniss kann man auch kein "make modules" aufrufen. :(


    Wie soll ich denn da mal eine eigene Änderung einbauen ???? Für einen Tipp bin ich dankbar.

  • Du clonest dir das VDRSternElec Repo und legst deine Patches in patchespackage_patchesoder direkt bei den VDR packagesab.

    Das submodule LibreELEC/CoreELEC wird bei jedem build.sh zurückgesetzt, Änderungen darin gehen verloren. Die Patches aus den o.g. Verzeichnissen werden dann bei einem build.sh neu angewendet.

    Wenn du im LE/CE Verzeichnis patches anlegst/modifizierst, darfst du nur mehr den build Befehl make imageselbst anwenden.

    Im build Verzeichnis bringen Änderungen gar nichts, die werden generell überschrieben.

  • Den Buildprozess für das Image werde ich wohl nie verstehn.

    Änderungen sind etwas mühsam.


    Beim Build werden die Pakete gelöscht, bei denen das package.mk oder eines der Patches geändert wurden oder allgemein sich etwas im Package-Verzeichnis geändert hat, die Sourcen neu ausgepackt, alle Patches angewandt und dann der Build gestartet. Damit sind alle Änderungen direkt im build Verzeichnis weg.


    Ich habe mal versucht irgendwie die Vorgehensweise der Entwickler von CE/LE herauszufinden. Das Einzige, daß ich gefunden habe, war die Aussage, daß es jeder anders macht und es kein allgemein anerkanntes und einfaches Verfahren gibt. Nach dem Motto: Denk dir was aus und mache es so wie du willst. Nicht sonderlich befriedigend.

    Meine Vorgehensweise sieht so aus:

    - Ich entpacke die Sourcen in einem tmp. Verzeichnis und erstelle mir davon direkt 2 Kopien (a, b)

    - Änderungen mache ich in b, erstelle dazu dann den diff zu a und packe den Patch in das richtige patch Verzeichnis


    Es gibt 2 wesentliche Verzeichnisse: patches und package_patches

    In patches können shell Skripte oder Patches untergebracht werden, die direkt die Packages oder Configs oder was auch immer ändern.

    Die Dateien in package_patcheswerden in die entsprechenden Verzeichnisse kopiert.


    Ganz neue Patches oder Modifikationen lege ich in package_patches ab. Änderungen am Bestand mache ich in patches.


    Danach wird das build Script aufgerufen und normalerweise werden dann die geänderten Pakete neu gebaut, aber auch abhängige Pakete. Zum Bespiel bedingen Änderungen am VDR auch den Neubau der Plugins.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!