Beiträge von jojo61

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

Ich werde es testen und berichten

Nach dem clean auschecken und starten kommt folgendes:

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.

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

Zitat von Dr. Seltsam

Inwieweit ist auch der Odroid N2(+) betroffen?

Es geht hier nur um Boards die keinen Hardware RTC besitzen (siehe oben). Das Odroid-N2 hat einen Hardware RTC (sogar mit Bufferbatterie) und ist nicht betroffen.

Betroffen sind X96 Max und Tanix und ähnliche ohne RTC.

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.

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:

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

Zabrimus Ich habe heute mal einen update gemacht und festgestellt das der Kernel wieder das Log zumüllt:

Feb 24 08:41:37 x96 kernel: dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 3 instead of 4. 188 bytes lost
Feb 24 08:41:37 x96 kernel: dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 2 instead of 3. 188 bytes lost
Feb 24 08:41:37 x96 kernel: dvb_demux: dvb_dmx_swfilter_section_new: section ts padding loss: 184/184
Feb 24 08:41:37 x96 kernel: dvb_demux: dvb_dmx_swfilter_section_new: pad data: 13 c1 39 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Das hatten wir doch schon mal weggepatcht. Damit ist sinnvolles Fernsehen nicht möglich und ausserdem schreibt es die SD Karte kaputt.

PS: Mein Fehler ich hatte einen Update der dvb-Treiber unter Kodi gemacht und das darf man nicht. Dann bekommt man die Standard Treiber und da ist das Log noch drin. Jetzt frag ich mich wie ich die Treiber von Zabrimus wieder bekomme.

Ahh ok. Ich würde dir eh empfehlen die GIT Version zu nehmen. Zumindest bei mir läuft die mit Nvidia 1050

Bin etwas verwirrt. Ich dachte es geht bei dir um die Intel GPU A380. Im Log ist es aber eine Nvidia GPU mit Cuvid. Welche Karte hast du denn da ? Bei mir läuft das mit einer 1050. Allerdings mit dem aktuellen Placebo GIT. Da ich nichts aus dem neueren Placebo nutze, macht es wenig Sinn Placebo zu aktualisieren wenn es mit dem alten läuft never change a running system

Da hast du ins schwarze getroffen Da ich nicht genau wusste ab wann die neuen structs verwendet werden, habe ich sie ab API grösser 229 angenommen.

Ich ändere den #if an der Stelle damit es auch mit API 229 klappt. Eingecheckt !

Ja die Auswertung der Paramter bei DRM ist irgendwie nicht optimal. Ohne den -g Parameter nimmt er den ersten Wert aus dem EDID und schaut nicht mehr auf den -r Parameter. Meist ist das aber 1920x1080x60 weil ja alles auf USA getrimmt ist

Zitat von beta

Es sieht so aus, als wäre der Test (Radxa Zero) erst einmal erfolgreich gewesen. Ich brauche jetzt keinen KODI-Start mehr vorab und das Anspielen eines Film-Schnipsels.

jojo61 Kannst Du das bitte übernehmen.

Habs nun übernommen und eingecheckt.

Zitat von jsffm

Mit placebo Schwarzbild

Ohne placebo Standbild

Also an der Version ohne placebo habe ich nichts gemacht. Das ist sonderbar.

Und für die Version mit placebo habe ich nur die neueste placebo Version ermöglicht. Die Version mit API 206 sollte auch noch gehen.

Hast du zwischenzeitlich noch andere updates gemacht ?

Ich habe nun noch einen Fix für den Build mit LIBPLACEBO_GL eingecheckt. Das wird für die softhddrm Version benötigt.

Dabei ist mir noch aufgefallen das bei HLG auch die LUT verwendet wird (wenn man eine hat). Das habe ich noch abgeschaltet.

mfg

jojo61

Zitat von jsffm

Bei compile mit git kommt:

Hmm ich habe mit git getestet. Ich schaue es mir morgen nochmal an. Für heute ist Feierabend

Ja ich habe nur mit API 208 und 246 getestet. Alles dazwischen ist Zufall da ich nicht immer gesucht habe in welchen API welche änderungen gemacht wurden.

Um auch diesen Thread aktuell zu halten:

softhdcuvid und ableger unterstützt nun die aktuelle libplacebo mit API 246. Falls es da Probleme gibt nehme ich gerne Feedback an.

In libplacebo hat sich viel bzgl. UHD getan und ich hoffe es geht noch alles.

Ich war fleissig und habe nun den libplacebo Teil upgedatet und nun läuft er mit API Version 246 (dem aktuellen GIT).

Ich hoffe ich habe nix kaputt gemacht für ältere Versionen.

Würe mich interessieren ob nun die A380 auch mit libplacebo läuft.

No matching format found

So wie es aussieht hat libplacebo mit dem gepackten Format ein Problem. Das verwundert etwas, weil du ja sagst das ein Bild kommt.

Ansonsten kann ich an dem Log nichts finden was schräg aussieht. Ich schau nun mal ob ich einen neuere Version von Libplacebo unterstützen kann.

Die Änderung für die nicht placebo Version werde ich schonmal einchecken.

Änder doch mal die Zeile 5476 in:

p->context.log_level = PL_LOG_ALL;

Damit wird das libplacebo Log aktiviert. Könnte sein das das auf der Konsole rauskommt.