[VDR*ELEC] - CoreELEC mit Amlogic und wakeup

  • Hallo

    ich habe festgestellt das die Wakeup funktionalität der Boards ohne Hardware RTC nicht sauber funktioniert. Der RTC kann (so wie ich es getestet habe) nur bis ca. 70 Minuten gesetzt werden.

    Werden grössere Zeiten eingetragen werden dann wacht das Board früher auf weil die Zeit wohl wrapped.

    Bei den Tests ist mir aufgefallen das es egal ist welchen Timer man nutzt. Also meson-vrtc oder aml_vrtc haben den gleichen Fehler. Wir hatten ja den Device Tree gepacht damit der meson-vrtc zum Einsatz kommt. Dieser Patch ist nicht nötig.


    Ich habe herausgefunden das es mit dem aml_pm Treiber viel einfacher geht den wakeup timer zusetzen. Man kann den Timer einfach in /sys/kernel/debug/wakeup_time setzen.

    Also mit "echo wakeup_in_x_sekunden >/sys/kernel/debug/wakeup_time" kann der Timer gesetzt werden. Wobei hier die relative Zeit bis zum Aufwachen in Sekunden zu setzen ist. Also NICHT die absolute Aufwachzeit in Sekunden seit 1970. Dabei ist es egal welchen vrtc Treiber man nutzt. Der aml_pm Treiber wird immer geladen. da muss man nix tun.


    Damit ist das Problem mit den 70 Minuten aber noch nicht gelöst. Dafür muss der SCP Prozess gepatcht werden. Hier hat CoreELEC noch einen Fehler in ihrem bl301.bin blob.

    Ich habe den bl301 blob angepasst und einen Patch dafür bereitgestellt (siehe Anhang). Der müsste dann von Zabrimus noch in den build Prozess eingebaut werden.

    Es werden beim build drei bl301 Repositories geladen. Der Patch muss wohl in jedem laufen.


    Damit das ganze dann auch klappt muss das System in den Suspend gefahren werden. Am einfachsten geht das über das Shutdown Script vom vdr.

    Beispiel:

    Code
    echo $2 >/sys/kernel/debug/wakeup_time
    systemctl suspend

    Wobei man evtl. von $2 (Zeit bis zum nächsten Timer in Sekunden) noch 300 abziehen sollte um etwas vorlauf zu haben.

    $2 ist null wenn kein Timer gesetzt ist. Diese 0 muss auch gesetzt werden damit ein evtl. alter Wert überschrieben wird vor dem suspend.


    Viel Spass

    jojo61

  • Mir ist aufgefallen das ich mich hier etwas kompliziert ausgedrückt habe.

    1.

    Mit dem bl301 Patch wird das Problem behoben das der RTC Timer ohne den Patch nur bis ca. 70 min funktioniert.

    2.

    Wer bisher den wakeup timer über /sys/class/rtc/rtc0/wakealarm gesetzt hat, der muss nichts weiter tun und nur das gepatchte bl301.bin laden. Da funktioniert der wakeup bei suspend und bei shutdown.

    3.

    Wer kein /sys/class/rtc/rtc0/wakealarm hat, weil er den aml_vrtc Treiber geladen hat (mit ungepatchten device tree), der kann den wakeup timer über

    /sys/kernel/debug/wakeup_time setzen. Dann funktioniert der Wakeup aber nur beim suspend.

  • Inwieweit ist auch der Odroid N2(+) betroffen? Ich setze in /sys/class/rtc/rtc0/wakealarm und hatte bisher keine Probleme mit Timern, die mehr als 70 Minuten in der Zukunft liegen. Ein gepatchtes bl301 verwende ich nach meiner Kenntnis nicht.

    VDR1: ACT-620, Asus P8B75-M LX, 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.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Mir ist aufgefallen das ich mich hier etwas kompliziert ausgedrückt habe.

    Äh ja :D


    Reicht es, wenn ich den Patch einspiele, oder muss ich andere Patches wieder entfernen?


    Ich habe in CE 3 Projekte gefunden, die zum Patch passen könnten. Müssen alle 3 oder nur eines davon bearbeitet werden?


    Code
    projects/Amlogic-ce/packages/linux-firmware/amlogic/bl301_091020
    projects/Amlogic-ce/packages/linux-firmware/amlogic/bl301_221119
    projects/Amlogic-ce/packages/linux-firmware/amlogic/bl301_xxxxxx
  • Es reicht wenn du nur den Patch einspielst. Du musst keine anderen Patches entfernen.

    Du musst alle 3 Projekte patchen. Der Patch ist für alle 3 der gleiche.


    Super und Danke für deine arbeit an VDR*ELEC

    jojo61

  • Es reicht wenn du nur den Patch einspielst. Du musst keine anderen Patches entfernen.

    Du musst alle 3 Projekte patchen. Der Patch ist für alle 3 der gleiche.

    Die Patches habe ich für alle 3 Packages hinzugefügt. Der Build von CE19 und CE20 werfen zumindest keine Fehler.

    Jetzt fehlt ein Freiwilliger, der zum Testen bereit ist :)

  • Ich werde es testen und berichten :)

    Nach dem clean auschecken und starten kommt folgendes:

    Code
    jojo@nuc:~/VDRSternELEC$ ./build.sh -config CoreELEC-20
    Read config CoreELEC-20
    Clean up
    fatal: ambiguous argument 'origin/coreelec-20': unknown revision or path not in the working tree.
    Use '--' to separate paths from revisions, like this:
    'git <command> [<revision>...] -- [<file>...]'

    Ich habe dann in cleanup das origin/$BRANCH wieder entfernt. Dann lief es. Jetzt warte ich auf den Build in ein paar Stunden.

  • fatal: ambiguous argument 'origin/coreelec-20': unknown revision or path not in the working tree.

    Seltsam. origin/coreelec-20 ist aber genau der remote Branch.

    Ich musste da einige Streckübungen machen, damit der automatische Build nicht immer auf die Nase fällt. Es wird permanent zwischen den Branches (coreelec-19, coreelec-20, coreelec-21) gewechselt und dazwischen kommen die Remote Pulls noch rein.

    Es gab immer wieder Ärger damit. Im Moment scheint es aber gut zu laufen - zumindest bei mir.


    Hast du das lokale Checkout evt. länger nicht aktualisiert? Oder ist das ein frischer Checkout (wegen den paar Stunden)?


    Edit: Lesen bildet.

    Nach dem clean auschecken und starten kommt folgendes:

    Das habe ich schon sehr lange nicht mehr gemacht. Das werde ich prüfen müssen.

  • So ich habe es nun getestet und noch einen Fehler gefunden. Die Leutchen von Corelec haben etwas chaos in ihren BL301 Quellen und einiges ist da doppelt und dreifach drin. Deswegen muss in dem Repositories bl301_221119 und bl301_091020 noch eine weitere Datei gepatcht werden.

    Ich habe dir die Patchdatei angehängt. Die muss nach

    package_patches/CoreELEC/projects/Amlogic-ce/packages/linux-firmware/amlogic/bl301_221119/patches

    und nach

    package_patches/CoreELEC/projects/Amlogic-ce/packages/linux-firmware/amlogic/bl301_091020/patches


    Evtl musst du die Patchdatei nach umbenennen nach bl301.patch

  • Hallo,

    vielen Dank für den Patch!

    Ich hatte den Wakeup bereits vor ein paar Monaten ausprobiert und nachdem die Box immer nach ca. 1 Stunde statt zum Timer aufgewacht ist, war ich in der Annahme, dass meine Box das einfach nicht kann oder irgendeine Macke hat. Hatte das ganze dann umständlich über einen ESP8266 und WOL gelöst.

    Sobald das nächste Release von VDR*ELEC erstellt wird, werde ich den Wakeup auch testen und gebe dann Rückmeldung.

  • Es könnte sein das ich da nochmal nacharbeiten muss weil der Timer beim booten evtl. nicht gelöscht wird. D.h. beim erneuten shutdown wird er wieder auf den alten Wert gesetzt. Das bin ich gerade am testen.


    Nachtrag:

    Der Test war erfolgreich und es sind keine Nacharbeiten nötig. Der Timer wird beim boot immer gelöscht und alles funktioniert wie es soll.

  • Nach den ersten Tests scheint alles wie gewünscht zu laufen. Endlich geht auch der Wakeup.
    "/sys/kernel/debug/wakeup_time" ist bei mir nicht vorhanden - keine Ahnung warum. Ich nutze stattdessen "/sys/class/rtc/rtc0/wakealarm".

  • Inwieweit ist auch der Odroid N2(+) betroffen? Ich setze in /sys/class/rtc/rtc0/wakealarm und hatte bisher keine Probleme mit Timern, die mehr als 70 Minuten in der Zukunft liegen. Ein gepatchtes bl301 verwende ich nach meiner Kenntnis nicht.

    Bei mir läuft auch Odroid N2+ Hardware. Wo bzw. wie setzt VDR*ELEC denn standardmäßig vdr Timer?

    Muss ich nach VDR*ELEC Installation extra was einstellen?


    CR2032 Batterie ist eingesetzt, Timer ist gesetzt (z.B. für nächsten Tag), im vdr osd steht nach Inaktivität x herunterfahren, wakeup passiert aber nicht...

  • Für ein System mit vdr in chroot-Umgebung könnte ich es Dir sagen, aber bei VDR*ELEC blicke ich auch nicht so recht durch.

    Zunächst mal fehlt in /storage/.config/vdropt/conf.d/vdr.conf ein shutdown-Parameter.

    Normalerweise würde ich da jetzt das Script eintragen, das den nächsten Timer ins RTC schreibt und den Rechner dann runterfährt. Also z.B. --shutdown=/storage/vdrshutdown.sh.

    Diese Datei könnte z.B. so aussehen:

    Bash
    #!/bin/bash
    sudo hwclock --systohc --utc
    NextTimer=$(($1 - 600 ))  # 10 minutes earlier
       bash -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"
    if test $NextTimer -gt "0"; then
       bash -c "echo $NextTimer > /sys/class/rtc/rtc0/wakealarm"
    fi
    /sbin/poweroff

    und muss natürlich mit chmod +x /storage/vdrshutdown.sh ausführbar gemacht werden. Der passende Ort wäre wohl anstelle von /storage eher /usr/local/bin - aber dazu müsstest Du zunächst

    mount -o remount,rw /flash

    dann Deine Änderung vornehmen und dann

    mount -o remount,ro /flash

    machen.

    Wie gesagt, normalerweise. Da es aber in /usr/local/bin bereits einen shutdown-wrapper gibt (den kenne ich eigentlich nur von Systemen, wo vdr nicht als root läuft) mag es hier ein anderes Konzept geben, zu dem Zabrimus etwas sagen müsste.

    VDR1: ACT-620, Asus P8B75-M LX, 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.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Genauer kenne ich mich mit dem Aufwecken nicht aus, da ich das bisher nicht verwendet habe. Die Änderungen in VDR*ELEC sind nur aufgrund von Wünschen entstanden.

    jojo61 hat hier wohl man ein Script gepostet. Es gibt aber keinen (oder sollte) wirklichen Unterschied zu anderen Lösungen geben. VDR Parameter, Shutdown Script und dergleichen sollte irgendwie fast überall gleich sein - so zumindest mein Verständnis.


    Der shutdown-wrapper in /usr/local/bin kommt aus dem Plugin dbus2vdr. Um herauszufinden, welchen Zweck das Programm erfüllt, müsste man im Repository/Manual/README des dbus2vdr nachschauen.


    Ich kann nur dringend davon abraten, etwas selbst in /usr/local/ abzulegen. Diese Änderungen werden bei dem nächsten Update überschrieben und müssten dann wieder neu erstellt werden. Sofern man daran denkt oder kein Update durchführen will, spricht nichts dagegen.


    Scripte/Daten/Konfigurationen, die ein Update überstehen sollen, sollten in /storage abgelegt werden. CE/LE machen genau das: Das eigentliche System im read-only Flash und Konfigurationen/Addons und was auch immer, landen in /storage.


    Für VDR Scripte würde ich daher eher /storage/.config/vdropt empfehlen. Zumal dann alles VDR-spezifische in einem eigenen Order abgelegt wird.

  • Ok, danke euch beiden.


    Habe es mit gezeigtem Script umgesetzt, Ablageort: /storage/.config/vdropt/vdrshutdown.sh, ausführbar gemacht und in /storage/.config/vdropt/conf.d/vdr.conf eingetragen.


    Mal sehen ob wakeup nun funktioniert... *edit: es funktioniert :)

    Einmal editiert, zuletzt von vdr_rossi ()

Jetzt mitmachen!

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