Twinhan VP-1020A

VP-1020A

VP-1020A ASIC ... Identify your card model

A (so called) "Budget" DVB-S PCI card by TwinHan. This card is well suppported by the LinuxTV drivers.

Overview/Features

Effectively, the VP-1020A is the oldest card design in the DVB-S family from TwinHan -- although it was preceeded by the VP-1020 model, the only differences between itself and the older VP-1020 are the color of the board (PCB) and the firmware contained in the onboard ASIC.

("DST-03T") (dst)
 features: Card is capable of delivering the full unmodified TS stream to userspace. 
 interface: PCI
 PCI device id: 14f1:8804
 PCI subsystem id: 1822:0001
 Bridge: bt8xx
  card driver: dvb-bt8xx
 frontend: LG
  frontend driver: dst

Notes: 
* The actual card type is determined by interrogating the onboard EEPROM.
* The frontend on these cards is hidden behind an ASIC -- the tuner component initialization routines are held 
  in the ASIC in the form of firmware (not reloadable through software).  So there is no need to know the full 
  details of the frontend, and, consequently, the only frontend driver for this card is the dst module. 

Required modules and parameters:
Uses the bttv driver.

dvb_core dvb_shutdown_timeout=0 
bttv i2c_hw=1 card=0x71 
bt878 
dst 
dvb-bt8xx

Loading just dvb-bt8xx will normally autodetect the card and load all the above modules with the required parameters. See the following section for one potential problem area.

Kernel Hangup Problems with the TwinHan 1020A / bttv Driver

This card derives it's PCI subsystem ID from the value contained in the EEPROM. Unfortunately, for some reason (or cheapness on TwinHan's part) the EEPROM is not write protected, and, consequently, due to some other unknown reasons (such as maybe a buggy driver or something other?) portions of the EEPROM may become corrupted/overwritten.

So, if your kernel freezes at startup with the following last messages:

bttv0: subsystem: fefe:0001 (UNKNOWN)
bttv0: using: *** UNKNOWN/GENERIC *** [card=0,autodetected]

it most likely means that your card's EEPROM has become corrupted. The fefe:0001 value reported is an unknown ID, which causes the bttv driver to hang. The good news, however, is that with the EEPROM being writable, this also means that one can fix the problem relatively easily....relatively.

The Catch-22 Situation

• With the card installed, during boot up, the bttv driver is loaded and it performs an I²C probe of the EEPROM, where upon the unknown ID is encountered and which causes the driver to freeze. If bttv never probed, you wouldn't end up with a hung kernel.
• In order to correct the root of that problem (an incorrect value in the EEPROM) you will need to have the card installed and be able to write to its EEPROM chip via I²C
• However, problematic to the solution is that the card actually doesn't contain a vanilla I²C bus. Instead, I²C probing is performed in conjunction with PIO signals, and it is the bttv driver that provides such functioning.

And there lies the catch-22 situation: you can't boot with the card installed because of bttv, but you can't proceed to fix the problem without first booting with the card installed and having bttv loaded

There are several ways for getting around this conundrum, and although the difference between these methods is simply in the level of each's procedural complexity, they all effectively provide the same outcome. Which method you choose is entirely up to you -- the obvious route to take is that which you are most comfortable with in performing. In very brief/rough description, here are a few ways:

• uninstall the card; boot; fix modprobe.conf with the bttv card=113 option so as to force that identification rather then relying upon autodetection; shutdown; reinstall card; reboot; if that works, follow the steps listed below in the next section
• uninstall the card; boot; rename bttv module (i.e. bttv.ko to bttv.bak) to suppress its loading during bootup; shutdown; reinstall card; reboot; cp bttv.bak bttv.ko; modprobe bttv card=113; if that works, follow the steps listed below in the next section
• boot from a liveCD (or an OS installation disk, and while loading its setup, get to a console via Ctrl + Fn); then mount the filesystem on your hdd and make the necessary changes via either the first two methods outlined listed just above; reboot; if that works, follow the steps listed below in the next section ... this method avoids the necessity of having to do the physical removal and re-installation steps of the card and some of the requisite reboots, though newcomers will likely not be familiar with the command line steps required to successfully carry out the procedure.

Steps For Fixing A Corrupted EEPROM:

Note: The original authour of the article wrote a warning that "to fix the EEPROM, it is IMPORTANT that you load all modules for your 1020 card except dvb-bt8xx." This may not be entirely necessary. But what should be clear from the discussion above, you most certainly will need to have the bttv module reloaded after first having booted with the card installed and the bttv module disabled/surpressed somehow

1. Obtain the I²C Tools for Linux
You will need the "i2c*" programs from I²C Tools for Linux (formerly included directly within lm-sensors) -- some Linux distros may have these utilities already installed, otherwise you will have to obtain and install them yourself. After installation, make sure the i2c-dev module, which the i2c* utilities rely upon, is loaded -- you can check via opening a command console and running:

lsmod | grep i2c

If i2c-dev is not contained within the output, then load the driver now via:

modprobe i2c_dev

2. Determine your card's I²C Bus
List all the installed I²C buses on your system by opening a command terminal and running:

i2cdetect -l

Remember, as described in the "Catch-22" section above, your card does not have a regular I²C bus, so unless the bttv driver is loaded, i2cdetect will not find/report one for the card. These steps assume that you have already resolved the catch-22 delemma, and as such, having bttv loaded, you would obtain output from i2cdetect similar to that shown in the example below:

Installed I2C busses:
  i2c-1       unknown         bt878 #0 [hw]                           Algorithm unavailable
  i2c-0       unknown         SMBus PIIX4 adapter at e800             Algorithm unavailable

From the i2cdetect output that is generated in your own case, determine which bus relates to your 1020 card -- the first column in the list will show i2c-BUS, where BUS is an integer representing a particular installed bus in your system. From here on, whenever BUS is written in these instructions, substitute it with the correct integer that represents the bus that you just determined is for your card. As can be seen, in the example above this would correspond to i2c-1.

3. Obtain a contents dump from your card's EEPROM

Note: This step can be dangerous if the BUS used is wrong, but usually it is safe.

The next step is to run:

i2cdetect BUS

The above command should result in the output of a map of available address spaces detected on that BUS. The 1020 card normally has only one active chip at address 0x50. For example:

 i2cdetect 1

 WARNING! This program can confuse your I2C bus, cause data loss and worse!
 I will probe file /dev/i2c-1.
 I will probe address range 0x03-0x77.
 Continue? [Y/n] y

      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:          XX XX XX XX XX XX XX XX XX XX XX XX XX
 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
 50: 50 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
 70: XX XX XX XX XX XX XX XX

If your output seems right, then try to dump the EEPROM's contents with:

i2cdump BUS 0x50

For example:

 i2cdump 1 0x50

 No size specified (using byte-data access)
 WARNING! This program can confuse your I2C bus, cause data loss and worse!
 I will probe file /dev/i2c-1, address 0x50, mode byte
 Continue? [Y/n] y

      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
 00: 00 f0 00 dc 00 10 00 38 ff ff ff ff ff ff ff ff    .?.?.?.8........
 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 50: 00 ff ff ff ff ff ff 20 ff 00 00 ff ff ff ff ff    ....... ........
 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
 f0: ff ff ff ff ff ff ff ff fe f9 00 00 00 01 fe fe    ........??...???

From the output of the EEPROM contests dump, you will find that the (incorrect) subsystem ID will reside in the last 4 bytes -- make sure it matches the one that your system prints just before the system hang (i.e. if your system message shows the incorrect fefe:0001, that means the last 4 bytes from the EEPROM dump should be 00 01 fe fe ). If you do not see the incorrect ID there, or nothing resides at address 0x50, stop here and heed this following warning:

Note: The commands which follow in step 4 will write to the EEPROM chip. This means that:

• you should be absolutely sure that the EEPROM contents dump that you're looking at is from your 1020 card -- i.e make sure you're NOT looking at that from another piece of hardware, as the write operation may damage the respective hardware irreparably !!
• even if you are looking at the EEPROM contents dump from your 1020 card, and even though the chances of mishap are then very small, there are still NO GUARANTEES that the write operation won't damage the 1020 card irreparably -- just as when you write a new BIOS to a motherboard, or a new firmware to a optical disc burner, or whatever the case, there is always an element of risk involved. In the event of any negative consequences, as borne out of your actions in face of such risk, you alone bear the entire responsibility

Now, with that said, a 1020 card exhibiting the hanging symptoms described above, but whose EEPROM dump doesn't have the expected incorrect ID at 0x50, is still essentially a very small step away from becoming a doorstop, so you might as well go ahead anyway and perform the following steps which write to the card.

4. Write the correct ID value to your card's EEPROM
To put the correct ID of 1822:0001 at address 0x50 (i.e. the EEPROM on your 1020 card), run the following commands:

i2cset -y BUS 0x50 0xfc 0x00 b
i2cset -y BUS 0x50 0xfd 0x01 b
i2cset -y BUS 0x50 0xfe 0x18 b
i2cset -y BUS 0x50 0xff 0x22 b

Note, each of these commands will complain with a "Warning - readback failed", but the write operations should work nonetheless.

5. Check for success
Cross-check that you successfully overwrote the EEPROM with the correct ID by way of another EEPROM contents dump:

i2cdump -y BUS 0x50

If all looks correct, then once the bttv module is loaded again (e.g. at the next reboot, or via unloading the modules from memory and then reloading them), it should now detect your card correctly. The same goes for the dvb-bt8xx module.