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

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


    "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 :rolleyes: Aber auch an diesem Problem (cxd2099 in staging) wird bereits gearbeitet...

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • 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

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • 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.


    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.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

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

    HowTo: APT pinning

  • 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?

    Code
    1. root@omv4:~# uname -a
    2. 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?

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


    c. Was verrät uns dmesg?

    Code
    1. root@omv4:~# dmesg | grep ddbridge
    2. root@omv4:~# dmesg | grep "Digital Devices"
    3. root@omv4:~# dmesg | grep DVB
    4. root@omv4:~# dmesg | grep -i dvb
    5. [ 11.257256] dvb_core: disagrees about version of symbol module_layout
    6. [ 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:


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


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

    Code
    1. root@omv4:~# modprobe ddbridge

    Ok, das sieht gut aus!


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


    Nun noch kurz den VDR starten... Tada, läuft! :wow 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

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • Code
    1. root@omv4:~# modinfo ddbridge
    2. filename: /lib/modules/4.14.0-0.bpo.2-amd64/kernel/drivers/media/pci/ddbridge/ddbridge.ko
    3. version: 0.9.31intermediate-integrated
    4. [....]
    5. 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...

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • 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

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • 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

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Danke für die Info!

    -> Ich las I2C....

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

    [Cine S2 V6.5 + DuoFlex V4] zur Zeit wieder ngene basierte Cine S2 / Apollo-Lake Celeron (Asrock J3355M), ATRIC Einschalter, yaVDR0.61

  • 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.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • 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.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • 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

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 )
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)