Xceive XC3028/XC2028: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
(added further notes based largely upon (and at times in verbatim of) Mauro's explanations on the V4L m/l)
m (fixed link)
Line 67: Line 67:


'''Some Notes'''
'''Some Notes'''
* The in-kernel driver supports older firmware, but some extracting tool is needed for older firmwares; see [[Development:_How_to_extract_a_firmware here]].
* The in-kernel driver supports older firmware, but some extracting tool is needed for older firmwares; see [[Development:_How_to_extract_a_firmware|here]].


* If you use the debug option with the tuner-xc2028 driver, then after the firmware has been successfully loaded, you will find that the firmware's internal version code is reported within your system log / dmesg output.
* If you use the debug option with the tuner-xc2028 driver, then after the firmware has been successfully loaded, you will find that the firmware's internal version code is reported within your system log / dmesg output.

Revision as of 16:01, 6 February 2008

This article discusses a family of silicon ICs, produced by Xceive, that combine RF tuner and analog IF demodulator functions within one chip. In addition, this page addresses the drivers that support these chips, as well as their firmware requirements.

IC Family Members

XC3028

The XC3028 has robust support for both analog and digital signals; it supports the analog TV broadcast standards (NTSC, PAL, & SECAM), CVBS, SIF and most digital TV standards (ATSC, DVB-C, DVB-T, DMB-T, & ISDB-T).

Note: While the XC3028 is capable of reception of signals using 64-QAM, it is incapable of handling the more complex 256-QAM flavour.

The XC3028 IC is found in a large number of devices.

XC3018

seen here.

The XC3018 is a lesser version of the XC3028; it supports only the analog TV broadcast standards (NTSC, PAL, & SECAM) and just the DVB-T digital TV standard, whereas the XC3028 has more robust support for both analog and digital signals.

List of devices using this chip:

XC2028

An analog only variant.


Drivers

Development -- There are two drivers versions. The oldest out-of-tree driver, from mrec. Newer kernels (2.6.25+) will have tuner-xc2028 for xc2028/3028 based boards.

Feature Support

  • in-kernel xc3028 driver - analog/DVB-T/ATSC work fine; radio support is untested
  • mrec's - analog and digital are both supported


Firmware Information

The information in this section is directed only towards support for the in-kernel driver. For 3rd party driver requirements and/or information, please consult those sources directly.

How to Obtain the Firmware

Follow the instructions outlined on lines 6-14 of the extract_xc3028.pl perl script. Specifically:

# In order to use, you need to:
#       1) Download the windows driver with something like:
#               wget http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip
#       2) Extract the file hcw85bda.sys from the zip into the current dir:
#               unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip Driver85/hcw85bda.sys
#       3) run the script:
#               linux/Documentation/video4linux/extract_xc3028.pl
#       4) copy the generated file:
#               cp xc3028-v27.fw /lib/firmware

The above instructions allow the extraction of Xceive's v.2.7 firmwares from a specific Windows driver file (i.e. the script won't accept nor be able to extract the firmware from other files ... see below for furhter details). This approach is known to work with a large number of boards from different manufacturers.

The in-kernel driver approach for xc2028/xc3028 has a complex logic for loading a firmware. The big advantage of this approach is that:

  • just one firmware file is needed in order to provide support for all video/dvb/radio standards.
  • almost no changes are required at the device's bridge drivers.

In order to do that, the firmware format of the in-kernel driver is completely different from the format used by other approaches.

About the Windows driver file from which the Xceive firmware is extracted

The Windows ".sys" file contains the Xceive firmware + xc3028 code + device-specific code + vendor-specific code. So, the ".sys" file from your Windows driver CD/download is likely to be different between two different cards, even if they have the exact same Xceive firmware version.

About the Xceive firmware

Internally, the Xceive firmware actually contains several small firmwares, for each different xc3028 supported standard. The in kernel driver loads all firmwares once, and will automatically load the proper part, based on the required standard.

The Xceive firmware has an internal version number; the newest of which, to the best of knowledge, is version 2.7. In theory, this particular firmware can be the same one that is used for all xc3028 based devices. However, in practice, there are some devices that might require an older firmware version (eg. this is the case with the tm6000 based 10moons device, which requires firmware version 1.e). If you happen to know that the Windows ".sys" driver file for your device is supplied with a version 2.7 firmware, then in all likelihood you can use the perl script above (which extracts the firmware from the specific hcw85bda.sys file), and this should work properly for your device...of course, not many end users are going to know that information. So, without further theoretical explanations, the bottom line is that you should just try above method first, and, if it that is unsuccessful, then proceed to try to figure out the reason why.

Some Notes

  • The in-kernel driver supports older firmware, but some extracting tool is needed for older firmwares; see here.
  • If you use the debug option with the tuner-xc2028 driver, then after the firmware has been successfully loaded, you will find that the firmware's internal version code is reported within your system log / dmesg output.
  • The firmware is not dependent on system architecture (i.e whether it is a 32 or 64 bit machine has no bearing).

About the tuner_callback requirement

In order for the proper firmware to load, the bridge chip must be coded with a xc3028-specific setup and a tuner_callback, with the proper GPIO codes to reset the xc2028/3038.

The reset code is specific to each hardware design. Since several hardwares are based at the same reference design, generally, the initialization code may be the same for two different boards, though this may not hold true and and different initialization needs may be required for some boards,

See the particular bridge chip articles/code for further information.


External Links