hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
alexxied schrieb: Ist eigentlich bekannt ob jemand dieses Gerät überhaupt mal funktionierend hat unter Linux?
Meines Wissens ist der einzige Bericht, dass es funktionieren soll, von hier 🇬🇧. Leider besitze ich diese Box nicht. Bei anderen Geräten lässt ein fehlerhafter Sendersuchlauf oft auf eine falsche Firmware-Version schließen. Die verwendeten Firmwaredateien von hier müssten auch im Windows-Treiber von hier genauso vorhanden sein, da ja das Prinzip mit dem Nachladen der Firmware betriebssystemunabhängig ist. Leider liegen die Firmwaredateien im Windowstreiber oft nicht als Einzeldatei vor, sondern können auch z.B.: nur ein Teil einer .sys-Datei sein. Ist die Datei unter Windows als 32-Bit und 64-Bit-Version vorhanden, muss sich die Firmware, in dem Teil befinden, der bei beiden Versionen ident ist. Die Firmware läuft ja direkt am Gerät und nicht am PC. Trotzdem ist es schwierig den richtigen Teil (genauer Beginn, Länge) für Ubuntu herauszukopieren. Vorallem, wenn die Firmware zu bestehenden Firmwaredateien von hier abweicht und vielleicht auch noch verschiedene Firmwareversionen für verschiedene Geräte in einer einzigen .sys-Datei zusammengepackt wurden.
|
mczak
Anmeldungsdatum: 2. November 2013
Beiträge: Zähle...
|
Habe auch so eine Karte und wollte schon aufgeben...
Aber es funktioniert doch, es liegt tatsächlich an der Firmware.
Der Trick ist dass man die Firmware des drx-k gar nicht benötigt, die im eeprom funktioniert bestens (jedenfalls bei mir - keine Ahnung ob da alle ausgelieferten Geräte identisch sind).
Also ganz einfach die "dvb-usb-terratec-h7-drxk.fw" Datei wegwerfen (oder verschieben) so dass sie nicht geladen werden kann dann funktioniert es (aber nicht "dvb-usb-terratec-h7-az6007.fw" die braucht man definitiv). Gut das ist nicht so eine feine Methode aber egal...
(der Hint dass es so gehen könnte kam übrigens von der LinuxTV.org Seite, da sieht man nämlich dass der Treiber die az6007.fw lädt aber eben die drxk.fw nicht laden kann...) Ich habe allerdings den Patch etwas modifiziert (ist rein stylistisch), mein Eintrag sieht so aus:
{DVB_USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_CABLESTAR_HDCI,
&az6007_props, "Technisat CableStar Combo HD CI", RC_MAP_EMPTY)}, Denn es ist nicht korrekt das einfach als HDCI_V3 zu bezeichnen sind doch die V1/V2 Varianten _SkyStar_ HDCI (mit az6027 Chip). Auch die FB funktioniert so wie ich das sehe eh nicht, da meint man dann nur es müsste ja gehen wenn man einen richtigen Eintrag nimmt (es wird allerdings trotzdem eine FB registriert).
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
mczak schrieb: Der Trick ist dass man die Firmware des drx-k gar nicht benötigt, die im eeprom funktioniert bestens
👍 (der Hint dass es so gehen könnte kam übrigens von der LinuxTV.org Seite, da sieht man nämlich dass der Treiber die az6007.fw lädt aber eben die drxk.fw nicht laden kann...)
Ja, leider kam von da auch der Tipp mit der Firmware, mit der es nicht ❗ funktioniert: Firmware dvb-usb-terratec-h7-drxk.fw from http://linuxtv.org/downloads/firmware/
...und das habe ich dann auch in meine Anleitung übernommen 😕
|
mczak
Anmeldungsdatum: 2. November 2013
Beiträge: 7
|
hakunamatata schrieb: mczak schrieb: Der Trick ist dass man die Firmware des drx-k gar nicht benötigt, die im eeprom funktioniert bestens
👍 (der Hint dass es so gehen könnte kam übrigens von der LinuxTV.org Seite, da sieht man nämlich dass der Treiber die az6007.fw lädt aber eben die drxk.fw nicht laden kann...)
Ja, leider kam von da auch der Tipp mit der Firmware, mit der es nicht ❗ funktioniert: Firmware dvb-usb-terratec-h7-drxk.fw from http://linuxtv.org/downloads/firmware/
...und das habe ich dann auch in meine Anleitung übernommen 😕
Ich werde mal versuchen einen upstream-tauglichen Patch hinzubekommen ist ja keine tolle Lösung dass man das selber kompilieren muss...
Die Firmware-Situation ist übrigens interessant, ich habe versucht die manuell aus dem Windows-Treiber zu extrahieren. Hat letztendlich auch funktioniert, die war aber letztlich bit-identisch zur "dvb-demod-drxk-pctv.fw".
Der az6007 Treiber weigert sich allerdings die zu laden, da die einzelnen Blöcke zu gross sind (der Treiber reklamiert wenn die write Blocklänge über 64 Bytes ist).
Ich habe auch andere drxk Firmwares etwas analysiert (mit ein bisschen c code direkt aus dem drxk firmware loader des Kernels extrahiert), und ich vermute die "dvb-usb-terratec-h5-drxk.fw" bzw. "dvb-usb-terratec-htc-stick-drxk.fw" (die beiden sind wiederum bit-identisch) ist auch dasselbe, ausser dass die eben schon manuell in kleinere Blöcke aufgeteilt wurde und somit auch vom az6007 Treiber geladen werden kann. Die manuell extrahierte ist 42692 Bytes gross mit insgesamt 34 Blöcken, die h5-drxk hingegen hat 50222 Bytes aber in 787 Blöcken - jeder zusätzliche Block verursacht 10 mehr Bytes ohne dass sich am Inhalt was ändert, das würde also perfekt passen. Ist aber natürlich kein Beweis bin aber zu faul da jetzt Code zu schreiben um die Firmware komplett zu transformieren, ich habe sie jedenfalls geladen und sie funktioniert auch. Wer also unbedingt eine firmware laden will kann das tun...
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
Ich werde mal versuchen einen upstream-tauglichen Patch hinzubekommen ist ja keine tolle Lösung dass man das selber kompilieren muss...
Das macht auf jeden Fall Sinn. 👍 Die Firmware-Situation ist übrigens interessant [..] Wer also unbedingt eine firmware laden will kann das tun...
Wirklich sehr interessant. Wenn es nur an der Transformierung liegt, könnte ich die übernehmen.
|
mczak
Anmeldungsdatum: 2. November 2013
Beiträge: 7
|
hakunamatata schrieb: Ich werde mal versuchen einen upstream-tauglichen Patch hinzubekommen ist ja keine tolle Lösung dass man das selber kompilieren muss...
Das macht auf jeden Fall Sinn. 👍
Ja ich habe den Patch mal gemailt wir werden sehen...
Die Firmware-Situation ist übrigens interessant [..] Wer also unbedingt eine firmware laden will kann das tun...
Wirklich sehr interessant. Wenn es nur an der Transformierung liegt, könnte ich die übernehmen.
Naja dass die ja offenbar nicht benötigt wird hat mein Interesse nicht gerade erhöht...
Ich wäre da schon eher interessiert die FB zum Laufen zu kriegen aber da habe ich keine Ahnung was da nötig ist. Der Treiber erlaubt z.B. nur NEC codes und die TS35 ist ja offenbar RC5. Wird da eigentlich andere az6007 Firmware benötigt für die FB oder würde das bloss mit Aenderungen im Treiber funktionieren? Die az6007-fw habe ich nicht extrahiert, wusste nicht genau wonach suchen (drx-k-fw haben scheinbar alle "48 4C" Bytes am Anfang das erleichtert die Suche ungemein...). Aber wenn ich wüsste dass die cablestar az6007-fw für irgendetwas benötigt wird (was nicht schon mit der h7-az6007-fw funktioniert wenn sie denn überhaupt anders ist) würde ich das wohl auch hinkriegen... Wenn's dich aber interessiert kann ich dir schon sagen wie ich die drx-k FW extrahiert habe, einfach im Hex-Editor nach 484C suchen in udst7000bda.sys (funktioniert sowohl mit der 32bit wie 64bit Version letztere hat aber viel mehr falsche Treffer...), ich wusste ja vorerst nicht wie gross die ist also habe ich da einfach "genug" rauskopiert (dachte 100kB müssten reichen).
Zur Analyse habe ich folgendes Programm verwendet (ist bloss leicht frisierter drxk firmware loader):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83 | #include <stdio.h>
#include <stdlib.h>
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
static void parse_microcode(const u8 p_mc_image[], u32 length)
{
const u8 *p_src = p_mc_image;
u32 address;
u16 n_blocks;
u16 block_size;
u32 offset = 0;
u32 i;
int status = 0;
/* down the drain (we don't care about MAGIC_WORD) */
/* MAGIC_WORD seems to be 48 4C great for recognition... */
p_src += sizeof(u16);
offset += sizeof(u16);
n_blocks = (p_src[0] << 8) | p_src[1];
p_src += sizeof(u16);
offset += sizeof(u16);
printf("drx-k fw number of blocks %d\n", n_blocks);
for (i = 0; i < n_blocks; i += 1) {
address = (p_src[0] << 24) | (p_src[1] << 16) |
(p_src[2] << 8) | p_src[3];
p_src += sizeof(u32);
offset += sizeof(u32);
block_size = ((p_src[0] << 8) | p_src[1]) * sizeof(u16);
p_src += sizeof(u16);
offset += sizeof(u16);
p_src += sizeof(u32);
offset += sizeof(u32);
if (offset + block_size > length) {
printf("Firmware is corrupted.\n");
return;
}
printf("block %d start 0x%x waddr 0x%x size %d\n", i, offset - 10, address, block_size);
p_src += block_size;
offset += block_size;
}
printf("real drx-k fw size %d\n", offset);
}
int main( int argc, char *argv[] )
{
FILE *fp;
u8 fw[100000];
int i = 0;
if ( argc != 2 )
{
printf( "usage: %s filename\n", argv[0] );
return -1;
}
fp = fopen(argv[1],"r");
if( fp == NULL )
{
printf("Error while opening the file.\n");
return -1;
}
while( !feof(fp) ) {
fw[i] = fgetc(fp);
i++;
}
parse_microcode(fw, i);
return 0;
}
|
Ist jetzt nicht gerade ein Meisterwerk aber es reicht um die Grösse herauszufinden - erst danach habe ich bemerkt dass die FW tatsächlich identisch ist zu dvb-demod-drxk-pctv.fw. Und wie gesagt die h5-drxk firmware sieht wirklich aus wie wenn sie identisch sein könnte abgesehen davon dass da eben alle grossen Blöcke aufgetrennt wurden (dies im Gegensatz zur h7-drxk die ist ziemlich seltsam auch viel kleiner - müsste ich raten würde ich sagen das ist kein vollständiges Image modifiziert bloss das schon existierende im Speicher des Chips).
Man könnte natürlich problemlos mehr Analyse machen um herauszufinden ob zwei fw Files identisch sind abgesehen von eben den aufgetrennten Blöcken (man muss bloss aufpassen da hat es noch pro Block 4 Bytes die vom fw-loader nicht verwendet werden sind wohl Prüfsummen). Man könnte natürlich auch den Treiber modifizieren so dass er die Blöcke selbst zerlegt, wenn's denn überhaupt nötig ist (andere Treiber scheinen kein solches Limit zu kennen).
|
Sorcim
Anmeldungsdatum: 1. April 2008
Beiträge: 256
|
UPDATE: ich hab leider nicht gesehen, dass hier schon eine Lösung existierte -_-
Ich hab mich mal an media_build gewandt und dort Hilfe bekommen, sodass die DVB-T Karte nun läuft. Hier ist, was mach machen muss: hakunamatata schrieb: Um den Patch einzubauen, führst du nach den ersten Befehlen
sudo apt-get install git linux-headers-$(uname -r) build-essential patchutils libproc-processtable-perl
git clone git://linuxtv.org/media_build.git
cd media_build
statt dem Skript build Einzelschritte aus. Zuerst machst du einen Download der aktuellen Treiberversion und entpackst die:
make download untar
Statt des alten Patches, muss man einen anderen Patch anwenden. Ich weiß leider nicht, wie man einen Patch erstellt, darum hab ich die Dateien händisch geändert und an diesen Beitrag angehängt. Sie müssen die Originaldateien in den Ordnern ./linux/drivers/media/usb/dvb-usb-v2 und ./linux/drivers/media/dvb-core kopiert werden.
Schließlich baust du die Treiber (das kann etwas Zeit in Anspruch nehmen):
make
Danach kannst du wie in der Anleitung mit
sudo make install
fortsetzen.
Desweiteren darf nicht die H7 Firmware von drxk, sondern die H5 Firmware von drxk (kombiniert mit der H7 az6007 firmware) verwendet werden. Dazu: sudo wget http://linuxtv.org/downloads/firmware/dvb-usb-terratec-h5-drxk.fw -O /lib/firmware/dvb-usb-technisat-cablestar-hdci-drxk.fw
und
sudo wget http://linuxtv.org/downloads/firmware/dvb-usb-terratec-h7-az6007.fw -O /lib/firmware/dvb-usb-terratec-h7-az6007.fw Anschließend geht DVB-T. Einzig das Tunen dauert ein wenig und der Sound knistert ein bisschen. LG,
Tobi
- az6007.c (22.6 KiB)
- Download az6007.c
- dvb-usb-ids.h (15.6 KiB)
- Download dvb-usb-ids.h
|
Thorn31
Anmeldungsdatum: 2. November 2013
Beiträge: Zähle...
|
und Dvb-c für kabel geht nicht ? 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | dmesg | grep -i DVB
[ 7.462839] usbcore: registered new interface driver dvb_usb_technisat_usb2
[ 9.603149] usb 1-6: dvb_usb_v2: found a 'Technisat Combo HD CI' in warm state
[ 10.788499] usb 1-6: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[ 10.788532] DVB: registering new adapter (Technisat Combo HD CI)
[ 10.791407] usb 1-6: dvb_usb_v2: MAC address: c2:f7:14:03:00:00
[ 10.884617] usb 1-6: DVB: registering adapter 0 frontend 0 (DRXK)...
[ 11.044220] usb 1-6: dvb_usb_v2: schedule remote query interval to 400 msecs
[ 11.044225] usb 1-6: dvb_usb_v2: 'Technisat Combo HD CI' successfully initialized and connected
[ 11.044263] usbcore: registered new interface driver dvb_usb_az6007
[ 27.442658] usb 1-6: dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0
[ 32.029364] usb 1-6: DVB: adapter 0 frontend 0 frequency 1256000 out of range 47000000..865000000)
[ 32.029418] usb 1-6: DVB: adapter 0 frontend 0 frequency 1880000 out of range 47000000..865000000)
[ 32.029454] usb 1-6: DVB: adapter 0 frontend 0 frequency 1092000 out of range 47000000..865000000)
[ 32.029489] usb 1-6: DVB: adapter 0 frontend 0 frequency 1276000 out of range (47000000..865000000)
[ 32.029523] usb 1-6: DVB: adapter 0 frontend 0 frequency 1843000 out of range (47000000..865000000)
[ 32.029557] usb 1-6: DVB: adapter 0 frontend 0 frequency 1082000 out of range
|
findet mit w_scan keine Sender bin mit meinem latein am ende ☹
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
mczak schrieb: Ja ich habe den Patch mal gemailt wir werden sehen...
Hab ich gesehen 👍 Wir werden ja sehen wie schnell der Patch die einzelnen Stationen durchläuft. Optimal wird es dann, wenn der Patch im Kernel angekommen ist. Eventuell wäre eine Idee vorab für ein aktuelles Ubuntu 13.10 nur das betroffene gepatchte Kernelmodul dvb-usb-az6007.ko als .deb-Datei mit automatischer DKMS-Kompilation zur Verfügung zu stellen. (man muss bloss aufpassen da hat es noch pro Block 4 Bytes die vom fw-loader nicht verwendet werden sind wohl Prüfsummen)
Ja, das Problem habe ich auch schon entdeckt. Solange mir nicht die Bedeutung aller 10 Bytes im Blockheader bekannt ist, wird es bei mir wohl nichts mit der Transformierung werden. 😉 Sorcim schrieb: UPDATE: ich hab leider nicht gesehen, dass hier schon eine Lösung existierte -_-
Die Lösung von mczak ist der neue Patch ⮷. Es würde aber auch der alte Patch funktionieren, nur darf die Firmware dvb-usb-terratec-h7-drxk.fw nicht geladen werden.
|
Thorn31
Anmeldungsdatum: 2. November 2013
Beiträge: 11
|
habe jetzt alles gemacht wie oben beschrieben bekomme jetzt beim w_scan |
searching QAM256...
73000: sr6900 (time: 05:47) sr6875 (time: 05:49)
81000: sr6900 (time: 05:52) sr6875 (time: 05:55)
113000: sr6900 (time: 05:57) (time: 05:59) signal ok:
QAM_256 f = 113000 kHz S6900C999
WARNING: section too short: network_id == 0xf009, section_length == 907, descriptors_loop_len == 905
|
was hat das zu bedeuten ? MFG Thorn
|
mczak
Anmeldungsdatum: 2. November 2013
Beiträge: 7
|
Sorcim schrieb: Anschließend geht DVB-T. Einzig das Tunen dauert ein wenig und der Sound knistert ein bisschen.
Dass Frequenzwechsel etwas langsam sind ist mir auch aufgefallen. Ist aber möglicherweise normal das hängt ja auch vom Tuner ab (ich habe keine Ahnung ob da der MT2063 vielleicht langsam ist).
Dass nur der Sound knistert kann eigentlich nicht sein, Video/Audio oder was auch immer macht für die HW rein gar keinen Unterschied, ist also eher ein Softwareproblem sonst irgendwo. Thorn31 schrieb: und Dvb-c für kabel geht nicht ?
Ich benutze nur dvb-c, dvb-t habe ich nicht getestet.
[ 27.442658] usb 1-6: dvb_frontend_ioctl_legacy: doesn't know how to handle a DVBv3 call to delivery system 0
Kriege ich auch ich weiss gar nicht wer da Schuld ist dass der Fehler generiert wird. Ist aber harmlos.
[ 32.029364] usb 1-6: DVB: adapter 0 frontend 0 frequency 1256000 out of range 47000000..865000000)
[ 32.029557] usb 1-6: DVB: adapter 0 frontend 0 frequency 1082000 out of range
findet mit w_scan keine Sender bin mit meinem latein am ende ☹
Scheint eher ein Problem mit w_scan oder den Parametern zu sein. Thorn31 schrieb: habe jetzt alles gemacht wie oben beschrieben bekomme jetzt beim w_scan |
searching QAM256...
73000: sr6900 (time: 05:47) sr6875 (time: 05:49)
81000: sr6900 (time: 05:52) sr6875 (time: 05:55)
113000: sr6900 (time: 05:57) (time: 05:59) signal ok:
QAM_256 f = 113000 kHz S6900C999
WARNING: section too short: network_id == 0xf009, section_length == 907, descriptors_loop_len == 905
|
was hat das zu bedeuten ?
Immerhin hat das Tuning funktioniert ☺.
Passiert das denn bei allen Frequenzen?
|
Thorn31
Anmeldungsdatum: 2. November 2013
Beiträge: 11
|
er findet jede menge sender dauert bis zu 1 Stunde aber TVheadend findet garnix und sucht auch nichts ☹ weiss nicht was ich bei w_scan einstellen muss damit er die in tvheadend übernimmt MFG Thorn PS: findet 577 Sender ☺
|
mczak
Anmeldungsdatum: 2. November 2013
Beiträge: 7
|
hakunamatata schrieb: mczak schrieb: (man muss bloss aufpassen da hat es noch pro Block 4 Bytes die vom fw-loader nicht verwendet werden sind wohl Prüfsummen)
Ja, das Problem habe ich auch schon entdeckt. Solange mir nicht die Bedeutung aller 10 Bytes im Blockheader bekannt ist, wird es bei mir wohl nichts mit der Transformierung werden. 😉
Also der Firmware-Loader im Kernel ignoriert die Bytes ja auch, der Wert ist also egal. Aber wenn's Prüfsummen oder was ähnliches ist könnte es natürlich sein dass der in Zukunft dann plötzlich reklamiert wenn er die nicht mehr ignoriert... Aber zum Beweisen ob die FW identisch ist zur drxk-h5 oder eben nicht würde das jedenfalls reichen.
|
hakunamatata
Supporter
Anmeldungsdatum: 30. Juni 2009
Beiträge: 5130
|
Aber zum Beweisen ob die FW identisch ist zur drxk-h5 oder eben nicht würde das jedenfalls reichen.
Ich habe "dvb-demod-drxk-pctv.fw" mit "dvb-usb-terratec-h5-drxk.fw" verglichen, in dem ich in beiden Fällen alle Header entfernt habe. Länge ist wie vermutet dann ident. Es besteht ein minimaler Unterschied. Die letzten 2 Byte sind vertauscht. "dvb-demod-drxk-pctv.fw" endet mit X'43 00' und "dvb-usb-terratec-h5-drxk.fw" mit X'00 43'.
|
mczak
Anmeldungsdatum: 2. November 2013
Beiträge: 7
|
hakunamatata schrieb: Aber zum Beweisen ob die FW identisch ist zur drxk-h5 oder eben nicht würde das jedenfalls reichen.
Ich habe "dvb-demod-drxk-pctv.fw" mit "dvb-usb-terratec-h5-drxk.fw" verglichen, in dem ich in beiden Fällen alle Header entfernt habe. Länge ist wie vermutet dann ident. Es besteht ein minimaler Unterschied. Die letzten 2 Byte sind vertauscht. "dvb-demod-drxk-pctv.fw" endet mit X'43 00' und "dvb-usb-terratec-h5-drxk.fw" mit X'00 43'.
Sehr interessant. Da fragt man sich natürlich ob das irgendwie einen Unterschied macht und falls ja welchen. Zu blöd dass man da gar keine Ahnung hat was die firmware so tut...
|