Video Treiber für Odroid-N2+ (softhdodroid)

ich finde im ersten Post diesen Link: https://wiki.odroid.com/odroid-n2/os_images/ubuntuder der führt mich ganz unten bei Ubuntu 22.04 nach hier: https://wiki.odroid.com/odroid-n2/os_images/ubuntu/20220622
der Link dann wiederum nach hier: https://de.eu.odroid.in/ubuntu_22.04lts/N2/

von dort habe ich ubuntu-22.04-4.9-minimal-odroid-n2-20220622.img genommen
Das habe ich dann ohne einen anderen Kernel zu installieren verwendet.

Passt das oder oder bin ich irgendwo falsch abgebogen?

Was sagt dennuname -r?

Der sollte passen.

Du kannst in Deiner runvdr denStart eines Scripts /usr/local/bin/smp-affinity.sh mit diesem Inhalt eintragen:

!/bin/sh
# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright (C) 2018-present Team CoreELEC (https://coreelec.org)
SMP="../smp_affinity"
MESONIR="`find /proc/irq/ -name ir-meson`"
ETH0="`find /proc/irq/ -name eth0`"
VDEC0="`find /proc/irq/ -name vdec-0`"
VDEC1="`find /proc/irq/ -name vdec-1`"
PREDI="`find /proc/irq/ -name pre_di`"
AFIFO0="`find /proc/irq/ -name afifo0`"
AOCEC="`find /proc/irq/ -name hdmi_aocec*`"
USB3="`find /proc/irq/ -name xhci-hcd:usb1`"
IRQ="$AOCEC $ETH0 $USB3 $VDEC0 $VDEC1 $AFIFO0 $MESONIR $PREDI"
cpu=0
aff=1
for i in $IRQ; do
if [ -f "$i/$SMP" ];then
cpu=$((cpu + 1))
if [ -d "/sys/devices/system/cpu/cpu$cpu" ];then
aff=$((aff * 2))
haff=`printf '%x\n' $aff`
else
aff=2
haff=2
cpu=0
fi
echo "echo $haff > $i/$SMP"
echo $haff > $i/$SMP
fi
done
exit 0

Ansonsten habe ich gelegentlich auch Probleme, die leider schwer nachzustellen sind. Gestern blieb das Bild z.B. bei Rückkehr von kodi zu vdr schwarz und im Log stand was von codec not open. Das ließ sich nur mit einem vdr restart beheben. Habe dann 20x den Wechsel hin und her durchgetestet, ohne dass Probleme auftraten. Das debuggen wird erschwert, weil der Hardketnel- und der CoreElec-Kernel zu gesprächig sind. Die müllen das log mit völlig irrelevanten Infos zu.

danke für das Skript !

Hier wieder so ein Effekt, nach systemctl restart vdr zwei instanzen da sich die eine nicht beendet hat und SIGKILL hilft nicht

root@odroid:~# killall -9 vdr
root@odroid:~# psg vdr
root        4166       1  0 14:15 ?        00:00:02 /usr/bin/vdr
root        4385       1  0 14:22 ?        00:00:02 /usr/bin/vdr

habe das Skript in die systemd Unit eingetragen:

ExecStartPre=/root/bin/smp-affinity.sh
ExecStart=/usr/bin/vdr

und den Pfad zu sh angepasst #!/usr/bin/sh

Wie sieht denn das systemd Script für vdr aus?

Das softhdodroid-Plugin braucht recht lange zum Beenden, wenn man z.B. den auf der Konsole gestarteten vdr mit strg-c terminiert. Vielleicht wartet systemd nicht lange genug auf die Rückmeldung einer erfolgreichen Beendigung und startet zu früh? Von systemd habe ich aber kaum Ahnung.

Was bei mir immer geht ist der Neustart über das Einstellungen-Menü von vdr. Ich habe vdr aber auch über die normale runvdr gestartet.

das habe ich überall so kommt aus dem PPA von seahawk198:

[Unit]
Description=Video Disk Recorder
After=network.target

[Service]
Type=notify
ExecStartPre=/bin/bash /usr/lib/vdr/merge-commands.sh "commands"
ExecStartPre=/bin/bash /usr/lib/vdr/merge-commands.sh "reccmds"
ExecStartPre=/root/bin/smp-affinity.sh
ExecStart=/usr/bin/vdr
Restart=on-failure
RestartPreventExitStatus=0 2

[Install]
WantedBy=multi-user.target

denke hier liegt das Problem (gerade mit dmesg entdeckt):

[   78.671430] mem flags 4099 4099, 4
[   78.675162] Input block allocation failed
[   78.679370] vframe_block storage allocation failed
[   78.710628] not enough mem for VFRAME_INPUT size 524288, ret=-10003
[   78.711419] mem flags 4099 4099, 4
[   78.715172] Input block allocation failed
[   78.719464] vframe_block storage allocation failed
[   78.750634] not enough mem for VFRAME_INPUT size 524288, ret=-10003
[   78.751424] mem flags 4099 4099, 4
[   78.755555] Input block allocation failed
[   78.759607] vframe_block storage allocation failed
[   78.850534] vdec requested to be disconnected
[   80.870465] vdec_disconnect timeout!!! status: 0x3
[   80.870508] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   80.878015] pgd = ffffffc0c92e0000
[   80.881568] [0000000000000000] *pgd=0000000000000000, *pud=0000000000000000
[   80.888677] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[   80.894396] Modules linked in: cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_conservative joydev i2_meson_master sch_fq_codel amvdec_vp9 amvdec_vc1 amvdec_real amvdec_mmpeg4 amvdec_mpeg4 amvdec_mpeg12 amvdec_mmjpeg avdec_mjpeg amvdec_h265 amvdec_h264mvc amvdec_mh264 amvdec_h264 amvdec_avs stream_input decoder_common firmware media_lock fuse ip_tables x_tables
pv6 spidev spi_meson_spicc
[   80.930278] CPU: 1 PID: 3255 Comm: device 1 receiv Not tainted 4.9.337-31 #1
[   80.937468] Hardware name: Hardkernel ODROID-N2Plus (DT)
...
...
[   82.101839] [<ffffff8009ca009c>] wait_for_common+0x9c/0x160
[   82.107556] [<ffffff8009ca01d0>] wait_for_completion_timeout+0x30/0x40
[   82.114231] [<ffffff8009992e40>] video_receiver_event_fun+0xd0/0x140
[   82.120730] [<ffffff800987c39c>] vf_unreg_provider+0x138/0x1ec
[   82.126766] [<ffffff8001de3220>] vdec_release+0x70/0x430 [decoder_common]
[   82.133680] [<ffffff8001e2645c>] video_port_release+0x6c/0xc0 [stream_input]
[   82.140864] [<ffffff8001e28c6c>] amstream_release+0x1ec/0x310 [stream_input]
[   82.148032] [<ffffff800924ead0>] __fput+0xac/0x1fc
[   82.152969] [<ffffff800924eca4>] ____fput+0x24/0x30
[   82.157998] [<ffffff80090cc7c8>] task_work_run+0xd8/0x110
[   82.163544] [<ffffff80090bc088>] get_signal+0x708/0x7c0
[   82.168917] [<ffffff800908b7a0>] do_signal+0x80/0xa94
[   82.174117] [<ffffff800908c588>] do_notify_resume+0xa8/0xc0
[   82.179836] [<ffffff80090836ac>] work_pending+0x8/0x10

die Plugin Optionen habe ich identisch zu der chroot Umgebung unter welcher es prima funktioniert:

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

Es ist in der Tat der Kernel. In der chroot funktioniert unter 20.04 sogar ein do-release-upgrade. Da bleibt dann aber auch der Kernel von CE erhalten. Das ist eben das Problem mit dem fehlenden mainline-Support.

danke euch! Ich schaue mal nach was älterem.

Hoffentlich kommt das bald in den mainline Kernel

ich finde keine Möglichkeit den Kernel zurück zu drehen, im git finde ich auch keinen mit dem entsprechenden Tag. Übersehe ich etwas?
Die einzige Option scheint das 20.04 statt dem 22.04 Image.

generell habe ich nichts dagegen. Nur wie sieht es in der Zukunft aus, weißt du/ihr schon etwas darüber wie es mit der Unterstützung im Kernel weiter gehen soll?

Beim Wohnzimmer VDR werde ich sehr wahrscheinlich erst mal bei der chroot Lösung bleiben.
Der Test wie es unter Ubuntu läuft ist für zwei weitere Anwendungen. Einmal im Wohnmobil, da läuft eine Haussteuerung drauf (die habe ich in c++ implementiert) und ein mal im Garten mit der selben Steuerung nur da für den Pool. Beides betreibe ich im Moment mit einem Rasperry Pi auch jeweils mit VDR, nur ist der für den VDR nicht wirklich gut daher denke ich darüber nach es mit dem odroid n2+ abzulösen.
Und auch die Haus-/Pool-Steuerung nebst Zugriff auf GPIO, W1, ... und alles was ich da sonst noch drauf (squeezebox Server, ...) benötige fühlt sich in chroot etwas umständlich an.

Die OpenGL-Treiber funktionieren wohl inzwischen unter mainline. Das ist aber nur die halbe Miete (OpenGL-Beschleunigung).

Mit der VPU sieht es aber mau aus. Ist gibt Meinungen, dass die unter Amlogic nichts taugt und dass das (bis HD) die CPU machen soll. Ich persönlich sehe das anders. Ich bin mit der Qualität sowohl unter HD als auch unter UHD sehr zufrieden.

Die einzige Upgrade-Möglichkeit, die mit momentan einfällt, wäre der A311D2 (z.B. Khadas Vim4). Die läuft unter CE ein 5.4-Kernel (immer noch etwas entfernt vom Mainline 6.x). OpenGL sollte kein problem sein (um ehrlich zu sein, weiß ich es aber nicht) und die VPU scheint ja unter CoreElec zu funktionieren. Ich kann Dir aber nicht sagen, ob die Aufrufe dann für jojo61's Plugin geändert werden müssten oder ob es eine Distribution außer CoreElec gibt, unter der das Plugin dann "native" läuft. Allerdings scheint es noch Probleme mit einigen HD-Audio-Formaten zu geben. Die kennen wir aber schon von Rockchip und dem DRM-Plugin, beim dem Passthrough z.B. nicht funktioniert.

Damit hat jojo61 leider Recht. Beste Lösung (aus meiner Sicht, da alle Audio-Formate und HD und UHD unterstützt werden) ist der 4.9-Kernel entweder im Ubuntu 20.04 oder unter CE 20.0-ng, dann als chroot. Als Alternative zum Odroid N2+ kann ich den Radxa Zero empfehlen. Das System mit chroot passt auf das eMMC, eine SD-Karten kann für Aufnahmen verwendet werden. Das Teil läuft genau so flüssig wie der N2+, bietet aber noch WLAN (und Bluetooth) und ist deutlich kleiner. Hier wirst Du allerdings wieder mit den GPIOs Probleme bekommen unter der chroot, da die overlays meiner Meinung nach nicht richtig in CE implementiert sind (getestet für die LED, wo der Device Tree zwar vorhanden ist, aber Änderungen keine Auswirkungen haben). Das das Radxa-Image oder das Armbian-Image haben sicherlich keine VPU-Schnittstelle implementiert...

Zitat von horchi

generell habe ich nichts dagegen. Nur wie sieht es in der Zukunft aus, weißt du/ihr schon etwas darüber wie es mit der Unterstützung im Kernel weiter gehen soll?

Dazu äußern sich ja schon die Eingangsposts in diesem Thread...

Langfristig Spass macht das wohl nur mit mainline Unterstützung. Der kurzfristige Erfolg ist zwar schön und reicht wohl für die meisten, aber evtl. wäre es kein Schaden, dass man sich anschaut, wie weit LibreELEC hier schon ist? Das nutzt zumindest zukunftssichere Komponenten. Vor einiger Zeit hatte ich das Image für eine S905 Box mal kurz angetestet, und kodi und vdr liefen zumindest schon mal...

EDIT: https://linux-meson.com/hardware.html würde doch gar nicht so schlech aussehen für S922X

Kodi benötige ich nicht (bzw. ich verwende es wenn es da ist einmal im Jahr für eine Dia Show).

Dann teste im mal gpio unter chroot. Verwendest du GPIO per Skript oder mit c/c++ (ich muss mir das noch ansehen, welche lib, etc, hab das bislang nur auf dem Raspi verwendet). Will damit jetzt nicht den Thread hier kapern.

Nachtrag, ggf. kann es ja noch jemand brauchen:
mit einem laufenden sshd (auf separatem port) in der chroot Umgebung ist das ganze deutlich praktischer, damit kommt man auch mit dem emacs von Remote (emacs tramp package) direkt an das System - das ging auch vorher nur war man dann im corelec Environment im welchem man nicht compilieren konnte.
Man benötigt damit den login zu coreelec (fast) nicht mehr.

Mit einem # getrennt kann man beim Datei remote öffnen im emacs den Port angeben:

/scp:root@uhdvdr#2022:build/.....

Habe hier die Beschreibung wie man zu dem sshd in chroot kommt ergänzt (Kapitel 7):
https://github.com/horchi/vdrO…2Plus/blob/main/README.md