Twinhan VP-1020A: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
(some reorg, minor touch ups)
(minor fixes)
Line 32: Line 32:


==Kernel Hangup Problems with Twinhan / Brooktree 1020A==
==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.
If your kernel freezes at startup with the following last messages: <pre>

bttv0: subsystem: fefe:0001 (UNKNOWN)
So, if your kernel freezes at startup with the following last messages:
<pre>bttv0: subsystem: fefe:0001 (UNKNOWN)
bttv0: using: *** UNKNOWN/GENERIC *** [card=0,autodetected]</pre>
bttv0: using: *** UNKNOWN/GENERIC *** [card=0,autodetected]</pre>
This means your card's eeprom has been corrupted. The card takes it subsystem id from this eeprom, ''fefe:0001'' is an unknown id, which makes the bttv driver hang. Due to unknown reasons (or cheapness on TwinHan's part) the eeprom is not write protected, and something (maybe a buggy driver?) stomped over it.
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'''.


To list all the buses, run:
But the eeprom being writable also means that one can fix the problem relatively easy. You need the '''i2c*''' programs from '''lm-sensors'''. Run
modprobe i2c_dev
modprobe i2c_dev
i2cdetect -l
i2cdetect -l
to list all busses. '''IMPORTANT: to fix eeprom you must load all modules for your card except dvb-bt8xx.''' Find the right one for your card and do
{{Note|'''IMPORTANT: to fix the EEPROM you must load all modules for your card except dvb-bt8xx.'''}}
Find the right bus for your card and run
i2cdetect BUS
i2cdetect BUS
(Replace BUS with the bus you determined from now on.) The above should list available address spaces. This can be dangerous if BUS is wrong, but usually it is safe. The 1020 normally has only one active chip at 0x50. If this looks right try
(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
i2cdump BUS 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 irreperably! '''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
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
i2cset -y BUS 0x50 0xfc 0x00 b
i2cset -y BUS 0x50 0xfc 0x00 b
i2cset -y BUS 0x50 0xfd 0x01 b
i2cset -y BUS 0x50 0xfd 0x01 b
Line 52: Line 55:
i2cdump -y BUS 0x50
i2cdump -y BUS 0x50
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.
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.






Revision as of 16:51, 19 June 2007

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

A DVB-S Budget PCI card by TwinHan Technology Co. Ltd

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 the VP-1020 and the VP-1020A are the color of the board and the firmware contained in the ASIC.

Overview

("DST-03T") (dst)

 features: Card is capable of delivering the full unmodified TS stream to userspace. 
 card driver: dvb-bt8xx
 interface: PCI
 PCI device id: 14f1:8804
 PCI subsystem id: 1822:0001
 Bridge: bt8xx
 frontend 1: LG
   frontend driver: dst
 Notes: The frontends on these cards are hidden behind an ASIC - no need to know the full details.
        The actual card type is determined by interrogating the onboard EEPROM.

Required modules and parameters:
The only frontend driver for this card is the dst module. The tuner component initialization routines are held in the ASIC in the form of firmware (not reloadable through software).

This card uses the bttv driver. Well suppported by LinuxTV drivers.

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. You will need the i2c* programs from lm-sensors.

To list all the buses, run:

modprobe i2c_dev
i2cdetect -l
Note: IMPORTANT: to fix the EEPROM you must load all modules for your card except dvb-bt8xx.

Find the right bus for your card and run

i2cdetect BUS

(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

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

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 with another

i2cdump -y BUS 0x50

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.