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

Zitat von nanohcv

Da freut man sich so auf 4.14, dass man nicht mehr soviel frickeln muss und nun sowas

"kmod-staging" scheint es nicht mehr zu geben bei RPMFusion.

Tja. Gegen die (IMHO äusserst seltsamen, speziell im RPM-Bereich) Launen der Binärdistributoren helfen alle Anstrengungen rund um den Upstream nix Aber auch an diesem Problem (cxd2099 in staging) wird bereits gearbeitet...

Zitat von nst

gestern war offenbar mal wieder "Merge-Day" im media_tree, dabei wurden die ddbridge-0.9.32 Patches mitgemerged. Die Changes werden in Linux-4.16(rc1) landen. Einen wirklichen Grund, darauf zu warten, gibts aber eigentlich nicht, dddvb-0.9.31->0.9.32 war im Tunerkartenbereich nur 'ne Aufräumaktion.

Moinsen,

bin kürzlich mit meinem Openmediavault System auf Debian Stretch (Openmediavault4) umgestiegen. Ich hatte es nun eigentlich so in Erinnerung, dass meine Max S8 ab Kernel 4.14 out-of-the-box läuft. Ist das jetzt noch so?

In den Backports von Debian Stretch gibt es seit gestern nämlich folgende Pakete:

• linux-image-4.14.0-0.bpo.2-amd64 - Linux 4.14 for 64-bit PCs
• linux-headers-4.14.0-0.bpo.2-amd64 - Header files for Linux 4.14.0-0.bpo.2-amd64
• linux-kbuild-4.14 - Kbuild infrastructure for Linux 4.14

Falls das damit nicht funktioniert, wäre ich euch dankbar, wenn mir einer die entsprechenden Befehle kurz aufschlüsseln könnte, um den richtigen Treiber selbst zu bauen.

Folgende Kernel habe ich derzeitig in Stretch zur Auswahl:

• linux-image-4.9.0-5-amd64 - Linux 4.9 for 64-bit PCs
• linux-image-4.13.0-0.bpo.1-amd64 - Linux 4.13 for 64-bit PCs
• linux-image-4.14.0-0.bpo.2-amd64 - Linux 4.14 for 64-bit PCs

Welchen Kernel würdet ihr mir dann für den selbst zu bauenden Kernel empfehlen?

Derzeitig habe ich Kernel 4.9 im Einsatz, da ich auf der gleichen Maschine auch noch ein ZFS betreibe und ich mir unsicher bin, ob das mit den neueren Kerneln schon funktioniert.

Danke euch schonmal und Gruß Hoppel

Zitat von hoppel118

Ich hatte es nun eigentlich so in Erinnerung, dass meine Max S8 ab Kernel 4.14 out-of-the-box läuft. Ist das jetzt noch so?

Yep.

Zitat von hoppel118

In den Backports von Debian Stretch gibt es seit gestern nämlich folgende Pakete:

• linux-image-4.14.0-0.bpo.2-amd64 - Linux 4.14 for 64-bit PCs
• linux-headers-4.14.0-0.bpo.2-amd64 - Header files for Linux 4.14.0-0.bpo.2-amd64
• linux-kbuild-4.14 - Kbuild infrastructure for Linux 4.14

Wenn die Debian-Herrschaften nicht irgendwelchen Unsinn paketieren (ich schreib das ganz bewusst, weil z.B. die RPM/Fedora-Herrschaften keine Staging-Module paketieren und deshalb die CXD2099AR-basierten CI-Flexmodule nicht funktionieren) solltest Du damit glücklich werden.

Naja, was spricht dagegen einfach mal den 4.14er Kernel zu testen ... geht doch nix kaputt ...

So, hatte gerade Zeit mich damit zu beschäftigen. Mein ZFS-Pool und meine Max S8 laufen beide mit Kernel 4.14. Das war gar nicht so schwer.

Ich bin wie folgt vorgegangen:

1. Installation der 4.14 Kernel Pakete aus den Debian Stretch Backports

2. Reboot und booten des neuen Kernels

3. Prüfen, was Sache ist:

a. Welcher Kernel wurde gebootet?

root@omv4:~# uname -a
Linux omv4 4.14.0-0.bpo.2-amd64 #1 SMP Debian 4.14.7-1~bpo9+1 (2017-12-22) x86_64 GNU/Linux

b. Welcher Treiber wurde geladen?

root@omv4:~# modinfo ddbridge
filename:       /lib/modules/4.14.0-0.bpo.2-amd64/updates/dkms/ddbridge.ko
version:        0.9.28
license:        GPL
author:         Ralph and Marcus Metzler, Metzler Brothers Systementwicklung GbR
description:    Digital Devices PCIe Bridge
srcversion:     B7D0071B39C2757EF6A1654
alias:          ...
...
...

c. Was verrät uns dmesg?

root@omv4:~# dmesg | grep ddbridge
root@omv4:~# dmesg | grep "Digital Devices"
root@omv4:~# dmesg | grep DVB
root@omv4:~# dmesg | grep -i dvb
[   11.257256] dvb_core: disagrees about version of symbol module_layout
[   11.257368] dvb_core: disagrees about version of symbol module_layout

Erkenntnis: Der von mir manuell unter Kernel 4.9 installierte Treiber wurde geladen, funktioniert aber nicht mehr.

4. Deinstallation des alten Treibers:

root@omv4:~# apt-get remove --purge dddvb-dkms
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
  dddvb-dkms*
0 aktualisiert, 0 neu installiert, 1 zu entfernen und 3 nicht aktualisiert.
Nach dieser Operation werden 3.479 kB Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n]
(Lese Datenbank ... 109110 Dateien und Verzeichnisse sind derzeit installiert.)
Entfernen von dddvb-dkms (1:0.9.28~v7a.0easyVDR0-trusty) ...

-------- Uninstall Beginning --------
Module:  dddvb
Version: 0.9.28~v7a.0easyVDR0
Kernel:  4.14.0-0.bpo.2-amd64 (x86_64)
-------------------------------------
...
...
...

5. Prüfen, ob nun der Kerneltreiber bekannt ist:

root@omv4:~# modinfo ddbridge
filename:       /lib/modules/4.14.0-0.bpo.2-amd64/kernel/drivers/media/pci/ddbridge/ddbridge.ko
version:        0.9.31intermediate-integrated
license:        GPL
author:         Ralph and Marcus Metzler, Metzler Brothers Systementwicklung GbR
description:    Digital Devices PCIe Bridge
srcversion:     33B8C7F87D036BD792B6A14
alias:          pci:v0000DD01d00000329sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000328sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000323sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000322sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000321sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000320sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000220sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000210sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000203sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000201sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000013sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000012sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000011sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000008sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000007sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000006sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000005sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000003sv0000DD01sd*bc*sc*i*
alias:          pci:v0000DD01d00000002sv0000DD01sd*bc*sc*i*
depends:        dvb-core
intree:         Y
name:           ddbridge
vermagic:       4.14.0-0.bpo.2-amd64 SMP mod_unload modversions
parm:           fmode:frontend emulation mode (int)
parm:           fmode_sat:set frontend emulation mode sat (int)
parm:           old_quattro:old quattro LNB input order  (int)
parm:           adapter_nr:DVB adapter numbers (array of short)
parm:           adapter_alloc:0-one adapter per io, 1-one per tab with io, 2-one per tab, 3-one for all (int)
parm:           msi:Control MSI interrupts: 0-disable (default), 1-enable (int)
parm:           ci_bitrate: Bitrate in KHz for output to CI. (int)
parm:           ts_loop:TS in/out test loop on port ts_loop (int)
parm:           xo2_speed:default transfer speed for xo2 based duoflex, 0=55,1=75,2=90,3=104 MBit/s, default=2, use attribute to change for individual cards (int)
parm:           alt_dma:use alternative DMA buffer handling (int)
parm:           no_init:do not initialize most devices (int)
parm:           stv0910_single:use stv0910 cards as single demods (int)

6. Sicherheitshalber nochmal prüfen, ob der neue Treiber sauber geladen wird:

root@omv4:~# modprobe ddbridge

Ok, das sieht gut aus!

7. Prüfen, ob mit dem neuen Kernel-Treiber alles sauber erkannt wird:

root@omv4:~# dmesg | grep -i dvb
[   11.257256] dvb_core: disagrees about version of symbol module_layout
[   11.257368] dvb_core: disagrees about version of symbol module_layout
[  251.145035] ddbridge 0000:02:00.0: Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-S2 MAX
[  251.145039] ddbridge 0000:02:00.0: Port 1: Link 0, Link Port 1 (TAB 2): DUAL DVB-S2 MAX
[  251.145042] ddbridge 0000:02:00.0: Port 2: Link 0, Link Port 2 (TAB 3): DUAL DVB-S2 MAX
[  251.145044] ddbridge 0000:02:00.0: Port 3: Link 0, Link Port 3 (TAB 4): DUAL DVB-S2 MAX
[  251.145935] dvbdev: DVB: registering new adapter (DDBridge)
[  251.145938] dvbdev: DVB: registering new adapter (DDBridge)
[  251.145939] dvbdev: DVB: registering new adapter (DDBridge)
[  251.145941] dvbdev: DVB: registering new adapter (DDBridge)
[  251.145942] dvbdev: DVB: registering new adapter (DDBridge)
[  251.145944] dvbdev: DVB: registering new adapter (DDBridge)
[  251.145945] dvbdev: DVB: registering new adapter (DDBridge)
[  251.145947] dvbdev: DVB: registering new adapter (DDBridge)
[  257.070704] ddbridge 0000:02:00.0: DVB: registering adapter 0 frontend 0 (MaxLinear MxL5xx DVB-S/S2 tuner-demodulator)...
[  257.126683] ddbridge 0000:02:00.0: DVB: registering adapter 1 frontend 0 (MaxLinear MxL5xx DVB-S/S2 tuner-demodulator)...
[  257.182678] ddbridge 0000:02:00.0: DVB: registering adapter 2 frontend 0 (MaxLinear MxL5xx DVB-S/S2 tuner-demodulator)...
[  257.238677] ddbridge 0000:02:00.0: DVB: registering adapter 3 frontend 0 (MaxLinear MxL5xx DVB-S/S2 tuner-demodulator)...
[  257.239745] ddbridge 0000:02:00.0: DVB: registering adapter 4 frontend 0 (MaxLinear MxL5xx DVB-S/S2 tuner-demodulator)...
[  257.240775] ddbridge 0000:02:00.0: DVB: registering adapter 5 frontend 0 (MaxLinear MxL5xx DVB-S/S2 tuner-demodulator)...
[  257.241721] ddbridge 0000:02:00.0: DVB: registering adapter 6 frontend 0 (MaxLinear MxL5xx DVB-S/S2 tuner-demodulator)...
[  257.242333] ddbridge 0000:02:00.0: DVB: registering adapter 7 frontend 0 (MaxLinear MxL5xx DVB-S/S2 tuner-demodulator)...
root@omv4:~# dmesg | grep "Digital Devices"
[  251.030938] ddbridge: Digital Devices PCIE bridge driver 0.9.31intermediate-integrated, Copyright (C) 2010-17 Digital Devices GmbH
[  251.031496] ddbridge 0000:02:00.0: detected Digital Devices MAX S8 4/8
root@omv4:~# ls /dev/dvb
adapter0  adapter1  adapter2  adapter3  adapter4  adapter5  adapter6  adapter7

Nun noch kurz den VDR starten... Tada, läuft! Während ich mein Handeln hier gerade dokumentiere, schaue ich parallel TV und zappe dabei ein Bisschen hin und her.

Ich halte euch auf dem Laufenden, ob alles läuft oder ob es irgendwo noch Probleme gibt.

Vielen Dank für die ganze Arbeit die Ihr da investiert habt, inbesondere nst .

Gruß Hoppel

Zitat von hoppel118

Code

root@omv4:~# modinfo ddbridge
        filename:       /lib/modules/4.14.0-0.bpo.2-amd64/kernel/drivers/media/pci/ddbridge/ddbridge.ko
        version:        0.9.31intermediate-integrated
        [....]
        depends:        dvb-core

... Das sieht so aus, als würde Debian bzw. die Backports-Herrschaften auch nichts von staging-Modulen halten - die CXD2099-basierten Single-Flex Addons werden damit genausowenig laufen wie mit Fedora...

Hm..., ok, das ist ja bescheiden. Da ich ausschließlich freie Sender mit meiner Max S8 schaue, betrifft mich das nicht.

Danke für die Info, das ist ja sicherlich auch für andere Debian Jessie User interessant.

Bisher läuft alles einwandfrei.

Gruß Hoppel

Nabend zusammen,

da gerade der linux-media Pull Request für Kernel 4.16 gemerged wurde, einfach mal 'ne kurze Zusammenfassung, was mit 4.16 für DD-Kartenuser an Neuerungen kommt (4.15 hat nur kosmetische Code-Cleanups erhalten):

• Noch mehr kosmetische Cleanups und Mini-Fixes in allen DD-relevanten Kernelmodulen (ddbridge, stv0910, stv6111, mxl5xx sowie cxd2099).
• ddbridge Version 0.9.32 (auch wenn der Versionstag eins höher ist, gibts für Tuner- und CI-Karten User funktional nichts neues).
• Die Fehlerbehandlung in ddbridge beim Demod/Tuner-Attach wurde ordentlich verbessert. Egal, zu welcher Zeit der Karten- bzw. Flexmodul-Init in Fehler läuft, hinterlässt ein Fehler jetzt keine Artefakte mehr im Kernel (memleaks, OOPSes usw.) oder geladene Module mit kaputtem Refcount, die sich nicht mehr entladen lassen.
• Weiterhin werden "restliche" funktionierende Tunermodule jetzt in einen funktionsfähigen Zustand initialisiert und können verwendet werden. ddbridge meldet erst dann eine fehlgeschlagene Initialisierung an die Kernel-Subsysteme zurück, wenn wirklich gar nichts initialisiert werden konnte. Teilweise fehlgeschlagene Initialisierungen werden entsprechend als Warning im Kernel Log dokumentiert.
• Im stv0910/stv6111 Demod/Tuner-Stack (CineS2 V7 und DuoFlex S2 V4) wurde ein potentielles Deadlocking-Problem gefixt, welches durch fehlgeschlagene I2C-Transfers während des Tuner-Zugriffs ausgelöst werden konnte.
• Das DVB Subsystem kann jetzt mit DVB-S2(X) "Physical Layer Scrambling" umgehen. Der STV0910-Treiber hat diesbzgl. Unterstützung erhalten (der STV090x-Treiber - CineS2 V6.5 und ältere S2 Flex - hat diese von anderer Steller erhalten).

Für 4.17 derzeit queued (hätte eigentlich auch in 4.16 landen sollen, wurde aus unerfindlichen Gründen aber nicht merged):

• Mehr Support (enums/Konstanten) für DVB-S2X wie neue Modulationsverfahren (APSK32+) u.a.
• Physical Layer Scrambling Support für den mxl5xx (MaxS8 4/8).
• (noch nicht gepostet) Ein Fix für die MiniDiSEqC Burst Übertragung im stv0910.

Viele Grüße,

nst

Danke für die Info!

-> Ich las I2C....

Könnte das die I2C Timeout Problematik auf Asrock Boards fixen??

Zitat von Grillbert

Könnte das die I2C Timeout Problematik auf Asrock Boards fixen??

Nein (das ist ein Problem zwischen Board und Karte bzw. dessen FPGA und nach aktuellem Kenntnisstand nicht per Treiberupdate fixbar), aber das System läuft nicht mehr in Gefahr, im Kernel zu deadlocken, wenn sich Karte und PCIe-Bus voneinander verabschieden.

Hallo,

evtl kann mir jemand fuer den debug einen Tip geben:

[ 729.084462] ddbridge: Digital Devices PCIE bridge driver 0.9.31intermediate-integrated, Copyright (C) 2010-17 Digital Devices GmbH

[ 729.085335] ddbridge 0000:02:00.0: detected Digital Devices DVBCT V6.1 DVB adapter

[ 729.085359] ddbridge 0000:02:00.0: HW 0001000d REGMAP 00010004

[ 729.085635] ddbridge 0000:02:00.0: Port 0: Link 0, Link Port 0 (TAB 1): NO MODULE

[ 729.086655] ddbridge 0000:02:00.0: Port 1: Link 0, Link Port 1 (TAB 2): NO MODULE

[ 729.087879] ddbridge 0000:02:00.0: Port 2: Link 0, Link Port 2 (TAB 3): NO MODULE

zZ laufe ich mit kernel: 4.14.0-0.bpo.3-amd64 #1 SMP Debian 4.14.13-1~bpo9+1

Das ganze lief schon mal mit frueheren kerneln und dem media-tree.

Die HW sollte also tun.

Gruesse

Ah, die CTv6 und "NO MODULE" auf Port 0. Wenn Dir "modinfo stv0367" und "modinfo tda18212" was sinnvolles anzeigt: Power-Off, Power-Kabel ab (oder Kippschalter am Netzteil auf "aus"), 20 Sek. warten (bis sich die Kondensatoren entladen haben), dann alles wieder an. Wenn die Karte keine Macke hat, läuft dann alles.

Excellent, laeuft nach dem Ausschalten!

Danke

Nabend zusammen,

da gerade sowas wie der "merge day" auf linux-media stattgefunden hat, hier mal die für ddbridge (und ngene) relevanten Dinge, die in Kernel 4.17 landen werden:

• Der cxd2099 Treiber (Flex CI Single Support) ist jetzt ein "sauberer" I2C Client Treiber, der obendrein die Regmap API verwendet - dadurch fallen die eigenen i2c_*() Funktionen komplett weg und es kommt Standard Kernel API zum Einsatz.
• cxd2099: Der Treiber ist aus staging/ jetzt zu den "stabilen" Frontends in dvb-frontends/ eingezogen. nanohcv und hoppel118 bzw. mindestens alle Debian und Fedora User bekommen den Treiber daher jetzt auch in den regulären Kernel Images mit
• Physical Layer Scrambling Support für den mxl5xx (MaxS8 4/8).
• Die MiniDiSEqC Burst Übertragung im stv0910 ist repariert.
• ngene: Der Treiber wurde generell an diversen Stellen etwas angehübscht (u.a. anständiges Kernel Logging).
• ngene: Der Treiber erkennt und unterstützt jetzt so ziemlich jede aktuelle DD DuoFlex Erweiterung, inkl. DuoFlex CT (stv0367-basiert), C(2)T2(I) (cxd2841er-basiert) und die DuoFlex S2 V4 (!) (letzteres ungetestet). Die Addons wurden an einer CineS2 v5.5 getestet. Ein Test an den alten DuoFlex PCIe (2-Port) vor allem am ersten Port steht noch aus, mehr als andere I2C Adressen für die Demods dürften aber nicht erforderlich sein (trivialer Patch). Unterstützung für die aktuellen DuoFlex CI wäre auch machbar, erfordert aber viel Codeduplizierung aus ddbridge und es ist nur einer von den CI Slots nutzbar, daher ist das NICHT implementiert.
• ngene: Das CI TS Buffer Offset Shift Problem hat einen Workaround erhalten. Die Buffer werden jetzt im Treiber dauerhaft auf TS SYNC Bytes geprüft und bei Bedarf Richtung DVB Core / Userspace neu ausgerichtet, wenn durch CAM Inits Verschiebungen stattfinden.
• ngene: Der DDCI-Support funktioniert jetzt auch mit TVheadend (jaja, das hier ist ein VDR-Forum...). TVH ist etwas penibler, was das Abholen von Daten vom CAM angeht (ts_poll). Das fehlte in ngene komplett und wurde jetzt nachgerüstet.

Die S2X Konstanten sollen laut den Maintainern mit einer Erweiterung der DVB Core API einhergehen und wurden daher zunächst nicht gemerged.

Ich push' die Tage noch 1-2 kleinere Fixups Richtung linux-media (nur kosmetische Dinge), und dann warten wir mal, was als nächstes so kommt.

Viel Spass damit,

nst

Das 4.18er Merge Window steht vor der Tür, für DD-Karten gibts eigentlich nur einen wirklich spannenden Change:

• ddbridge 0.9.33, inkl. initialem Support für die neuen MaxSX8 Karten

Anders als in dddvb-0.9.33 aus dem DD GitHub Repository ist es allerdings nicht zwingend erforderlich, die FPGA-Firmware der CineS2V7/OctopusCIS2 Karten umzuflashen. Der Treiber erkennt, wenn nicht die aktuellste v1.7 im FPGA vorhanden ist und aktiviert dann die High-Bandwidth-Transponder-Unterstützung im stv0910-Demod-Treiber nicht und die Karten laufen wie gehabt. Erst wenn die Karte die passende Firmware enthält, wird die Unterstützung aktiviert bzw. der Demod entsprechend anders konfiguriert.

Apropos FPGA-Firmware: Das Update-Thema wird für das 4.19er Window noch mal verstärkt beackert, damit das endlich auch mit dem Kernel-Treiber funktioniert.

Zitat von nst

Apropos FPGA-Firmware: Das Update-Thema wird für das 4.19er Window noch mal verstärkt beackert, damit das endlich auch mit dem Kernel-Treiber funktioniert.

Na das finde ich aber super!

Dann gibt es keinen Grund mehr die Treiber aus den DD Repo zu verwenden.

Was machen wir mit den Flash Tools?

Kommen die auch in den Kernel Tree?

LG,

Jasmin

Zitat von jasminj

Was machen wir mit den Flash Tools? Kommen die auch in den Kernel Tree?

Nö.

Aha, dann muss man die also weiterhin aus dem DD Repo nehmen.

Ich hoffe die ioctl Codes im Kernel und im DD Tree sind dann gleich.

Echt cool, was du/ihr hier vollbracht hast/habt.

Zitat von jasminj

Ich hoffe die ioctl Codes im Kernel und im DD Tree sind dann gleich.

Ja, bald.