Beiträge von Zabrimus

Zitat von Dr. Seltsam

Wenn ich das installscript richtig interpretiere

Die Samples werden nur kopiert, wenn das Verzeichnis nicht besteht. Das ist richtig, weil ansonsten könnten eigene Konfigurationen überschrieben werden und das wollte ich vermeiden.

Das install Skript kennt aber auch den Parameter "-C" um genau das zu erreichen:

Bestehende Konfigurationen beibehalten und neue hinzufügen. Falls die Dateien schon existieren, werden sie auch aber dann nicht überschrieben. Das würde dir also auch nicht nützen, außer du löscht vorher alle 0-Byte Dateien.

Zitat von Dr. Seltsam

Zabrimus: Warum eigentlich so kompliziert? Wenn man die zu aktivierenden Plugins ohnehin in einer Datei (enabled_plugins) eintragen muss, könnte man doch auch gleich die Pluginparameter dort ergänzen, so wie es die plugins.conf in den vdr-Sourcen vorsieht.

Kompliziert? Bisher hielt ich das immer für sehr einfach. An den genauen Grund kann ich mich gar nicht mehr erinnern. Aber es werden alle Plugins und alle Config installiert und ich habe mich dagegen gesträubt, irgendwelche Tricks anwenden zu müssen um die zu startenden Plugins auswählen zu können. Zum Beispiel Links der Config Dateien zu erstellen/löschen oder andere Lösungen. Mir ging es darum, möglichst schnell und einfach Plugins aus- und abwählen zu können. Gerade in der Anfangsphase habe ich die wildesten Kombinationen an Plugins probiereren müssen, z.B. ob die überhaupt starten.

Auf einem System wie die Tanix TX3 kann ich - nach meinen Tests - nicht unbedingt empfehlen das Vollprogramm (alle vorhandenen Plugins) zu starten.

Im Prinzip hat man jetzt die bekannten *.conf Dateien mit dem Unterschied, daß das Startkommando anders erstellt wird.

Zitat von Dr. Seltsam

alle conf und ini-Dateien in /storage/.config/vdropt/conf.d/ sind leer!

In der Parameterliste taucht softhdodroid auch nicht auf. In der config muss auf jeden Fall für jedes zu startende Plugin zumindest der Eintrag "[pluginname]" vorhanden sein, weil daraus die Kommandozeile generiert wird. Zusätzlich zu den Parametern für das Plugin.

Und gerade softhdodroid braucht noch einen Parameter.

[softhdodroid]
-a hw:CARD=AMLAUGESOUND,DEV=0

Also entweder aus .config/vdropt-sample/conf.d kopieren oder manuell erstellen.

Ich verstehe nur nicht, wie die Dateien alle leer sein können. Das ist schon ein wenig merkwürdig.

edit:

Also zusammengefasst:

In enabled_plugins befinden sich Namen. Mit dem Namen wird in conf.d/<name>.conf die Konfiguration gelesen. Aus der Konfiguration wird dann das zu startende Plugin mit Parametern extrahiert.

Es ist also auch möglich, z.B. in enabled_plugins sowas wie "mein_neues_plugin" zu schreiben, und in conf.d/mein_neues_plugin.conf ein völlig anders Plugin zu konfigurieren.

Es ist zwar möglich, aber wahrscheinlich verwirrend.

Kannst du mal das angehängte Script nach /storage/ packen und manuell aufrufen? Allerdings solltest du vorher VDR wirklich stoppen systemctl stop vdropt.

Das Script ist eine Kopie von /usr/local/bin/start_vdr.sh, gibt aber die gesamte Kommandozeile aus. Gibt es denn die Config /storage/.config/vdropt/conf.d/softhdodroid.conf?

start_vdr.sh.txt

Zitat von vdr_rossi

Mein Ziel ist das shutdown bzw. wakeup für vdr Timer funktioniert.

Die Injection wird - wenn ich das richtig verstanden habe - nur benötigt, wenn der Bootloader der Originalbox verbesserungswürdig ist. Zum Beispiel bei der Tanix TX3. Auf der N2+ sollte es eigentlich so funktionieren. Zumindest der Shutdown klappt gut. Und die RTC hat auch Alarmmöglichkeiten.

Zitat von JoeBar

Hast Du auch den odroid? Falls ja, wie fällt die Performance zum tanix tx3 aus? Lohnt es sich den odroid anzuschaffen?

Ich habe sowohl die Tanix TX3, als auch die N2+ im Einsatz. Und rein gefühlmäßig (auch vom Hausvorstand) ist die N2+ um viele Längen schneller und geschmeidiger. Auch bezüglich des IR Empfängers ist die N2+ besser. Bei der Tanix muss ich immer genau zielen.

Zitat von JoeBar

Gibt es die Möglichkeit die CPU Temperatur auch im VDR anzuzeigen? Evtl. cat /sys/class/thermal/thermal_zone0/temp das scheint ja die CPU Temperatur in Grad Celsius * 1000 zu sein, oder? Bzw. watch cputemp

Das hängt wohl vom Skin ab. Ich meine, ich hätte zumindest im Skindesigner gesehen, daß Ausgaben von Skripten eingebunden werden können sollten möglich sein - oder so ähnlich.

Zu der Thermik der Box:

Ich habe mir nur einen Kühlkörper draufgeklebt, habe aber bei der Suche nach Möglichkeiten so alles an Variantionen gesehen und die eben aufgelistet. Ich denke auch, Luft von unten einblasen wäre die beste Lösung. Ich bin aktuell nur geschädigt von kleinen Lüftern (neuen Blikvm im Keller mit Mini-Lüfter) und das Ding ist brutal laut und nervig. Ich habe beide (Keller und Büro) jetzt auch umgebaut und die Lüfter abgeklemmt.

Zitat von JoeBar

Evtl. liegt es auch an der CPU Temperatur, dass diese dann drosselt aktuell Zeigt Kodi (60% CPU Last) mit hyperion (23% CPU Last) und vdr (19% CPU Last) im Hintergrund ca. 73°C an.

Das ist ein thermisches Problem. Ich habe bei mir einen neuen Kühlkörper eingebaut und dabei die alte Alu-Platte und die Leitpaste entfernt. Das war vom Platz schon grenzwertig.

Es scheint auch andere Lösungen zu geben, wie z.B. einen großen Alukörper durch den Boden zu führen und mit einem Ventilator zu kühlen. Aber das widersprach meiner Vorstellung einer kleinen und leisen Box. Wieder andere Bohren Löcher in den Boden um mehr Luft in die Kiste zu bekommen.

Zitat von vdr_rossi

BL301 injection wird bei mir nicht unterstützt:

Ich habe der odroid n2+ die Injection gar nicht gebraucht. Was genau fehlt dir denn?

Zitat von apache

#> sudo make install in the skinnoopacity directory
it creates the module /usr/local/lib/vdr/libvdr-skinnoopacity.so.2.5.6
instead of libvdr-skinnoopacity.so.2.6.0 with API 2.6.0 ,

I'm forced to change the name manually as requested by VDR in Startup to Bash Console

The solution is a bad idea. The root cause for the wrong version shall be fixed.

Ususally this happens because of old VDR header files installed somewhere.

pkg-config --variable=apiversion vdr

should return the desired VDR version (in your case i assume 2.6.0 or possibly a later one).

Zitat von JoeBar

Zabrimus Kann man sich da irgendwo einlesen, wie man die Packages für die Plugins konfigurieren muss? So auf den ersten Blick sieht das alles recht umfangreich aus

Es gibt eine package.mk.template in den CE/LE package Verzeichnissen. In den beiden Foren dürfte es auch Informationen geben. Aber vieles habe ich mir durch ausprobieren und lesen der Bestandpackages und Scripte herausarbeiten können.

Ein neues Plugin ist einfacher, als es den Anschein hat. Wenn jemand ein neues Plugin wünscht ist mein aktuelles Vorgehen so:

1. Kopieren eines Bestandpaketes (z.B. packages/vdr/_vdr-plugin-ac3mode nach packages/vdr/_vdr-plugin-superduper)
2. Hinzufügen des neuen Paketes in packages/virtual/vdr-all/package.mk
   PKG_DEPENDS_TARGET+=" _vdr-plugin-superduper"
3. Anpassen der Files (Name und Inhalt) in _vdr-plugin-superduper/conf.d/
4. Anpassen des Headers in der package.mk des neuen Plugins:
   PKG_NAME="_vdr-plugin-superduper"
   PKG_VERSION="<Version anpassen>"
   PKG_SHA256="<sha256sum des Archivs mit den Sourcen"
   PKG_LICENSE="<Lizenz>"
   PKG_SITE="<Homepage des Plugins>"
   PKG_URL="<Download URL der Plugin Sourcen>"
   PKG_SOURCE_DIR="vdr-plugin-superduper-${PKG_VERSION}"
   PKG_DEPENDS_TARGET="toolchain _vdr"
   PKG_NEED_UNPACK="$(get_pkg_directory _vdr)"
   PKG_LONGDESC="<Langbeschreibung>"
   PKG_TOOLCHAIN="manual"
5. In package.mk in der Prozedur post_makeinstall_target()muss noch ac3mode-sample-config.zipdurch superduper-sample-config.zip ersetzt werden.

Jetzt könnte man schon einmal den ersten Build-Test starten um zu prüfen, ob das Source-Archiv heruntergeladen werden kann und die Checksumme passt.

Der Build wird mit hoher Wahrscheinlichkeit abbrechen, weil der Makefile Patch patches/Makefile.patch nicht passt.

Im Makefile sind in den allermeisten Fällen (es gibt auch Ausnahmen) nur 2 Änderungen notwendig, da die Makefiles der Plugins sich zumeist sehr ähnlich sind:

-LIBDIR = ../../lib
+LIBDIR ?= ../../lib

und 

install-lib: $(SOFILE)
-    install -D $^ $(DESTDIR)$(LIBDIR)/$^.$(APIVERSION)
+    install -D $^ $(LIBDIR)/$^.$(APIVERSION)

Diff erstellen zwischen altem und neuen Makefile und in das Verzeichnis packen.

Mal wieder so ein Build-Test starten...

Nachdem alles gebaut wurde, kann man sich z.B. die Sourcen anschauen in

CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/build/_vdr-plugin-superduper-<Version>

und die installierte Version findet sich dann in

CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/install_pkg/_vdr-plugin-superduper-<Version>

Das Installationsverzeichnis sollte man prüfen, ob die Verzeichnisstruktur passt und auch alles so vorhanden ist, was man für das Plugin so erwarten würde.

Das ist so die einfachste Version für ein neues Plugin. Fast alle der zuletzt hinzugefügten Plugins wurden genauso integriert.

Es gibt Fälle, in denen es andere Abhängigkeiten gibt und vielleicht sogar neue Libs benötigt werden. Das Vorgehen ist aber ähnlich, wenn auch manchmal zermürbend.

Es gibt verschiedene Prozeduren in den package.mk, mit denen der Build beeinflusst werden kann. Dazu schaut man sich aber am Besten packages aus CE/LE an. Die Prozeduren genügen alle einer bestimmten Namenskonvention.

Falls noch Fragen vorhanden sind, immer her damit.

Zitat von JoeBar

Den vnsi-server hab ich gefunden, ich hab mich halt gewundert, dass unter .config/vdropt/plugins kein Verzeichnis war.

Oje. Da ist mir ein Plugin-Verzeichnis durchgegangen.

Da fehlt wohl noch das Verzeichnis .config/vdropt/plugins/vnsiserverund darin die Datei allowed_hosts.confmit zumindest dem Default-Inhalt

#
# allowed_hosts.conf  This file describes a number of host addresses that
#                     are allowed to connect to the streamdev server running 
#                     with the Video Disk Recorder (VDR) on this system.
# Syntax:
#
# IP-Address[/Netmask]
#

127.0.0.1             # always accept localhost
192.168.0.0/24        # any host on the local net
#204.152.189.113      # a specific host
#0.0.0.0/0            # any host on any net (USE THIS WITH CARE!)

Es könnte natürlich sein, daß der vnsi server so gar keine Verbindungen erlaubt, wenn die Datei fehlt.

Zitat von JoeBar

Jetzt muss ich nur noch Ausprobieren wie man das ganze selber compiliert bekommt um noch ein paar vdr-plugins auszuprobieren. Bzw. wo finde ich den den vnsi server? Im Github ist er ja schon aufgeführt aber im aktuellen Release noch nicht enhalten oder?

Das vdr-plugin-vnsiserver wird gebaut und installiert. Wie kommst du denn darauf, daß er nicht da sei?

Das Kompilieren geht recht einfach (braucht nur viel Hauptspeicher, Plattenplatz und Zeit (zumindest für den ersten Build)):

git clone https://github.com/Zabrimus/VDRSternELEC.git
cd VDRSternELEC
./build.sh -config CoreELEC-19

Die Packages für Plugins befinden sich im Verzeichnis packages/vdr. Falls neue Plugins hinzugefügt werden sollen, dann muss dieses auch in packages/virtual/vdr-all/package.mkhinzugefügt werden.

Die packages in packages/vdrsind alle sehr ähnlich und unterscheiden sich häufig nur in Nuancen.

Zitat von JoeBar

Funktioniert das VFD mit dem coreelec service openvfd oder sollte man den service weglassen und den von Zabrimus verwenden bzw. wie bekomme ich das Tanix tx3 VFD unter Kodi zum laufen?

Der openvfd ist schon richtig. Ich habe den nur etwas gepatched um einfach auch beliebige "Texte" anzeigen lassen zu können. Bei 4 möglichen Zeichen vielleicht nicht immer sinnvoll.

Es muss die Datei /storage/.config/vfd.conf angelegt werden. Du kannst ja meine Config für die Tanix TX3 probieren.

vfd.conf.txt

Ansonsten nur noch in CoreELEC den OpenVFD Service installieren und rebooten.

Siehe CoreELEC Howto

Zitat von JoeBar

Gibt es eine "universal" Fernbedienung auf der die Powertaste frei programmiert werden kann, so dass man die tx3 bzw. die X96 Max+ einschalten kann?

Ja gibt es. Allerdings ist das alles andere als simpel und einfach. Ich habe hier zum Beispiel 2 URC 7140 im Einsatz. Die können sehr umfangreich programmiert werden. Allerdings nur mit entsprechender Hardware und Einarbeitung.

Siehe das JP1 Wiki und das JP1 Forum. Und ich rate jedem davon ab, der nicht willens ist, den Aufwand (Hardware und Zeit zur Einarbeitung) zu betreiben.

Zitat von Dr. Seltsam

Über eine zusammenfassende und anfängertaugliche Zusammenfassung, was genau zu tun ist, würde ich mich freuen.

Ich versuche mich mal zu erinnern

Schritt 1:

Es muss eine Unterscheidung getroffen werden: Update oder Neuinstallation.

Neuinstallation wie üblich. SD Karte, dtb aussuchen und nach dtb.img kopieren.

Für das Update einer Bestandsinstallation gilt nahezu dasselbe. Die neue dtb muss kopiert werden, denn die wird bei einem Update nicht automatisch aktualisiert.

Ich verwende die dtb sm1_s905x3_4g_1gbit.dtb. Es scheint auch Leute zu geben, bei denen die Box nur startet, wenn man die dtb ohne "1gbit" oder "100mbit" nutzt. Da hilft nur probieren.

Schritt 2:

Für die Tanix TX3 musste ich den Bootloader aktualisieren: Stichwort bl301. Nachlesen kann man es z.B. auf im CoreELEC Wiki. Und da gibt es auch eine Warnung, die ich heute ignoriert habe, da ich meine Box nicht von Aliexpress habe:

Falls das System nach dem bl301 Update nicht mehr bootet beginnt das Lesen des Forums und das Kurzschliessen von 2 Pins auf dem Board und Nutzung einer speziellen SD Karte um wieder an die Box zu kommen.

Ich habe das inject per Kommdozeile gemacht, weil ich die Ausgaben sehen wollte und die weitere Konfiguration dann in Kodi.

inject_bl301

Nach dem erfolgreichem Booten kann man inject_bl301 nochmal aufrufen und prüfen, ob der neue Bootloader auch geschrieben wurde. Meine Ausgabe kann man oben finden.

Schritt 3:

Nutzung... In einem shutdown Script oder wie auch immer. Das bleibt dann jedem selbst überlassen. Meine Box wacht erfolgreich auf mit

echo 0 > /sys/class/rtc/rtc0/wakealarm 
echo +300 > /sys/class/rtc/rtc0//wakealarm
shutdown -h -P now

Falls Datumsberechnungen (mit z.B. date) erfolgen sollen, dann sollte man beachten, daß das busybox date verwendet wird und das verhält sich etwas anders, als das normale bekannte Kommando und da muss man ein wenig forschen. Deshalb kam ich auf das "echo +300" um meine Tests einfacher durchführen zu können.

Zitat von Dr. Seltsam

Habt Ihr mal den Unterschied des Stromverbrauchs zwischen „Kiste läuft“ und „Kiste ist mit gesetzter Aufwachzeit runtergefahren“ gemessen?

Im Rahmen der Messungenauigkeit und des verwendeten Netzteils komme ich für die Tanix TX3 auf diese Werte (ohne Platte, SSD, oder andere Geräte):

Verbrauch VDR/Kodi: 2,7 Watt

Aus: 1,3 Watt

Aufwachzeit gesetzt: 1,3 Watt

Zitat von SurfaceCleanerZ

Hast du mal nach 1h probiert? Nicht dass es sn Sommerzeit oder so liegt?

Genau deshalb habe ich mir ja die Daten (cat /proc/driver/rtc) ausgeben lassen. Die Systemzeit und die Alarmzeit unterschieden sich genau um die gewünschte Zeit.

Zitat von jojo61

Hast du den bl301 Blob geladen ? Das musst du unter Kodi aktivieren.

Genau das war es! Ich habe das zwar nur auf der Shell gemacht und das Ergebnis sieht jetzt so aus:

tanix1:~ # inject_bl301 
Starting bootloader blob BL301 injection tool...

This tool can be used to update the bootloader
blob BL301 of the vendor bootloader on the internal
eMMC. This bootloader blob BL301 is customized by
Team CoreELEC to support all wake-up features like
CEC, Wake-On-LAN, IR, and GPIO wake-up from
suspend or power off state!

Device serial number: 2b0b010001071a00000c3233334e3050
Using CPU type SM1 (2b): S905X3, S905D3
Using binary type because of CoreELEC DT-ID: Generic
Using /dev/bootloader as bootloader partition

Did not find Amlogic image v2 header magic!
Found a valid Amlogic v3 ToC header (0x10210)
Amlogic magic:                  AA640001
Serial Number:                  12345678
Flags:                          0
Old signature bl2:              2D935C42E6B9B0FB700A2C3010F78D41D6B18B9B601B29521E7F1B14EDC68BF2
BL2 time stamp:                 Built : 14:57:11, Sep  1 2020. g12a g3c95fed - gongwei.chen@droid11-sz

TOC ENTRY #3
UUID:                           D6D0EEA7FCEAD54B97829934F234B6E4
Offset Address:                 0xA7170 (absolute: 0xB7380)
Size:                           0xB9000
Flags:                          0x0
Found BL33 blob image at:       0x000B7380
Amlogic magic:                  @AML
BL33 time stamp:                U-Boot 2015.01-g3f93e96a99-dirty (Oct 12 2020 - 14:46:584▒ #a

TOC ENTRY #0
UUID:                           9766FD3D89BEE849AE5D78A140608213
Offset Address:                 0x68000 (absolute: 0x78210)
Size:                           0xFD70
Flags:                          0x0
Found BL30 blob image at:       0x00078210
Amlogic magic:                  @AML
Old signature bl30:             451C18B54C4394E62D8DC3D6CB6B7437CD7D92562ED576F5B037F8F6E0DCAD36
Using bl301 blobs from:         221119
Using bl301 blob:               Generic_28_2b_bl301.bin
Use config.ini value:           wol = 0x01
Use config.ini value:           cec_osd_name = CoreELEC
New signature bl30:             451C18B54C4394E62D8DC3D6CB6B7437CD7D92562ED576F5B037F8F6E0DCAD36
Update of BL301.bin on eMMC is not needed

Alarmzeit setzen, shutdown, warten ... Und mir ist fast der Löffel aus der Hand gefallen, als die Box wieder startete

Danke. WOL habe ich noch nicht getestet, aber das Aufwecken funktioniert einwandfrei.

Zitat von Uwe

Nur so eine Idee: Eventuell hilft es den Timer ein paar Minuten in der Zukunft zu setzen, als nur ein paar Sekunden?

Ich habe den Timer jetzt mit 10 Minuten getestet und 25 Minuten gewartet. Ohne Erfolg.

Zitat von Dr. Seltsam

Kann das an Hardwareunterschieden zwischen der X96MAX und der Tanix TX3 (Alice?) liegen? Wäre schade, die TX3 ist günstiger zu haben.

Da muss es wohl Unterschiede geben. Es scheint sogar Unterschiede zwischen verschiedenen TX3 zu geben. 1 GBit vs. 100Mbit Netzwerk. Angeblich soll auch WOL funktionieren, aber das habe ich auch nicht hin bekommen.

Gut. Mich stört das nicht, weil ich das wakeup bisher nie eingesetzt habe und jetzt mit der TX3 zum ersten mal teste. Das WOL ist schon ärgerlich, aber auch kein Beinbruch. Die Box dient eben nur zum TV/Kodi schauen und nix anderes.

Zitat von jojo61

Und die Zeiten sind in UTC. Und du musst sinnvolle Aufwachzeiten setzen. Also Zeiten in der Zukunft. Nicht wie in deinem Test oben.

Derzeit also grösser als 1670307715

Okay. Ein typischer ERROR-40. Wenn mans richtig macht, dann wird auch der IRQ gesetzt und die Box (tx3) wacht trotzdem nicht auf

tanix1:~ #  cat /sys/power/state 
freeze mem

Keine der Varianten führte zum Erfolg:

Gemeinsam ist:
echo 0 > /sys/class/rtc/rtc0/wakealarm 
echo +20 > /sys/class/rtc/rtc0//wakealarm 
cat /proc/driver/rtc 

rtc_time        : 14:09:02
rtc_date        : 2022-12-06
alrm_time       : 14:09:22
alrm_date       : 2022-12-06
alarm_IRQ       : yes
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1
max user IRQ frequency  : 64
24hr            : yes

Und dann entweder 
echo freeze > /sys/power/state
echo mem > /sys/power/state
shutdown -h -P now
systemctl suspend

Zitat von Dr. Seltsam

Ich habe jetzt nur vdr + softhdodroid-Plugin laufen - immer noch fast unverändert. last 1,8 und vdr hat 102%. Es ist ebenfalls ein N2+.

Soll ich mal ein anders image testen? Welches läuft bei Dir? Möchte aber nicht selbst bauen sondern ein fertiges img runterladen

Fertige Images findest Du hier. Die letzte Neuinstallation ist 2-3 Wochen her und seitdem mache ich nur Updates.

Und alles war bisher unauffällig.

Angefangen habe ich z.B. mit

VDR-CoreELEC-Amlogic-ng.arm-19.5-Matrix-2022-12-03.1-Odroid_N2.img.gz bzw. für das Update einer bestehenden Installation

VDR-CoreELEC-Amlogic-ng.arm-19.5-Matrix-2022-12-03.1.tar

Oder nutzt du den CoreELEC 20er Branch?

Zitat von jojo61

Poste mal was cat /sys/class/rtc/rtc0/name sagt. Und ob es ein cat /sys/class/rtc/rtc1/name gibt.

Und was gibt ein dmesg | grep rtc

Das sieht alles relativ unauffällig aus:

tanix1:~ # cat /sys/class/rtc/rtc0/name
meson-vrtc

tanix1:~ # cat /sys/class/rtc/rtc1/name
cat: can't open '/sys/class/rtc/rtc1/name': No such file or directory

tanix1:~ # dmesg | grep rtc
[    1.420836@1]- hctosys: unable to open rtc device (rtc0)
[   12.627626@3]- meson-vrtc ff8000a8.rtc: rtc core: registered meson-vrtc as rtc0

tanix1:~ # cat /proc/driver/rtc 
rtc_time        : 16:44:23
rtc_date        : 2022-12-05
alrm_time       : 00:00:00
alrm_date       : 1970-01-01
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1
max user IRQ frequency  : 64
24hr            : yes

tanix1:~ # ls /proc/driver/rtc*
/proc/driver/rtc

tanix1:~ # ls -la /dev/rtc*
lrwxrwxrwx    1 root     root             4 Aug  6  2021 /dev/rtc -> rtc0
crw-------    1 root     root      251,   0 Aug  6  2021 /dev/rtc0

Hast du auch diese Meldung?

tanix1:~ # dmesg | grep rtc
[    1.420836@1]- hctosys: unable to open rtc device (rtc0)

Ich überlege gerade, ob es ein sinnvoller Test wäre, den Treiber nicht als Modul zu bauen, sondern fix in den Kernel?

Edit:

Ob als Modul oder fix in den Kernel macht keinen Unterschied.

Zitat von Dr. Seltsam

Hast Du Dir mal die Ausgabe von top angesehen? Bei VDR*ELEC liegt die Load bei über 2 und vdr hat über 100% CPU-Last!

Da muss etwas anderes im argen sein. Auf meinem n2+ sieht das so aus:

Tasks: 168 total,   2 running, 166 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,4 us,  0,6 sy,  0,0 ni, 99,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   3679,8 total,   2538,3 free,    629,5 used,    512,0 buff/cache
MiB Swap:      0,0 total,      0,0 free,      0,0 used.   2965,9 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                                                                   
 3939 root      20   0  967236 367872  94252 S   4,7   9,8   3:54.87 vdr                                                                                                                                                                                                       
 1827 root      rt   0       0      0      0 S   1,7   0,0   1:00.93 aml-ditest-0                                                                                                                                                                                              
 2601 root     -51   0       0      0      0 D   1,0   0,0   0:30.72 vdec-core                                                                                                                                                                                                 
 2600 root     -51   0       0      0      0 S   0,7   0,0   0:22.21 irq/44-vdec-1                                                                                                                                                                                             
 4101 root      20   0    6188   2164   1676 R   0,7   0,1   0:00.09 top                                                                                                                                                                                                       
    1 root      20   0   26400   6420   5188 S   0,0   0,2   0:01.36 systemd

Und das finde ich jetzt nicht wirklich zuviel. Ich vermute eher, das die Usache der hohen Load an einem Plugin liegen könnte, das bei mir nicht gestartet wird.

Wenn die Last so auffällig gewesen wäre, hätte ich mich schon auf Ursachensuche begeben.

Zitat von jojo61

Hast du die alte rtc definition im Devicetree entfernt?

Die alte wurde durch die neue ersetzt. Soll ich beide drin lassen?

Vielleicht sollte ich den Devicetree auch mal genauer checken. Nicht das durch irgendein anderes Include noch was reingerutscht ist, daß ich noch nicht gefunden habe.

Zitat von jojo61

reg = <0x0 0xff8000a8 0x0 0x4>;

Da liegt ein Unterschied zu dem Patch den ich drin habe. Im Patch steht

reg = <0x0 0x000a8 0x0 0x4>;

Image gebaut, dtb ersetzt und getestet (tanix tx3). Mich dünkt, ich mache irgendwas falsch.

Egal welchen Wert ich nutze echo 12041451 > /sys/class/rtc/rtc0/wakealarm die Alarmzeit ist immer 5 Minuten in der Zukunft. Auch bei echo 0 > /sys/class/rtc/rtc0/wakealarm

tanix1:~ # cat /proc/driver/rtc
rtc_time        : 13:53:38
rtc_date        : 2022-12-04
alrm_time       : 13:58:36
alrm_date       : 2022-12-04
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1
max user IRQ frequency  : 64
24hr            : yes

Und die Box wacht immer noch nicht auf.