Beiträge von Zabrimus

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.

Zitat von jojo61

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.

Zitat von jojo61

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.

Zitat von jojo61

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.

Mein Patch sieht aber genauso aus. Bist du sicher, daß die Header von 2.6.2 verwendet werden?

diff -ru8bBwd a/remote.c b/remote.c
--- a/remote.c    2022-01-12 21:03:54.000000000 +0100
+++ b/remote.c    2022-11-30 18:40:28.266080608 +0100
@@ -791,17 +791,17 @@
         switch (devtyp[i])
         {
             case 'i':
                 new cRemoteDevInput(nam,fh[i],devnam[i]);
                 break;
 
 #ifdef REMOTE_FEATURE_LIRC
             case 'l':
-                new cLircRemote(devnam[i]); // use vdr's lirc code
+                cLircRemote::NewLircRemote(devnam[i]); // use vdr's lirc code
                 break;
 #endif
 #ifdef REMOTE_FEATURE_LIRCOLD
             case 'l':
                 new cRemoteDevLirc(nam,fh[i],devnam[i]);
                 break;
 #endif

/*
 * lirc.h: LIRC remote control
 *
 * See the main source file 'vdr.c' for copyright information and
 * how to reach the author.
 *
 * $Id: lirc.h 5.1 2022/11/26 13:37:06 kls Exp $
 */

#ifndef __LIRC_H
#define __LIRC_H

#include "remote.h"
#include "thread.h"

class cLircRemote : public cRemote, protected cThread {
protected:
  int f;
  cLircRemote(const char *Name);
public:
  virtual ~cLircRemote();
  virtual bool Ready(void);
  static void NewLircRemote(const char *Name);
  };

#endif //__LIRC_H

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.

tanix1:~ # dmesg | grep  -i rtc
[    1.412669@0]- hctosys: unable to open rtc device (rtc0)
[    6.464175@3]- meson-vrtc a8.rtc: rtc core: registered meson-vrtc as rtc0
tanix1:~ # cat /proc/driver/rtc 
rtc_time        : 19:09:16
rtc_date        : 2022-12-01
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

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

Aktuelle Zeit:         2022-12-01 20:14:43

rtc_time        : 19:14:43
rtc_date        : 2022-12-01
alrm_time       : 19:19:43
alrm_date       : 2022-12-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

Fahre Rechner runter.
Powering off.

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.

Zitat von jojo61

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

Mit anderen Worten, es funktioniert, wenn die DTB passt? Was genau hast du wie gemacht? Ich würde dann versuchen, das zu übernehmen.

Da muss ich mal schauen. Aber ich habe gerade den Verdacht, daß im Device Tree noch etwas hinzugefügt werden muss.

Siehe hier.
Und damit könnte es richtig spannend werden. Welche dtb wird denn aktuell zum Test verwendet?

Zitat von jojo61

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

odroid1:~ # cat /proc/driver/rtc 
rtc_time        : 11:55:48
rtc_date        : 2022-12-01
alrm_time       : 02:07:00
alrm_date       : 2022-12-30
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

rtc-meson-vrtc.ko.zip

Zitat von jojo61

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:

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.

Zitat von Dr. Seltsam

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.

Zitat von jojo61

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?

Zitat von LotharE

Muss da bei mir noch was lokal installiert sein?

Den Fehler kenn ich nur zu gut - in CoreELEC.-20 Die Ursache habe ich noch nicht gefunden. Mal funktioniert es nur auf dem Server, mal funktioniert es nur auf der Entwicklungsmaschine. Meistens (aber auch nicht immer) baut es, wenn man das komplette Build Verzeichnis löscht und neu bauen lässt.

Der Seite zufolge könnte ein python3 -m pip install --upgrade setuptools reichen. Allerdings muss das irgendwie in das Build integriert werden, weil nicht python3 vom Host verwendet wird.

Und da python3 zu der toolchain gehört, kommt man um einen vollständigen neuen Build wohl nicht herum.

Und das Schöne ist, es gibt keine Garantie, das das Problem nicht wieder auftaucht

Wenn du das *tar installiert wird erst einmal nur die Systempartition aktualisiert. Das /storage wird dabei nicht angetastet.

Es gibt 2 Dateien, die bei einer Bestandsinstallation evt. angefasst werden müssen, wenn sie schon vorhanden sind:

/storage/.profile
/storage/.config/autostart.sh

Solange du das /usr/local/bin/install.shnicht aufrufst, solltest du keine Veränderung an der Bestandsinstallation bemerken. Nach dem Aufruf gibt es ein Verzeichnis /storage/.config/vdropt und ein paar Dateien in /storage/.config/system.d

Die Installation wurde - soweit es ging - minimalinvasiv gestaltet. Aber es ist immer eine gute Idee das /storage/.config zu sichern. In /storage/.kodiwird maximal eine xml Datei für das Powermenu geändert, um den Switch Kodi -> VDR im Menu zu haben.

Das ist alles seltsam. Alles neu installiert und keine Probleme. Dann habe ich in Kodi die Refresh Rate auf 50Hz gesetzt und schon kamen die Probleme wieder.

Die schlaue Idee, die Refresh Rate in Kodi wieder auf 60Hz zu setzen funktioniert nicht, weil ich nicht mehr an die Settings komme. Die sind jetzt disabled

Zitat von Dr. Seltsam

echo 1080p50hz > /sys/class/display/mode

hat an dem Problem auch nichts geändert. Dann habe ich die /flash/config.ini geändert und folgende Einträge gemacht:

Nach einem reboot lief wieder alles problemlos. Aber an die Kodi Einstellungen komme ich immer noch nicht. Aber wenn es jetzt läuft, werde ich erstmal nix weiter daran basteln.

Zitat von rell

Zabrimus So, damit sollte es laufen. Bitte nochmal probieren. Wenns geht, kannst du die beiden letzten natürlich weglassen.

Bliebe dann noch die Sache mit NM12 und DRM...

Soooo. VDR startet und ich habe ein HD Bild. Aber. Ich meine, es sieht cool aus, aber wahrscheinlich nicht so gewollt.

Es liegen 2 gleiche Bilder übereinander, das zweite mit seltsamen Farben, vertikal nach unten verschoben und leicht gestreckt.

Auf der Konsole habe ich permanent diese Ausgabe:

CodecVideoSendPacket: send_packet ret: Resource temporarily unavailable

CodecVideoSendPacket: send_packet ret: Resource temporarily unavailable

Das Journal sieht am Ende dann so aus:

Zitat von reini-at

hab mir nur überlegt ob es nicht sinnvoller ist abzufragen ob cecremote überhaupt aktiviert ist, eventuell so:?

Kann man natürlich auch machen. Ich hatte vor dem Merge geprüft, ob das Kommando das Script abbricht, wenn das Plugin nicht geladen wurde. Aber es läuft.

Zitat von LotharE

Wenn cecremote nicht genutzt wird, gibt's ne Fehlermeldung, die aber nicht stört:

Genau das meine ich. Unnötige Fehlermeldungen sind unschön und ich würde sie als "moderate" einstufen. Kann man bei Gelegenheit fixen, ist aber nicht dringend.

Zitat von rell

v4l2request brauchst du nicht, sondern v4l2m2m und das ist aktiviert.

Okay. Denkfehler gefunden. Ich dachte ich hätte irgendwo gelesen v4l2request wäre Pflicht und deshalb ....

Zitat von rell

Zabrimus Ich habe nochmal 2 patches hinzugefügt. Damit wird das Log wohl zwar ziemlich voll, aber evtl. kann ich sehen, was an den Werten für den Commit nicht passt. Gerne testen und das Log schicken.

Das journal habe ich angehängt.

softhddevice-drm-journal.txt

Zitat von Dr. Seltsam

./build.sh -config CoreELEC-19.4-Matrix

Oje. Die habe seit Monaten nicht mehr gebaut.

Zitat von reini-at

hatte versucht ein PR zu erstellen (kein commit natürlich, war wohl schon zu spät ), aber das ging wohl schief, habe es nochmal gemacht, jetzt sieht es glaube ich besser aus.

Ist jetzt mit drin

Zitat von Dr. Seltsam

Eigentlich wollte ich mir nur mal anschauen, wie der Quellcode von kodi für amlogic aussieht. Gibt es den in irgendeinem repo fix und fertig zur Ansicht, oder wird der nur durch Patches erzeugt?

Ganz allgemein kommt man auf 3 Wegen an die Sourcen:

- Falls man selbst gebaut hat, finden sich im Build Verzeichnis CoreELEC/build.CoreELEC-Amlogic-ng.arm-19/build/kodi-XXXX die Sourcen

- Oder im Verzeichnis sourcen das heruntergeladene Archiv (meist tar oder zip).

- Oder in den package Dateien. Z.B.

CoreELEC/packages/mediacenter/kodi/package.mk

PKG_URL="https://github.com/xbmc/xbmc/archive/${PKG_VERSION}.tar.gz"

mit PKG_VERSION="286694e9df8741313a688b46940661a30f36f35c"

Zitat von beta

Ich habe das hier beschrieben: https://forum.odroid.com/viewt…hp?f=177&t=43593&start=50

Sensationell! Passt zwar nicht hierhin, aber danke. Wird unbedingt probiert.

Zitat von rell

Hm, lese ich nicht so. Amlogic verwendet wie RPi einen v4l2_m2m Treiber, der wird gebaut und lt. logs auch genutzt

Genau deshalb denke ich, ich habe irgendwo einen Denkfehler und finde den nicht. Ich habe das package.mk mal gekürzt

PKG_NAME="ffmpeg"

case "${PROJECT}" in
  Amlogic)
    PKG_URL="https://github.com/jc-kynesim/rpi-ffmpeg/archive/${PKG_VERSION}.tar.gz"
    ;;
esac

### V4L2_SUPPORT ist yes für amlogic
if [ "${V4L2_SUPPORT}" = "yes" ]; then
  PKG_FFMPEG_V4L2="--enable-v4l2_m2m --enable-libdrm"

  ## Project ist Amlogic... also ...
  if [ "${PROJECT}" = "Allwinner" -o "${PROJECT}" = "Rockchip" -o "${DEVICE}" = "iMX8" ]; then
    PKG_V4L2_REQUEST="yes"
  elif [ "${PROJECT}" = "RPi" -a "${DEVICE}" = "RPi4" ]; then
  else
    ## ..... landet der hier
    PKG_V4L2_REQUEST="no"
  fi

  ### PKG_V4L2_REQUEST steht ja jetzt auf "no"
  if [ "${PKG_V4L2_REQUEST}" = "yes" ]; then
  else
    ## und wird hier nicht wieder alles abgeschaltet, was notwendig ist?
    PKG_FFMPEG_V4L2+=" --disable-libudev --disable-v4l2-request"
  fi
else
fi

Zitat von rell

Ansonsten kann ich versuchen herauszufinden, warum drm in den abort läuft - falls du testwillig bist.

Ich habe extra dafür eine Kiste auf Standby

Seit über einer Woche will ich mich mal dransetzen den Dev/Test-Zyklus zeitlich stark zu verkürzen (oder es zumindest zu versuchen), aber ich komme nicht dazu. Immer die vielen Images bauen, Update, Reboot, Test- Zyklen dauern mir zu lange für solche Sachen.