Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

Ich habe jetzt versucht den Tree von nst mit Hilfe von media_build zu kompilieren. Leider passen die Backport-Patches nicht auf seinen Tree.

Wie kompiliert ihr das denn?

Hm, ich kenne Archlinux nicht (lt. Deiner Sig anscheinend das fragliche System) - sollte es für die Kernel Pakete nicht auch PKGBUILDs geben? Hier dann einfach den SRC_URI auf das GIT Repo anpassen (z.B. https://github.com/herrnst/ddd…nux-4.4.y-ddbridge.tar.gz bzw. <branch>.tar.gz) und Paket auswerfen lassen (wäre eine Variante zumindest auf Gentoo). Alternativ z.B.

git diff linux-4.4.y..linux-4.4.y-ddbridge

und den resultierenden Patch auf beliebigen Kernel Source anwenden ( mini73: Das wäre ggf. für Dich eine Variante für Ubuntu - apt-get source linux-image / patch < patchfile / dpkg-buildpackage).

Standalone-Build wird ohne Weiteres kaum funktionieren, aber Sinn und Zweck der Sache ist halt, den Kram als Bestandteil vom Kernel zu haben, um am Ende "einfach" die Patches auf der Media-Liste abzukippen.

Ja klar gibt's das. Ich fange aber sicher nicht an am Kernel Source rumzubauen.
Kernel Source ist aber ein No-Go. Deswegen habe ich ja versucht über media_build zu gehen.

Also wie der Weg über media_build am besten zu bestreiten wäre, kann ich nicht sagen (Hints welcome). Ausgehend davon, dass sich media_build am linuxtv.org-media_tree bedient, hast Du alles, was Du brauchst, wenn Du diesen Diff (oder: TDA18212/STV0367 Testing / Zusatzfeatures mit API irgendwie als Patch in das Konstrukt reinbekommst.

Über die Patches funktioniert es tatsächlich.
Ich hatte versucht deinen Tree über "make tar" in das passende Format zu bekommen. Da gab es aber nur Probleme.

https://github.com/herrnst/ddd…ile-using-media_build.git

Hat auf einer Ubuntu 16.04beta Test-VM gerade wunderbar geklappt.

Mit Kernel 4.4.5 läuft es zwar durch aber

modprobe ddbridge
modprobe: ERROR: could not insert 'ddbridge': Invalid argument

[ 3661.547515] dvb_core: Unknown symbol media_devnode_remove (err 0)
[ 3661.547600] dvb_core: Unknown symbol media_create_intf_link (err 0)
[ 3661.547625] dvb_core: Unknown symbol media_create_pad_links (err 0)
[ 3661.547652] dvb_core: Unknown symbol media_create_pad_link (err 0)
[ 3661.547675] dvb_core: disagrees about version of symbol media_device_register_entity
[ 3661.547677] dvb_core: Unknown symbol media_device_register_entity (err -22)
[ 3661.547725] dvb_core: Unknown symbol media_entity_pads_init (err 0)
[ 3661.547782] dvb_core: Unknown symbol media_devnode_create (err 0)
[ 3661.547789] dvb_core: disagrees about version of symbol media_device_unregister_entity
[ 3661.547791] dvb_core: Unknown symbol media_device_unregister_entity (err -22)

Mod.: Es braucht kein Vollzitat vom Post davor, es kann jeder lesen worauf Du antwortest.

Das sieht für mich so aus, als wäre bei "make install" irgendetwas schief gelaufen, oder Deine Kernel-Header passen nicht zum laufenden Kernel.

Der Tipp mit den Kernelheaders hat was gebracht....

lsmod | grep ddbridge
ddbridge               68768  35
cxd2099                 6207  1 ddbridge
dvb_core               91622  1 ddbridge
i2c_core               26745  10 drm,i915,i2c_i801,cxd2099,ddbridge,drm_kms_helper,i2c_algo_bit,stv090x,lnbp21,stv6110x
linux media_build # rmmod ddbridge
rmmod: ERROR: Module ddbridge is in use
linux media_build # systemctl restart vdr
linux media_build # dmesg | grep "Digital Devices"
[    3.669050] Digital Devices PCIE bridge driver 0.9.18, Copyright (C) 2010-15 Digital Devices GmbH
[    3.669195] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter

aber sollte hier nicht was anderes stehen?

dmesg | grep dvb

v4l-dvb-saa716x: d7e98fc592305a600909003da2b7cc4338242511 saa716x_ff: Do not return on command ready timeout

Aber vdr zeigt meine 4 Tuner an....

Zitat von Tinitus

Code

linux media_build # rmmod ddbridge
rmmod: ERROR: Module ddbridge is in use
linux media_build # systemctl restart vdr
linux media_build # dmesg | grep "Digital Devices"
[    3.669050] Digital Devices PCIE bridge driver 0.9.18, Copyright (C) 2010-15 Digital Devices GmbH
[    3.669195] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter

Der alte Treiber ist noch nicht entladen ("in use" bei rmmod). Du solltest zuerst Deinen VDR beenden ("systemctl stop vdr") bzw. sonstige Software, die auf die Karten zugreifen, dann erst die Module entladen ("rmmod ddbridge", ausserdem alle zugehörigen Frontent-Module wie cxd2099, stv0910, stv0367 und was sonst zu Deiner Karte gehört), und dann neu laden (im Zweifelsfall: Reboot). Version 0.9.18 identifiziert ganz klar noch alte Module, da muss "0.9.22" stehen.

Nach Neustart sieht es so aus: (bei 4 Tunern)

dmesg | grep dvb
fb4149b86b9a5cd57217d74728393d583fca6b7c [media] ddbridge: Update to version 0.9.22 from vendor-provided dddvb-0.9.22 package
56ad35ff0e36f5d56645b2f0a60273233555035d [media] dvb-frontends/stv6111: Remove dead code, fix [-Wunused-variable]
fb4149b86b9a5cd57217d74728393d583fca6b7c [media] ddbridge: Update to version 0.9.22 from vendor-provided dddvb-0.9.22 package
56ad35ff0e36f5d56645b2f0a60273233555035d [media] dvb-frontends/stv6111: Remove dead code, fix [-Wunused-variable]
dmesg | grep "Digital Devices"
[ 3.627837] Digital Devices PCIE bridge driver 0.9.22, Copyright (C) 2010-15 Digital Devices GmbH
[ 3.628022] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter

Ist das dann OK so?

Zitat von Tinitus

Code

[    3.627837] Digital Devices PCIE bridge driver 0.9.22, Copyright (C) 2010-15 Digital Devices GmbH
[    3.628022] DDBridge driver detected: Digital Devices Cine S2 V6.5 DVB adapter

Das sieht sehr gut aus. Kannst Du die Ausgabe von lsmod (komplett) und dmesg (komplett) mal pastebin'en und Deine genauen Kartentypen (Bridge-Karte, DuoFlex-Module usw.) durchgeben? Funktioniert mit der Konstellation alles?

Cool, daß sich hier etwas tut. Vielen Dank nst!
Ich habe die letzten Beiträge aus Zeitmangel nur kurz überflogen, mit

Zitat von nst

Hm, ich kenne Archlinux nicht (lt. Deiner Sig anscheinend das fragliche System) - sollte es für die Kernel Pakete nicht auch PKGBUILDs geben? Hier dann einfach den SRC_URI auf das GIT Repo anpassen (z.B. https://github.com/herrnst/ddd…nux-4.4.y-ddbridge.tar.gz bzw. <branch>.tar.gz) und Paket auswerfen lassen (wäre eine Variante zumindest auf Gentoo). Alternativ z.B.

Code

git diff linux-4.4.y..linux-4.4.y-ddbridge

und den resultierenden Patch auf beliebigen Kernel Source anwenden

hast Du mich aber neugierig gemacht. Kann ich mir bei Github direkt ein Diff erzeugen lassen, das ich in /etc/portage/patches/sys-kernel/gentoo-sources/ ablegen kann, so daß beim Installieren eines Kernels automatisch der DD-Treiber reingepatcht wird? Das wäre schon mal eine große Erleichterung, wenn ich den Multimedia-Kram nicht mehr immer separat via media_build_experimental installieren müsste.

Zitat von gentoo-vdr

Kann ich mir bei Github direkt ein Diff erzeugen lassen, das ich in /etc/portage/patches/sys-kernel/gentoo-sources/ ablegen kann, so daß beim Installieren eines Kernels automatisch der DD-Treiber reingepatcht wird? Das wäre schon mal eine große Erleichterung, wenn ich den Multimedia-Kram nicht mehr immer separat via media_build_experimental installieren müsste.

Ja: Du kannst als URI https://github.com/herrnst/dddvb-linux-kernel/compare/<basebranch>...<comparebranch> zwei Branches (drei Punkte als Trenner) miteinander vergleichen (funktioniert natürlich mit jedem anderen Repository auch). Mit https://github.com/herrnst/ddd…e/master-ddbridge-testing werden Dir z.B. die Unterschiede von mediatree/master-ddbridge und mediatree/master-ddbridge-testing angezeigt. Wenn Du an den URI dann .diff oder .patch anhängst, bekommst Du entsprechend einen Diff oder ein Patchfile mit allen Commits.

Ich würde nach neusten Kenntnissen aber davon abraten, direkt die Sourcen zu patchen. Anscheinend ist die media_build-Methode die pflegeleichteste Variante (danke, Copperhead!). Wenn Du die Sourcen patchst, läufst Du mit jedem Major-Update von gentoo-sources in Gefahr von API-Inkompatibilitäten - von 4.4 auf 4.5 gibts z.B. Unterschiede bzgl. des neuen Media Controller Krams, von 4.5 auf folgende (mediatree) gibts Unterschiede im get_frontend() Interface, vgl. 7e3e68b.

Zitat von nst

Ja: Du kannst als URI https://github.com/herrnst/dddvb-linux-kernel/compare/<basebranch>...<comparebranch> zwei Branches (drei Punkte als Trenner) miteinander vergleichen (funktioniert natürlich mit jedem anderen Repository auch). Mit https://github.com/herrnst/ddd…e/master-ddbridge-testing werden Dir z.B. die Unterschiede von mediatree/master-ddbridge und mediatree/master-ddbridge-testing angezeigt. Wenn Du an den URI dann .diff oder .patch anhängst, bekommst Du entsprechend einen Diff oder ein Patchfile mit allen Commits.

Ich würde nach neusten Kenntnissen aber davon abraten, direkt die Sourcen zu patchen. Anscheinend ist die media_build-Methode die pflegeleichteste Variante (danke, Copperhead!). Wenn Du die Sourcen patchst, läufst Du mit jedem Major-Update von gentoo-sources in Gefahr von API-Inkompatibilitäten - von 4.4 auf 4.5 gibts z.B. Unterschiede bzgl. des neuen Media Controller Krams, von 4.5 auf folgende (mediatree) gibts Unterschiede im get_frontend() Interface, vgl. 7e3e68b.

Danke! Das Problem mit den API-Inkompatibilitäten könnte man ja lösen, indem man sich vor dem Installieren eines neuen Kernels den entsprechenden Diff zieht und beim Patchverzeichnis die jeweilige Versionsnummer mit angibt, also z.B. gentoo-sources-4.4.5 statt nur gentoo-sources. Dann müsste es nur für jede Kernelversion einen eigenen Branch mit und ohne DD-Treiber geben, den man vergleichen lassen kann. Die vielen Branches verwirren mich jetzt schon (was ist eigentlich der Unterschied zwischen ddbridge und dddvb?). Ich bleibe daher erst mal bei media_build_experimental. Falls Du aber noch Tester brauchst, helfe ich gerne. Ich habe eine Digital Devices DVBCT V6.1 im Einsatz, allerdings ohne CI.

Zitat von gentoo-vdr

Danke! Das Problem mit den API-Inkompatibilitäten könnte man ja lösen, indem man sich vor dem Installieren eines neuen Kernels den entsprechenden Diff zieht und beim Patchverzeichnis die jeweilige Versionsnummer mit angibt, also z.B. gentoo-sources-4.4.5 statt nur gentoo-sources. Dann müsste es nur für jede Kernelversion einen eigenen Branch mit und ohne DD-Treiber geben, den man vergleichen lassen kann.

Die Branches basierend auf den Kernelversionen müssen aber entsprechend erzeugt und ggf. gepflegt werden Wenn der Kram aber tatsächlich irgendwann irgendwie submitted werden soll, ist der Linux-Media Tree ("mediatree/"-Branches) aber maßgeblich, und da wollte ich jetzt eigentlich den Fokus drauflegen.

Zitat von gentoo-vdr

Die vielen Branches verwirren mich jetzt schon (was ist eigentlich der Unterschied zwischen ddbridge und dddvb?).

Die mit "dddvb"-markierten Branches sind meine ersten Versuche, das dddvb-Package von Digital Devices in seine Bestandteile zu zerlegen (da werd' ich mich nicht mehr weiter drum kümmern). Die "ddbridge"-Branches sind "noch mehr" zerlegte Varianten, aber so aufgesplittet, dass eine Basis ohne nötige API-Änderungen vorhanden ist (*-ddbridge und *-ddbridge-testing, alle üblichen Karten bis auf die MaxS8 unterstützt) und welche auch IMHO am problemlosesten an den Media-Maintainern vorbeikommen könnte. Die ddbridge-feature Branches haben dann Commit für Commit alle API-Änderungen (ein API-Command für die MaxS8 plus notwendigem mxl5xx-Demod, Netstream/OctoNet Support, Modulator-API und DVB-C Resi Modulator Card Support) und vervollständigen das ddbridge-Package auf das, was Digital Devices ausliefert.

Zitat von gentoo-vdr

Ich bleibe daher erst mal bei media_build_experimental. Falls Du aber noch Tester brauchst, helfe ich gerne. Ich habe eine Digital Devices DVBCT V6.1 im Einsatz, allerdings ohne CI.

Rückmeldungen zum -testing-Branch wären mit der Bridge-Karte sehr interessant! Die TDA18212 Tuner-Unterstützung sollte mittlerweile besser funktionieren und im CXD2843-Frontend ist schon ein wenig Kosmetik eingeflossen (alles Dinge, die in der Vergangenheit bereits durch die Media-Maintainer kritisiert wurden). Ausserdem werd' ich mich nochmal näher mit dem STV0367-Ersatz beschäftigen (das ist auch notwendig). Hatte da schonmal rumprobiert aber dann zunächst aufgrund von Mangeln im ddbridge-Modul (Resourcen wurden im Fehlerfall nicht freigegeben und haben dazu geführt, dass das Modul nicht mehr zu entladen war, sollte mittlerweile verbessert sein) abgebrochen.

Zitat von nst

Die Branches basierend auf den Kernelversionen müssen aber entsprechend erzeugt und ggf. gepflegt werden Wenn der Kram aber tatsächlich irgendwann irgendwie submitted werden soll, ist der Linux-Media Tree ("mediatree/"-Branches) aber maßgeblich, und da wollte ich jetzt eigentlich den Fokus drauflegen.

Verständlich. Letzteres ist auch in meinem Interesse

Zitat von nst

Die mit "dddvb"-markierten Branches sind meine ersten Versuche, das dddvb-Package von Digital Devices in seine Bestandteile zu zerlegen (da werd' ich mich nicht mehr weiter drum kümmern). Die "ddbridge"-Branches sind "noch mehr" zerlegte Varianten, aber so aufgesplittet, dass eine Basis ohne nötige API-Änderungen vorhanden ist (*-ddbridge und *-ddbridge-testing, alle üblichen Karten bis auf die MaxS8 unterstützt) und welche auch IMHO am problemlosesten an den Media-Maintainern vorbeikommen könnte. Die ddbridge-feature Branches haben dann Commit für Commit alle API-Änderungen (ein API-Command für die MaxS8 plus notwendigem mxl5xx-Demod, Netstream/OctoNet Support, Modulator-API und DVB-C Resi Modulator Card Support) und vervollständigen das ddbridge-Package auf das, was Digital Devices ausliefert.

Danke für die Erklärung.

Zitat von nst

Rückmeldungen zum -testing-Branch wären mit der Bridge-Karte sehr interessant! Die TDA18212 Tuner-Unterstützung sollte mittlerweile besser funktionieren und im CXD2843-Frontend ist schon ein wenig Kosmetik eingeflossen (alles Dinge, die in der Vergangenheit bereits durch die Media-Maintainer kritisiert wurden). Ausserdem werd' ich mich nochmal näher mit dem STV0367-Ersatz beschäftigen (das ist auch notwendig). Hatte da schonmal rumprobiert aber dann zunächst aufgrund von Mangeln im ddbridge-Modul (Resourcen wurden im Fehlerfall nicht freigegeben und haben dazu geführt, dass das Modul nicht mehr zu entladen war, sollte mittlerweile verbessert sein) abgebrochen.

OK, dann teste ich. Kann ich den Kernel 4.4.5 direkt mit https://github.com/herrnst/ddd…er-ddbridge-testing.patch patchen oder soll ich lieber nach https://github.com/herrnst/ddd…ile-using-media_build.git vorgehen? Dann muß ich nur

git checkout mediatree/master-ddbridge

durch

git checkout mediatree/master-ddbridge-testing

ersetzen, richtig?

Zitat von Tinitus

Mit Kernel 4.4.5 läuft es zwar durch aber

Code

modprobe ddbridge
modprobe: ERROR: could not insert 'ddbridge': Invalid argument

Bei mir hier genau das Selbe:

server02 ~ # modprobe -v  ddbridge
insmod /lib/modules/4.4.5-gentoo/kernel/drivers/media/pci/ddbridge/ddbridge.ko
modprobe: ERROR: could not insert 'ddbridge': Invalid argument
server02 ~ #

Zitat von gentoo-vdr

OK, dann teste ich. Kann ich den Kernel 4.4.5 direkt mit https://github.com/herrnst/ddd…er-ddbridge-testing.patch patchen

Nein, da wirst Du API-Probleme (= Compiler-Fehler) bekommen.

Zitat von gentoo-vdr

oder soll ich lieber nach https://github.com/herrnst/ddd…ile-using-media_build.git vorgehen? Dann muß ich nur

Code

git checkout mediatree/master-ddbridge

durch

Code

git checkout mediatree/master-ddbridge-testing

ersetzen, richtig?

Yep, das klappt so (mein Server läuft ebenfalls auf Gentoo+gentoo-sources-4.4.x, mit Modulen erzeugt durch media_build) - der Branch ist richtig

EDIT:
Nachtrag 1: Backup von /lib/modules/uname -r/ bietet sich an
Nachtrag 2: Danke fürs Testen und Helfen!