Skystar 2 lässt sich nicht aktivieren

Ich habe mein zweites Mediaportal mit einer TT Full featured Rev 1.6. und als Zweitkarte einer Skystar 2 Budget.
Über die FF funktioniert alles.
Leider funktioniert die zweite Karte nicht. Probleme an der SAT-Leitung scheiden aus, bereits getestet.

lspci gibt aus:
00:00.0 Host bridge: Intel Corporation 82810 GMCH (Graphics Memory Controller Hub) (rev 03)
00:01.0 VGA compatible controller: Intel Corporation 82810 (CGC) Chipset Graphics Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02)
00:1f.2 USB Controller: Intel Corporation 82801AA USB Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02)
01:04.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
01:05.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
01:07.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 07)
01:08.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74)

Die Karte wird also erkannt!

dmesg ergibt:

b2c2-flexcop: B2C2 FlexcopII/II(B)/III digital TV receiver chip loaded successfully
flexcop-pci: will use the HW PID filter.
flexcop-pci: card revision 2
ACPI: PCI Interrupt 0000:01:05.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
DVB: registering new adapter (FlexCop Digital TV device)
b2c2-flexcop: MAC address = 00:08:c9:a1:1d:02
b2c2-flexcop: i2c master_xfer failed
b2c2-flexcop: i2c master_xfer failed
b2c2-flexcop: i2c master_xfer failed
mt352_read_register: readreg error (reg=127, ret==-121)
b2c2-flexcop: i2c master_xfer failed
nxt200x: nxt200x_readbytes: i2c read error (addr 0x0a, err == -121)
Unknown/Unsupported NXT chip: 00 00 00 00 00
b2c2-flexcop: i2c master_xfer failed
lgdt330x: i2c_read_demod_bytes: addr 0x59 select 0x02 error (ret == -121)
b2c2-flexcop: i2c master_xfer failed
b2c2-flexcop: i2c master_xfer failed
stv0297_readreg: readreg error (reg == 0x80, ret == -121)
b2c2-flexcop: i2c master_xfer failed
mt312_read: ret == -121
b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter
ACPI: PCI interrupt for device 0000:01:05.0 disabled


Da es hier offensichtlich einige Fehler gibt, bin ich mir nicht sicher, was ich hier weiter machen soll.

Helaus Scripts dvb_update.sh habe ich durchlaufen lassen.

vdr ~ # /_config/bin/dvb_update.sh

These are the packages that would be merged, in order:

Calculating dependencies |
!!! All ebuilds that could satisfy "v4l-dvb-hg" have been masked.
!!! One of the following masked packages is required to complete your request:
- media-tv/v4l-dvb-hg-0.1-r2 (masked by: ~x86 keyword)

For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.

* WARNING: you are stopping a boot service.
* Stopping vdradmin-am ... [ ok ]
* Stopping vdr ...
Shutting down VDR
Waiting for vdr termination ... [ ok ]
Removing dvb-ttpci
Removing b2c2-flexcop-pci
DVB module: b2c2-flexcop-pci
DVB module: dvb-ttpci
* Starting vdr ...
root: Starting <openvt -c 8 -f -- /etc/vdr/runvdr>
root: /_config/bin/switch_console.sh <-vdr><> init
root: /_config/bin/switch_console.sh <-vdr><> VDR
Switching to VDR
VDR ist nicht gestartet [ ok ]
vdr ~ #


These are the packages that would be merged, in order:

Calculating dependencies

Exiting on signal 2

* WARNING: you are stopping a boot service.
* Stopping vdr ...
Shutting down VDR
Waiting for vdr termination ... [ ok ]
Removing dvb-ttpci
Removing b2c2-flexcop-pci
DVB module: b2c2-flexcop-pci
DVB module: dvb-ttpci
* Starting vdr ...
root: Starting <openvt -c 8 -f -- /etc/vdr/runvdr>
root: /_config/bin/switch_console.sh <-vdr><> init
root: /_config/bin/switch_console.sh <-vdr><> VDR
Switching to VDR
VDR ist nicht gestartet [ ok ]
vdr dvb #

Da scheint etwas mit v4l faul zu sein!!! Was muß ich machen ?


Beim Systemstart wird das Modul b2c2-flexcop-pci offensichtlich geladen.


vdr ~ # modprobe b2c2-flexcop
vdr ~ #
scheint so in Ordnung zu sein.


Wer kann mir bitte helfen, was hier falsch läuft.
Ich bin leider mit meinem Latein am Ende.

Hallo,
das Hauptproblem ist hier zu finden.

Bei meiner Cablestar2 ist es mit aktuellen Treiber von "v4l-dvb-hg" das selbe.
Ein funktionierender Treiber ist, in meinem Fall, nur ein älterer.

Für einen Versuch mit aktuellen Treiber.

Geht das nicht, kann ich dir schreiben, wie du einen älteren Treiber installierst.

bis dann,
Nando

Vielen Dank schon jetzt für die schnelle Antwort.

Ich habe das jetzt durchlaufen lassen.
Leider bleibt es bei der Ausgabe von DMESG

b2c2-flexcop: i2c master_xfer failed
mt312_read: ret == -121
b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter


Ich müsste also eventuell dann den alten Treiber installieren.
Ich wäre sehr dankbar, wenn du mir mitteilen kannst, wie das läuft.

Ok, na dann ...

neuen Treiber entfernen

alten Treiber installieren

/_config/bin/dvbmod edtieren (in zwei Zeilen find /lib/modules...)

Welche SkyStar hast Du denn ? Die 2.8er ist wohl noch gar nicht unterstuetzt.

Ich habe diese Karte:

http://cgi.ebay.de/ws/eBayISAPI.dll?ViewIt...:B:EOIBSA:DE:31

Das scheint dann wohl die aktuelle 2.7 oder 2.8 zu sein.

Da habe ich dann wohl jetzt ein ernstes Problem.

Im vdr-wiki steht ein Treiber für 2.7er.
http://linuxtv.org/hg/~pb/v4l-dvb/archive/...295453b.tar.bz2

Hallo,
für die Revision 2.7 gibt es seit längerem direkte Kernelunterstützung - man braucht keinen v4l-tree zusätzlich.

Im Anhang gibt es einen proprietären Treiber mitsamt Beschreibung für die seit Februar 2008 nur mehr erhältliche Revision 2.8.

Viel Spass!

sinter


angehängte Datei ( Anzahl der Downloads: 328 )
 skystar2_rev2.8.tar.bz2

Hallo sinter,
willkommen im Forum. :)

Danke für deinen Beitrag.

Die Revisionen (für Kabel/Satelit) sind eigenständig zu sehen, oder?
Zu Kabel:
http://linuxtv.org/pipermail/linux-dvb/2008-June/026512.html
http://linuxtv.org/pipermail/linux-dvb/200...ust/028098.html


bis dann,
Nando

Hallo Nando,
was hier eigenständig zu sehen ist und was nicht, kann ich so aus dem Stegreif nicht beantworten, weil Deine Frage mich zunächst mal vollständig verwirrt, auch aufgrund der Links.
Als mir neulich meine Pinnacle PCTVSAT wieder einmal wegen des verflixten Relais zu Bruch ging, holte ich mir wieder eine DVB-S-Karte: Technisat Skystar DVB-S. Den Revisionswirrwarr nahm ich erst später zur Kenntnis, weil die Anleitung zur Einbindung des proprietären Tuner-Moduls mehr als oberflächlich war und ist.
Also setzte ich mich hin, und recherchierte stundenlang.
Heraus kam eine Mini-Doku, welche die Revisionen 01 (aka 2.7) und 02 (aka 2.8) abdeckt, und sich gleichzeitig auf folgende Typen beschränkt:
1. nur DVB-S Geräte.
2. PCI-Karte oder USB-1.1-Kästchen.
Dass die verschiedenen Typen der Technisat Skystar auch noch mehr als DVB-S können, sieht man an den Zwangsanbindungen bei der Kernelkompilierung, wenn man, entgegen meiner Gewohnheit, den Schalter "Customize Frontend modules to build" weglässt.

Das Pech bei diesem Procedere ist dann nut, dass Du dann gut raten musst, welches Frontend / welche Revision es denn sein könnte.
Ferner produzierst Du auch auf diese Weise unheimlich viel speicherfressenden Müll, den Du nicht brauchst.
Schlau wäre es, mittels dieses Forums hinreichend Daten zu sammeln darüber, welches Frontend- respektive Tuner-Modul denn nun zu welchem Kartentypus passt.
Dann könnte ich den Teil meiner Doku, welcher sich mit Kernelkompilation befasst, optimieren, und dann könnten mit einem Schlag sämtliche Klarheiten beseitigt werden.
Hilfreich hierbei: lspci -vvv bzw. lsusb -vvv
Vielleicht kriegen wir dann das Revisionschaos geregelt, und ermöglichen es so den Leuten, sich optimale Kernel zu bauen. Dann hört dieses ewige Spekulieren und Kaffeesatzlesen endlich auf, das mir höllisch auf die Nerven geht, denn dann reden wir über Fakten.

Du bist jedenfalls der erste, der sich anerkennend äussert. Von der Technisat Company wie von der v4l community kommt nur beredtes Schweigen, was tief blicken lässt: In einem Fall ist es wohl Ignoranz, im anderen einfach nur Faulheit.
Nichts destotrotz handelt es sich um eine technisch hochwertige Karte mit wirklich guten Treibern für Linux.....
Die Treiberarchitektur ist deshalb so gut, weil der ganze Hybridschnickschnack (Analog-Ports etc.) einfach wegfällt, und die Karte "rein" ist.
Das war für mich entscheidendes Kaufkriterium nach dem zweimaligen Reinfall mit der Pinnacle PCTVSAT.

Salut

sinter

Es gilt also, eine Doku zu schreiben, die den Kartentyp richtig benennt und gleichzeitig eine korrekte Frontend-Modul-Zuweisung vornimmt.
Das kann ich nicht ganz alleine und dazu brauch ich Hilfe von Usern, die diese ganze Bandbreite von Karten ihr Eigen nennen.....

Kennst du die Sammlung der DVB device Daten von HelAu im VDRPortal?
Hilft das weiter? Die Nutzergruppen/Ansprechpartner im Portal sind auch etwas größer. ;)

Hallo Netz,
habe mir die Sammlung angesehen. Danke! Hilft _bedingt_ weiter.

Hier ein Fehler, den ich sofort gesehen hatte:
Pinnacle PCTV SAT
bttv Vendor: 109e Device: 036e SubV: ffff SubV: ffff
bttv Vendor: 109e Device: 036e SubV: ffff SubV: ffff

Das ist absoluter Crap!

Es MUSS heissen:

Pinnacle PCTV SAT
bttv Vendor: 109e Device: 036e SubV: ffff SubV: ffff
bt878 Vendor: 109e Device: 0878 SubV: ffff SubV: ffff

109e steht hier für den eigentlichen Produzent - die Karte ist ein TwinHan clone.
036e steht für den Audio-Controller Part, über den die RISC ENGINE und der ganze DVB-Teil abgewickelt wird.
0878 steht für den Videocontroller Part, über den hauptsächlich der analoge Teil der Karte abgewickelt wird, und über den mittels bttv Treiber die Adressierung der GPIO pins vorgenommen wird.

Was ich gelernt habe:
Frontends (Tuner) sind wie Oberhemden: Gestern dealt Technisat mit Samsung, zur Zeit offenbar mit Conexant, die bei der Freigabe des cx24113 codes als GPL dicke Arme machen, und stattdessen ein proprietär vorkompiliertes Modul mitliefern.

Wenn das Frontend gewechselt wird, schlägt sich das wiederum nicht in der Firmware-Revision nieder.

Wäre es möglich, ein Skript zu zaubern, das das Frontend (den Tuner) ausliest?

Die Datensammlung von euch, die ich jetzt gleich bereichern werde, ist insofern gut, als dass man rausfinden kann, welche Karte welche ist.

Wenn die Leute aber nicht die Frontend Module, die sie per lsmod ermitteln können, mitliefern, ist das weitestgehend verlorene Liebesmüh, weil sie sich dann um das eigentliche Problem herumdrücken:
die korrekte und einwandfreie Zuweisung des Frontends.

Den Beitrag fand ich gut:
Skystar 2.6d

0000:01:0a.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
Subsystem: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card
Flags: bus master, slow devsel, latency 32, IRQ 9
Memory at e9000000 (32-bit, non-prefetchable)
I/O ports at a400 [size=32]

und hernach folgt eine Auflistung von lsmod. Wenn das ganze irgendwie einen Sinn machen soll, dann nur in dieser Kombination.

Salut

sinter

Das wäre bei mir ...
lspci -v -s 01:08.0

Aber wie lese ich am besten das frontend aus? :unsure:

dmesg | grep frontend

Hallo Netz , Mod,

Gut gemacht!

Nur hast Du mit dmesg | grep frontend nur einen Teil des Ganzen ermittelt.
Die Richtung stimmt jedoch schon mal!

Bei mir zeigt er z. B. folgendes:
DVB: registering frontend 0 (Conexant CX24123/CX24109)...

Ich habe aber als Frontend Module _3_ an der Zahl:
a. cx24113, der RF-Downkonverter ( Tuner)
b. cx24123/cx24109, als Frontend (Demodulator)

UND:
c. isl6421 für die Ansteuerung des LNBs und ev. DisecQ

Durch Weglassen des Schalters "Customize frontend modules to build" kannst Du, wenn Du weisst, dass das ein DVB-C Teil ist (was sehr hilfreich ist), nachgucken, welche Module er im Bereich DVB-C sonst noch so an sich bindet (falls überhaupt)

Sowohl bei der Revision 2.7 wie auch bei der Revision 2.8 sind es im Falle einer DVB-S Karte immer DREI Module aus dem Frontend-Bereich.

Ich kenne mich mit DVB-C überhaupt nicht aus. Aber Du solltest durch Ein- und Ausschalten des Customize-Schalters nachschauen, was sich ändert.

Bei DVB-C wirst Du wahrscheinlich keinen Sec-Controller brauchen, da kein LNB da ist.
Und da bei DVB-C der Tuner ja vorgefertigte Bouquets verarbeitet, nehme ich auch nicht an, dass ein zweites Frontend Modul vonnöten ist.

Und wie man ausser durch Lesen der Treiber-CD die korrekte Revision der Firmware herausbekommt - da bin ich ehrlich gesagt total überfragt.

Zu überprüfen wäre ferner noch, ob der i2c-bus-Teil Deines Tuners noch ein Pll-Modul braucht.

Das wärs dann soweit mein bisheriges Latein reicht:
Der Frontend-Teil ist und bleibt eine Rumprobiererei. Und die korrekte Datensammlung vom vdr-portal könnte sehr hilfreich sein, wenn man sie richtig betreiben würde, anstatt einseitig nur auf dieses modifizierte Shellscript zu setzen, das für sich genommen viel zu wenig aussagt.
Die meiste Plackerei (das / die korrekte / n Frontends) werden nämlich durch das Skript überhaupt nicht ermittelt.

Salut

Uwe

Hallo Netz, hallo HelAu,

Zitat: "Kennst du die Sammlung der DVB device Daten von HelAu im VDRPortal?"

Ich habe mir die Arbeit gemacht, die ganze Liste durchzuarbeiten, und komme zu dem Schluss, dass ich sie schlichtweg furchtbar finde.

Gründe:

1. Viele Angaben sind entweder oberflächlich, unvollständig, oder sachlich auch falsch.
2. So gut wie alle Leute kreuzen bei der Kernelkompilation alles an, und machen aus Unwissenheit von Schaltern wie "Customize frontend modules to build" keinen Gebrauch. Oder sie fahren das System mit einem "Shipped" Kernel, bei dem auch alles aktiviert ist.
3. Das Wissen darum, welche Karte nun speziell welche Module braucht, scheint dazu verdammt zu sein, Sache einiger weniger Spezialisten und Freaks zu sein, was ich ziemlich absurd finde. Man hat an verantwortlicher Stelle offensichtlich auch kein Interesse daran, solche Sachen ordentlich zu dokumentieren. Das Endprodukt ist dann ein völlig sinnlos zugemüllter Arbeitsspeicher.
4. Das Produkt dieser also durchaus hausgemachten Unwissenheit sind dann endlos lang wirkende lsmod-Auflistungen, mit denen eine konkrete Zuordnung, was denn nun wirklich für welches Gerät notwendig ist und was nicht, schlichtweg unmöglich erscheint.
Beispiel: Keine Technisat-Karte dieser Welt braucht sechs oder mehr Frontend Module, um zu funktionieren. Guckt man sich die Listen an, wird aber genau das suggeriert. Völlig bescheuert!
Daraus wiederum folgt, dass die Angaben unbrauchbar sind, und der Anspruch, eine gute insmod.sh erstellen zu wollen (wofür im Zeitalter von udev, frage ich mich überdies?) ad Absurdum geführt wird.

Wegen des freien Teils des Technisat 2.8 patchsets warte ich noch auf Antwort von Andrew Morton.
Dann werde ich ein revidiertes Treiberpaket mitsamt TRENNSCHARFER Anleitung hier rein stellen.

Salut

Uwe

P. S.: Ich bin noch immer der Meinung, dass eine wirklich gute Dokumentation einem eine Menge Ärger erspart. Viele Entwickler sehen das offenbar nicht so.

Hallo Uwe,
ich habe zu wenig Ahnung, um da mitreden zu können.

Aber:
Wie soll es, mit der Voraussetzung auf mehrere Hardwaresystemen einsetzbar zu sein, bei einer Distribution anders funktionieren?
Bei Hardwaretreibern wie Lirc und DVB müssen doch mehrere Module (für unterschiedliche Systeme) übersetzt werden.

bis dann,
Nando

Hallo Netz,

ich finde es gut, dass wir diese Diskussion führen, denn dadurch klären sich Missverständnisse.

Zitat 1: "Wie soll es, mit der Voraussetzung auf mehrere Hardwaresystemen einsetzbar zu sein, bei einer Distribution anders funktionieren?"

Das stimmt soweit, völlig korrekt: Von einem Distro-Kernel einer x-beliebigen Distro wird erwartet, dass er absolut ALLES auf Anhieb kann (was natürlich nicht immer funktioniert, aber meistens). Und da es auf der Welt nicht nur i386-Architekturen gibt, werden (nicht nur) auf Kernelebene verschiedene Varianten verschickt, die für die jeweilige Architektur angepasst sind (z. B. AMD 64-bit oder die ganze Motorola-Baureihe m68k, um nur zwei zu nennen).

Ich meinte aber etwas ganz anderes:
Bezogen auf die jeweilige Architektur einen Kernel zusätzlich selbst zu bauen, bei dem Zusammenbau (Kompilation) absolut alles über Bord geworfen wird, was nicht benötigt wird.
Der ist dann z. B. bei mir erheblich kleiner als der Distro-Kernel (knapp über 1MB gross), und mein Verzeichnis /lib/modules ist nicht so überfüllt.

Zitat 2: "Bei Hardwaretreibern wie Lirc und DVB müssen doch mehrere Module (für unterschiedliche Systeme) übersetzt werden."

Das stimmt nur zum Teil.

Bei Lirc hängt es davon ab, welche Art von Remote Control du hast:
1. Wenn sie am seriellen Port hängt, brauchst Du in der Regel kein separates Modul, eben nur Unterstützung für den seriellen Port.
2. Hängt sie an einem USB-Dongle, brauchst Du mindestens ein USB-Submodul neben dem USB Hauptmodul, damit sie läuft.
3. Und dann gibt es noch Urgesteine wie z. B. ir-kbd, die bis heute mit dem bttv mitkompiliert werden, obwohl sie z. B. kein Mensch braucht.

Selbstverständlich sind es im Einzelfall immer ein Modul bis mehrere Module, aber die Liste ist halt nicht endlos, sondern die Zahl der tatsächlich notwendigen Module ist eben im Falle von DVB begrenzt.

Und die genaue Zuordnung, was genau welche Karte wirklich braucht und was nicht, ist es, was ich versuchte, unter Trennschärfe zu definieren.

In meinem Beispiel im vdr-Portal zur Bereicherung der DVB Datensammlung bin ich offenbar der einzige, der versucht hat, das genau umzusetzen:
Du wirst dort lesen, dass dass die Technisat Skystar 2 PCI DVB-S, Revision 2.8 exakt 6 Modules benötigt, um einwandfrei zu arbeiten.
Würdest Du jetzt in der gleichen Maschine noch irgendeine Technotrend Karte einbauen, kämen maximal vielleicht noch 3 Module hinzu, vielleicht auch 4, aber mehr garantiert nicht.

Hier Überschaubarkeit und Transparenz zu erschaffen, das wäre das zu verfolgende Ziel, damit diese lsmod-Endlosschlangen ein Ende haben, die für sich alles sagen, aber gleichzeitig auch rein gar nichts!

Salut

Uwe

P. S.: Ich fahre meine Systeme immer mit zwei Kernels:
1. Der Distrokernel (in der Regel der letzte, der von Debian Sid geliefert wird - das ist 2.6.26 derzeit)
2. Der optimierte Kernel, der nur Funktionen enthält, die ich wirklch brauche - alles andere wandert nach /dev/null im Qi-Gong-Stil.

Hallo Uwe,
da werden wohl zu wenige viel Sinn drinnen sehen. Es wird großteils der einfachste Weg gegangen.

Kennst du andere Möglichkeiten die benötigten Module einzugrenzen, oder ist es aus deiner Kenntnis heraus?

bis dann,
Nando

Salut Nando,

Zitat: "da werden wohl zu wenige viel Sinn drinnen sehen."

Kann man so machen! Nur treib ich dann den Teufel mit dem Beelzebub aus, wenn ich mich gegen Windows und für Linux entscheide.
Das Stichwort lautet: ressourcenschonendes Betriebssystem statt zugemülltes vollgepacktes grafisches Nichts.
LInux bietet so viele Möglichkeiten, die man nicht verschenken sollte, weil Wissenserwerb was mit Arbeit zu tun hat.

Zitat:
"Kennst du andere Möglichkeiten die benötigten Module einzugrenzen, oder ist es aus deiner Kenntnis heraus?"

Ein optimierter Kernel entsteht immer aus einem Gemisch von Erfahrung und Produktkenntnis unter Zuhilfenahme von Bordmitteln. Man muss sich - wie in alles - reinarbeiten.

Salut

Uwe