Twinhan VP-1020A: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
(minor reworking)
(bunch of clean ups)
Line 39: Line 39:
<pre>bttv0: subsystem: fefe:0001 (UNKNOWN)
<pre>bttv0: subsystem: fefe:0001 (UNKNOWN)
bttv0: using: *** UNKNOWN/GENERIC *** [card=0,autodetected]</pre>
bttv0: using: *** UNKNOWN/GENERIC *** [card=0,autodetected]</pre>
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 the EEPROM being writable also means that one can fix the problem relatively easy. You will need the '''i2c*''' programs from '''lm-sensors'''.
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 the EEPROM being writable also means that one can fix the problem relatively easy.
<br>
<br>
{{Note|To fix the EEPROM, it is IMPORTANT that you load all modules for your 1020 card ''except'' dvb-bt8xx.}}
<br>
You will need the '''i2c*''' programs from '''[http://www.lm-sensors.org/ lm-sensors]''' -- some Linux distros may have these utilities already installed, otherwise you will have to obtain and install them yourself.


The first step is to list all the installed i2c buses on your system by opening a command terminal and running:
To list all the buses, run:
modprobe i2c_dev
modprobe i2c_dev
i2cdetect -l
i2cdetect -l

{{Note|'''IMPORTANT: to fix the EEPROM you must load all modules for your card except dvb-bt8xx.'''}}
From the i2cdetect output, 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.
Find the right bus for your card and run

i2cdetect BUS
Then run:
(from here on, replace "BUS" with the name of the correct bus that you just determined is for your card) The above should list available address spaces. This can be dangerous if the "BUS" is wrong, but usually it is safe. The 1020 normally has only one active chip at 0x50. If this looks right try
i2cdump BUS 0x50
i2cdetect ''BUS''
The above should list available address spaces. The 1020 card normally has only one active chip at address 0x50.
to dump the EEPROM (usually safe). The (wrong) subsystem id will reside in the last 4 bytes, make sure it matches the one your system prints before the hang -- if you saw ''fefe:0001'' that means ''00 01 fe fe''. If do not see the id there, or nothing resides at 0x50, '''stop here'''! The next command will write to the chip, and may damage the respective hardware irreparably! '''NO GUARANTEES'''! That said, a card with this symptoms is a doorstop anyway, so if you are '''sure''' you are not looking at another hardware, go ahead. To put the right id ''1822:0001'' there, run the following commands
<br>
i2cset -y BUS 0x50 0xfc 0x00 b
{{Note|This can be dangerous if the ''BUS'' is wrong, but usually it is safe.}}
i2cset -y BUS 0x50 0xfd 0x01 b
<br>
i2cset -y BUS 0x50 0xfe 0x18 b
If the above step seems right, try to dump the EEPROM's contents with:
i2cset -y BUS 0x50 0xff 0x22 b
i2cdump ''BUS'' 0x50
The commands will complain about failing readback, but it should work anyway. Cross-check with another

i2cdump -y BUS 0x50
From the output, 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 warning!
Once the bttv module is loaded again (e.g. at the next reboot) it should detect your card correctly. The same goes for the dvb-bt8xx module.

{{Note|The following commands will write to the EEPROM chip. This means that:
* you should be '''absolutely sure''' that the EEPROM dump you are looking at is from your 1020 card -- i.e make sure you are 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 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, there is always an element of risk involved}}

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.

To put the correct ID of ''1822:0001'' at address 0x50 of 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
The commands will complain about failing readback, but it should work anyway.

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.


[[Category:DVB-S]]
[[Category:DVB-S]]

Revision as of 15:01, 20 June 2007

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

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

Overview

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 Twinhan / Brooktree 1020A

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 unknown reasons (maybe a buggy driver or something?) portions of it 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 the EEPROM being writable also means that one can fix the problem relatively easy.

Note: To fix the EEPROM, it is IMPORTANT that you load all modules for your 1020 card except dvb-bt8xx.


You will need the i2c* programs from lm-sensors -- some Linux distros may have these utilities already installed, otherwise you will have to obtain and install them yourself.

The first step is to list all the installed i2c buses on your system by opening a command terminal and running:

modprobe i2c_dev
i2cdetect -l

From the i2cdetect output, 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.

Then run:

i2cdetect BUS

The above should list available address spaces. The 1020 card normally has only one active chip at address 0x50.

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


If the above step seems right, try to dump the EEPROM's contents with:

i2cdump BUS 0x50

From the output, 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 warning!

Note: The following commands will write to the EEPROM chip. This means that:
  • you should be absolutely sure that the EEPROM dump you are looking at is from your 1020 card -- i.e make sure you are 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 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, there is always an element of risk involved

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.

To put the correct ID of 1822:0001 at address 0x50 of 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

The commands will complain about failing readback, but it should work anyway.

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.