Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Hi, Am 24.04.2014 23:26, schrieb Mauro Carvalho Chehab: Em Thu, 24 Apr 2014 15:24:20 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: [...] What can do, instead, is to sniff the traffic at the USB port, and get the proper GPIO, XCLK and I2C speed settings for this device. My suggestion is to either run it on a QEMU VM machine, redirecting the USB device to the VM and sniffing the traffic on Linux, or to use some USB snoop software. Take a look at: http://linuxtv.org/wiki/index.php/Bus_snooping/sniffing We have a script that parses em28xx traffic, converting them into register writes. All you need to do is to sniff the traffic and check what GPIO registers are needed to reset the device. Then, add the corresponding data at em28xx-cards.c. Ok, I managed to setup a VBox with TheOtherOS and usbmon and sniffed some traffic when I (virtually) plugged in the device. The file is (compressed) about ~620 KiB. I am honest: I have no clue what I sniffed or how I should read GPIO registers from there. If anyone is interested in helping me I would send the file directly. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Em Wed, 23 Apr 2014 22:50:36 +0200 Daniel Exner d...@dragonslave.de escreveu: Hi, Am 23.04.2014 22:42, schrieb Devin Heitmueller: On Wed, Apr 23, 2014 at 4:34 PM, Daniel Exner d...@dragonslave.de wrote: You can get the firmware via the following procedure: http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware or if you're on Ubuntu it's already packaged in linux-firmware-nonfree. The file itself is 66220 bytes and has an MD5 checksum of 293dc5e915d9a0f74a368f8a2ce3cc10. I used that procedure and have exactly that file in my /lib/firmware dir. Note that if you have that file in /lib/firmware, it's entirely possible that the driver is just broken (this happens quite often). The values read back by dmesg are from the device itself, so if the chip wasn't properly initialized fields such as the version will contain garbage values. On the page you linked above older firmware versions are mentions that should be supported by the driver. My Question is: how to get them? But you may be right, because Device is Xceive 34584 seems also wrong (didn't find any hint such a device exists..) I'm willing to invest some time to repair the driver. Anyone interested in helping me in getting this thing back to work? That doesn't seem to be a driver issue, but a badly extracted firmware. The firmware version should be 2.7. It the version doesn't match, that means that the firmware was not properly loaded. The driver checks if the firmware version loaded matches the version of the file, and prints warnings via dmesg. Are you sure that the md5sum of the firmware is 293dc5e915d9a0f74a368f8a2ce3cc10? -- Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Hi, Am Thu, 24 Apr 2014 08:29:19 -0300 schrieb Mauro Carvalho Chehab m.che...@samsung.com: That doesn't seem to be a driver issue, but a badly extracted firmware. The firmware version should be 2.7. It the version doesn't match, that means that the firmware was not properly loaded. The driver checks if the firmware version loaded matches the version of the file, and prints warnings via dmesg. Are you sure that the md5sum of the firmware is 293dc5e915d9a0f74a368f8a2ce3cc10? Yes, I am sure. The tuner-xc2028 module even reports FW Version 2.7. What I suspect is, that this piece of hardware simply doesn't work with that firmware version. Find attached the whole output of dmesg after loading the module with debug=1, pluggin in device and starting xawtv. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc usb 3-2: new high-speed USB device number 3 using xhci_hcd usb 3-2: New USB device found, idVendor=0ccd, idProduct=0043 usb 3-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 usb 3-2: Product: Cinergy T USB XS usb 3-2: Manufacturer: TerraTec Electronic GmbH em28xx: New device TerraTec Electronic GmbH Cinergy T USB XS @ 480 Mbps (0ccd:0043, interface 0, class 0) em28xx: Video interface 0 found: isoc em28xx: DVB interface 0 found: isoc em28xx: chip ID is em2870 em2870 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0x8d1e3bdf em2870 #0: EEPROM info: em2870 #0: No audio on board. em2870 #0: 500mA max power em2870 #0: Table at offset 0x06, strings=0x246a, 0x348e, 0x em2870 #0: Identified as Terratec Cinergy T XS (card=43) em2870 #0: em2870 #0: The support for this board weren't valid yet. em2870 #0: Please send a report of having this working em2870 #0: not to V4L mailing list (and/or to other addresses) em2870 #0: analog set to isoc mode. em2870 #0: dvb set to isoc mode. usbcore: registered new interface driver em28xx em2870 #0: Registering V4L2 extension Chip ID is not zero. It is not a TEA5767 tuner 16-0060: Tuner -1 found with type(s) Radio TV. xc2028: Xcv2028/3028 init called! xc2028 16-0060: creating new instance xc2028 16-0060: type set to XCeive xc2028/xc3028 tuner xc2028 16-0060: xc2028_set_config called xc2028 16-0060: xc2028_set_analog_freq called xc2028 16-0060: generic_set_freq called xc2028 16-0060: should set frequency 567250 kHz xc2028 16-0060: check_firmware called xc2028 16-0060: xc2028_set_analog_freq called xc2028 16-0060: generic_set_freq called xc2028 16-0060: should set frequency 567250 kHz xc2028 16-0060: check_firmware called xc2028 16-0060: request_firmware_nowait(): OK xc2028 16-0060: load_all_firmwares called xc2028 16-0060: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 xc2028 16-0060: Reading firmware type BASE F8MHZ (3), id 0, size=8718. xc2028 16-0060: Reading firmware type BASE F8MHZ MTS (7), id 0, size=8712. xc2028 16-0060: Reading firmware type BASE FM (401), id 0, size=8562. xc2028 16-0060: Reading firmware type BASE FM INPUT1 (c01), id 0, size=8576. xc2028 16-0060: Reading firmware type BASE (1), id 0, size=8706. xc2028 16-0060: Reading firmware type BASE MTS (5), id 0, size=8682. xc2028 16-0060: Reading firmware type (0), id 10007, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 10007, size=169. xc2028 16-0060: Reading firmware type (0), id 20007, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 20007, size=169. xc2028 16-0060: Reading firmware type (0), id 40007, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 40007, size=169. xc2028 16-0060: Reading firmware type (0), id 80007, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 80007, size=169. xc2028 16-0060: Reading firmware type (0), id 300e0, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 300e0, size=169. xc2028 16-0060: Reading firmware type (0), id c00e0, size=161. xc2028 16-0060: Reading firmware type MTS (4), id c00e0, size=169. xc2028 16-0060: Reading firmware type (0), id 20, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 20, size=169. xc2028 16-0060: Reading firmware type (0), id 400, size=161. xc2028 16-0060: Reading firmware type MTS (4), id 400, size=169. xc2028 16-0060: Reading firmware type D2633 DTV6 ATSC (10030), id 0, size=149. xc2028 16-0060: Reading firmware type D2620 DTV6 QAM (68), id 0, size=149. xc2028 16-0060: Reading firmware type D2633 DTV6 QAM (70), id 0, size=149. xc2028 16-0060: Reading firmware type D2620 DTV7 (88), id 0, size=149. xc2028 16-0060: Reading firmware type D2633 DTV7 (90), id 0, size=149. xc2028 16-0060: Reading firmware type D2620 DTV78 (108), id 0, size=149. xc2028 16-0060: Reading firmware type D2633 DTV78 (110), id 0, size=149. xc2028 16-0060: Reading firmware type D2620 DTV8 (208), id 0, size=149. xc2028 16-0060: Reading firmware type D2633 DTV8 (210), id 0, size=149. xc2028 16-0060: Reading firmware type FM (400), id 0, size=135.
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Yes, I am sure. The tuner-xc2028 module even reports FW Version 2.7. Yeah, the firmware image itself looks fine. What I suspect is, that this piece of hardware simply doesn't work with that firmware version. You've got the right blob (that's the only firmware that has ever run on the xc3028a chip). The message you provided which says Device is Xceive 34584 version 8.7, firmware version 1.8 is the value read out of the xc3028 chip after the firmware is loaded. The value isn't read out of the firmware blob. There are really three possibilities here: 1. The xc3028 is being held in reset. They've screwed up the GPIOs in the em28xx driver so many times that I've lost count. If the chip is in reset during the firmware load or when reading the version info, you'll get whatever garbage happened to be in memory when the I2C call was made. Alternatively, the xc3028 gets it's reset line probed between loading the firmware and reading the version (but this is less likely). 2. The xc3028 is not in reset, and the firmware load failed. In this case, for whatever reason the firmware wasn't loaded properly into the chip (for example, due to a bug in the I2C code in the em28xx driver) and the CPU on the 3028 never gets started. Hence when it goes to subsequently read the firmware version back out of the chip, the CPU on the 3028 isn't running so you're getting a garbage value back from the 3028. 3. The firmware loaded properly, but due to some other condition the I2C call to read the firmware version never actually made it to the 3028 and you're getting back whatever garbage value happened to be in the kernel memory that was supposed to be populated with the I2C response. The right way to debug this is probably to put a logic analyzer on the I2C bus and see if the traffic is making it to the xc3028 at all. Would also monitor the reset line with a scope and make sure it's high and watch for it being strobed when it shouldn't be. Of course both of those debugging techniques require hardware. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Em Thu, 24 Apr 2014 15:24:20 -0400
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:
Yes, I am sure. The tuner-xc2028 module even reports FW Version 2.7.
Yeah, the firmware image itself looks fine.
What I suspect is, that this piece of hardware simply doesn't work with
that firmware version.
You've got the right blob (that's the only firmware that has ever run
on the xc3028a chip). The message you provided which says Device is
Xceive 34584 version 8.7, firmware version 1.8 is the value read out
of the xc3028 chip after the firmware is loaded. The value isn't read
out of the firmware blob.
There are really three possibilities here:
1. The xc3028 is being held in reset. They've screwed up the GPIOs
in the em28xx driver so many times that I've lost count. If the chip
is in reset during the firmware load or when reading the version info,
you'll get whatever garbage happened to be in memory when the I2C call
was made. Alternatively, the xc3028 gets it's reset line probed
between loading the firmware and reading the version (but this is less
likely).
Hmm... This device entry is too simple for my taste:
[EM2870_BOARD_TERRATEC_XS] = {
.name = Terratec Cinergy T XS,
.valid= EM28XX_BOARD_NOT_VALIDATED,
.tuner_type = TUNER_XC2028,
.tuner_gpio = default_tuner_gpio,
},
And we never had a feedback that this works, as it still have a
.valid= EM28XX_BOARD_NOT_VALIDATED,
entry on it.
Maybe default_tuner_gpio is not the right one here, or it needs
something like:
.i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_100_KHZ,
for it to work.
2. The xc3028 is not in reset, and the firmware load failed. In this
case, for whatever reason the firmware wasn't loaded properly into the
chip (for example, due to a bug in the I2C code in the em28xx driver)
and the CPU on the 3028 never gets started. Hence when it goes to
subsequently read the firmware version back out of the chip, the CPU
on the 3028 isn't running so you're getting a garbage value back from
the 3028.
The most likely cause for this would be if the I2C speed is too high.
Not sure if this could also be affected by .xclk configuration.
3. The firmware loaded properly, but due to some other condition the
I2C call to read the firmware version never actually made it to the
3028 and you're getting back whatever garbage value happened to be in
the kernel memory that was supposed to be populated with the I2C
response.
The right way to debug this is probably to put a logic analyzer on the
I2C bus and see if the traffic is making it to the xc3028 at all.
Would also monitor the reset line with a scope and make sure it's high
and watch for it being strobed when it shouldn't be. Of course both
of those debugging techniques require hardware.
You likely don't need a hardware I2C analyzer, if the device is
not broken.
What can do, instead, is to sniff the traffic at the USB port, and get
the proper GPIO, XCLK and I2C speed settings for this device.
My suggestion is to either run it on a QEMU VM machine, redirecting
the USB device to the VM and sniffing the traffic on Linux, or to
use some USB snoop software.
Take a look at: http://linuxtv.org/wiki/index.php/Bus_snooping/sniffing
We have a script that parses em28xx traffic, converting them into
register writes. All you need to do is to sniff the traffic and check
what GPIO registers are needed to reset the device.
Then, add the corresponding data at em28xx-cards.c.
Regard
--
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Hi, (Please keep me in CC as I'm currently not subscribed to this Mailinglist) I happened to inherit one of those DVB-T Sticks ID 0ccd:0043 TerraTec Electronic GmbH Cinergy T XS and of course it isn't working as exspected. So far I extracted the firmware the tuner_xc2028 module was telling me (xc3028-v27.fw) and the module loaded. But no dvb device nodes where created. I tried connecting directly to it using xawtv and that gave me a load of Incorrect readback of firmware version. messages. Then I tried loading the module with debug=1 and now I see: Device is Xceive 34584 version 8.7, firmware version 1.8 So I guess the driver is trying to use the wrong firmware file. I extracted some file named merlinC.rom from the Terratec Windows Drivers that I suspect to contain the firmware. Now I need some help how to verify that and create a usable fw File for the driver. Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
On Wed, Apr 23, 2014 at 4:34 PM, Daniel Exner d...@dragonslave.de wrote: Hi, (Please keep me in CC as I'm currently not subscribed to this Mailinglist) I happened to inherit one of those DVB-T Sticks ID 0ccd:0043 TerraTec Electronic GmbH Cinergy T XS and of course it isn't working as exspected. So far I extracted the firmware the tuner_xc2028 module was telling me (xc3028-v27.fw) and the module loaded. But no dvb device nodes where created. I tried connecting directly to it using xawtv and that gave me a load of Incorrect readback of firmware version. messages. Then I tried loading the module with debug=1 and now I see: Device is Xceive 34584 version 8.7, firmware version 1.8 So I guess the driver is trying to use the wrong firmware file. I extracted some file named merlinC.rom from the Terratec Windows Drivers that I suspect to contain the firmware. Now I need some help how to verify that and create a usable fw File for the driver. You can get the firmware via the following procedure: http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware or if you're on Ubuntu it's already packaged in linux-firmware-nonfree. The file itself is 66220 bytes and has an MD5 checksum of 293dc5e915d9a0f74a368f8a2ce3cc10. Note that if you have that file in /lib/firmware, it's entirely possible that the driver is just broken (this happens quite often). The values read back by dmesg are from the device itself, so if the chip wasn't properly initialized fields such as the version will contain garbage values. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T XS Firmware (Kernel 3.14.1)
Hi, Am 23.04.2014 22:42, schrieb Devin Heitmueller: On Wed, Apr 23, 2014 at 4:34 PM, Daniel Exner d...@dragonslave.de wrote: You can get the firmware via the following procedure: http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware or if you're on Ubuntu it's already packaged in linux-firmware-nonfree. The file itself is 66220 bytes and has an MD5 checksum of 293dc5e915d9a0f74a368f8a2ce3cc10. I used that procedure and have exactly that file in my /lib/firmware dir. Note that if you have that file in /lib/firmware, it's entirely possible that the driver is just broken (this happens quite often). The values read back by dmesg are from the device itself, so if the chip wasn't properly initialized fields such as the version will contain garbage values. On the page you linked above older firmware versions are mentions that should be supported by the driver. My Question is: how to get them? But you may be right, because Device is Xceive 34584 seems also wrong (didn't find any hint such a device exists..) I'm willing to invest some time to repair the driver. Anyone interested in helping me in getting this thing back to work? Greetings Daniel -- Daniel Exner Public-Key: https://www.dragonslave.de/pub_key.asc signature.asc Description: OpenPGP digital signature
