PCI DVB tuner fix for timeout waiting for DSP ready

I had a similar problem as described below on Ubuntu 12.04 and found that inserting saa7134-dvb into /etc/modules.conf did the trick for me too.
It's interesting though that it has been working fine before. I did recall seeing this issue once or twice, but this time it did not seem to have been resolved by multiple cold booting by itself.
http://linuxtv.org/pipermail/linux-dvb/2008-June/026775.html 
[   43.162971] tda1004x: timeout waiting for DSP ready
[   43.202914] tda1004x: found firmware revision 0 -- invalid
[   43.202918] tda1004x: waiting for firmware upload...
[   48.675012] tda1004x: Error during firmware upload

Comments

  1. bkilMay 30, 2013 at 12:01 AM

    N.B. I've encountered the very same issue again today, and I forgot the mechanism again, wasting some more time again.


    To make it clear for future reference, if your computer boots up too fast, and any driver or application tries to access the tuner before the first automatic firmware update succeeds, the card freezes and becomes unusable until the next power cycling.


    So you not only need to blocklist the given driver from automatic loading on boot, you must not use the tuner in any way before you find a line in dmesg that reads "tda1004x: found firmware revision 29 -- ok". Remember that it could take up to 15 seconds (or perhaps up to 1 minute from power up?). The card can be used as usual after the first successful upload. Here's a good dmesg extract:

    [ 15.869524] dvb_init() allocating 1 frontend
    [ 15.875558] DVB: registering new adapter (saa7133[1])
    [ 15.875560] DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)...
    [ 16.107540] tda1004x: setting up plls for 48MHz sampling clock
    [ 18.563233] tda1004x: timeout waiting for DSP ready
    [ 18.603234] tda1004x: found firmware revision 0 -- invalid
    [ 18.603237] tda1004x: trying to boot from eeprom
    [ 20.930956] tda1004x: timeout waiting for DSP ready
    [ 20.970938] tda1004x: found firmware revision 0 -- invalid
    [ 20.970941] tda1004x: waiting for firmware upload...
    [ 33.455837] tda1004x: found firmware revision 29 -- ok

    ReplyDelete
  2. bkilMay 30, 2013 at 12:32 AM

    Here's an extract from a bad boot (or was it a warm boot after failure?):

    [ 7.953609] saa7130/34: v4l2 driver version 0, 2, 17 loaded
    (...)
    [ 12.089709] saa7134 0000:03:02.0: enabling device (0000 -> 0002)
    [ 12.089723] saa7134 0000:03:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
    [ 12.089726] saa7133[1]: found at 0000:03:02.0, rev: 209, irq: 18, latency: 32, mmio: 0xf7c00000
    [ 12.089731] saa7133[1]: subsystem: 1043:4878, board: Asus Tiger 3in1 [card=147,autodetected]
    [ 12.089791] saa7133[1]: board init: gpio is 0
    (... also contains a few lines of non-ff values)
    [ 12.232919] saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    [ 12.232922] saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    [ 12.264753] tuner 17-004b: Tuner -1 found with type(s) Radio TV.
    [ 12.344477] tda829x 17-004b: setting tuner address to 61
    [ 12.408235] tda829x 17-004b: type set to tda8290+75a
    [ 16.111010] saa7133[1]: dsp access error
    [ 16.178659] saa7133[1]: registered device video1 [v4l2]
    [ 16.178760] saa7133[1]: registered device vbi1
    [ 16.178801] saa7133[1]: registered device radio1
    [ 16.181484] saa7134 ALSA driver for DMA sound loaded
    [ 16.181572] saa7133[1]/alsa: saa7133[1] at 0xf7c00000 irq 18 registered as card -1
    [ 16.229636] saa7134_dvb: Unknown parameter `#loading'
    [ 16.246535] dvb_init() allocating 1 frontend
    [ 16.254251] DVB: registering new adapter (saa7133[1])
    [ 16.254254] DVB: registering adapter 0 frontend 0 (Philips TDA10046H DVB-T)...
    [ 16.461521] tda1004x: setting up plls for 48MHz sampling clock
    [ 18.936535] tda1004x: timeout waiting for DSP ready
    [ 18.976387] tda1004x: found firmware revision 0 -- invalid
    [ 18.976391] tda1004x: trying to boot from eeprom
    [ 21.303957] tda1004x: timeout waiting for DSP ready
    [ 21.343807] tda1004x: found firmware revision 0 -- invalid
    [ 21.343811] tda1004x: waiting for firmware upload...
    [ 31.963571] tda1004x: timeout waiting for DSP ready
    [ 32.043242] tda1004x: found firmware revision 0 -- invalid
    [ 32.043246] tda1004x: trying to boot from eeprom
    [ 34.377596] tda1004x: timeout waiting for DSP ready
    [ 34.457264] tda1004x: found firmware revision 0 -- invalid
    [ 34.457268] tda1004x: waiting for firmware upload...
    [ 38.855095] tda1004x: timeout waiting for DSP ready
    [ 38.934763] tda1004x: found firmware revision 0 -- invalid
    [ 38.934767] tda1004x: firmware upload failed
    [ 50.992927] tda1004x: timeout waiting for DSP ready
    [ 51.032742] tda1004x: found firmware revision 80 -- invalid
    [ 51.032746] tda1004x: firmware upload failed
    [ 69.763399] tda1004x: setting up plls for 48MHz sampling clock
    [ 71.998132] tda1004x: timeout waiting for DSP ready
    [ 72.037968] tda1004x: found firmware revision 0 -- invalid
    [ 72.037972] tda1004x: trying to boot from eeprom

    ReplyDelete

Post a Comment

Popular posts from this blog

Hidden TFTP of TP-Link routers

I did some more investigation after the positive results with the TL-WR740Nv4  (click the link to get introduced to the way of recovery). Most users report that devices and firmware updates released after a point in time usually have this mode enabled. If a firmware update is available from the vendor for your device, it's a good idea to apply that update before installing OpenWRT or dd-wrt UNLESS you own something for which upgrading will ensure incompatible with OpenWrt, like a TL-WR730N , and possible some other models (please report). Note that some old models have newer updates in different languages, those may also be worth a try ( TODO : compatibility?). Also remember that later on, tftp recovery will need a type of firmware image without a boot loader, so strip it with dd if yours has it ( grep U-Boot , or check the filename). Positive reported claims so far (personal results highlighted): TL-WDR4300 router 192.168.0.86 server 192.168.0.66 query wdr4300v1_tp_...
Read more

Tftp secret of TL-WR740N uncovered

I've found out that even this particular entry level router supports anti-bricking, so there's no need for soldering, unless of course you are modding. The method I used is the following: Set up a tftp server  on your PC and verify if it works correctly (configuration, permissions, firewalls, etc.) Rename your target firmware to wr740v4_tp_recovery.bin and copy it to your base folder (by default /tftpboot). I tested with openwrt-ar71xx-generic-tl-wr740n-v4-squashfs-factory.bin r43602. Set up the following static IP for your PC: 192.168.0.66 /255.255.255.0. If you're not sure about the firmware name on a different model, start a packet sniffer on your PC ( tcpdump -i eth0 -n -l ) and look for the name in the RRQ message. Preferably disconnect WAN from the router Connect the PC to a LAN port Power off the router Press and hold the reset button Power on the router After the leftmost (power) LED and the rightmost (padlock) LED turn on alone in a few seconds, release...
Read more

When both Google *and* AppStatus is down

Here is a link where you could theoretically monitor Google outages: https://www.google.com/appsstatus#hl=en&v=status I had a problem with Google services just recently. However, as I wanted to verify whether the problem is on my side, this monitoring site was down as well. At the same time, the third party reports on alternative sites started to grow: http://outage.report/google http://downdetector.com/status/google http://aussieoutages.com/status/google This highlights why we should not put all our eggs into the same basket.
Read more