[pvrusb2] PVR USB2 - how to check if it's dead?
Helmut Jarausch
jarausch at skynet.be
Mon Dec 17 13:07:58 CST 2012
On 12/10/2012 08:13:56 PM, Mike Isely wrote:
>
> What you're seeing there is all correct. The "suspicious" bit is
> actually a feature of the Cypress FX2 microcontroller used in these
> devices. What's happening is that when it first powers up, the
> microcontroller is running a very basic firmware image that is
> basically
> only smart enough to be replaced with a more complete firmware image.
> So what happens is that the pvrusb2 driver detects this situation and
> downloads the needed firmware image - that the v4l-pvrusb2-29xxx-01.fw
> file image. Once the download is done, then the FX2 resets itself to
> start running the new firmware. As part of this reset, the FX2 will
> "logically unplug" the USB connection from the host so it looks like a
> disconnect. When the new firmware starts, it reconnects to the host.
> The pvrusb2 driver then connects to it again, then it notes that
> there's
> no need for a firmware download this time, and initializes continues
> onward to completion.
>
> The reason for the USB disconnect / reconnect is that the new FX2
> firmware can present an entirely different USB configuration to the
> USB
> host - even different USB class / device IDs. It's effectively a
> different device when it reconnects. Cypress calls this trick
> "renumeration".
>
> Regarding your earlier reply, that all looks good. It appears that
> the
> hardware is responding and coming up correctly. There is one more
> thing
> that has to happen though - before the MPEG encoder can start
> streaming
> it also needs a firmware image. Without that you won't be able to
> stream. But you won't necessarily see that firmware download as part
> of
> the device's initialization because the pvrusb2 driver can download
> that
> image on-the-fly during operation. This ability is present for two
> reasons: (1) For hybrid tuners (i.e. analog + ATSC or DVB-T), the MPEG
> encoder firmware frequently needs to be re-sent when switching between
> digital vs analog modes (the MPEG encoder doesn't have to really do
> anything in digital mode). (2) There is a long-time issue with all
> these tuners where sometimes when the encoder is told to start
> streaming
> it will respond by instead going into a coma. The pvrusb2 driver
> detects this and responds by re-initializing the encoder chip and part
> of that step is a firmware re-download. This usually happens so fast
> that you won't even notice it unless you look at the kernel log (where
> messages about the re-initialization will be sent).
>
> So, try streaming from it and then look at your kernel messages and
> verify that things still look OK. Missing encoder firmware *might*
> explain the behavior you're seeing.
>
> -Mike
>
>
> On Mon, 10 Dec 2012, Helmut Jarausch wrote:
>
> > On 12/10/2012 06:15:31 PM, Christopher Cox wrote:
> > > On 12/10/2012 09:55 AM, Helmut Jarausch wrote:
> > > ...
> > > > What can I do to check if the device is broken or better to get
> it
> > > > working?
> > >
> > > If a firmware is loaded you should see a /sys/class/pvrusb2 dir
> with entries
> > > in it.
> > >
> > > Firmwares could go into many locations, I'd check /lib/firmwares
> or
> > > /usr/local/lib/firmwares... look for *pvrusb* entries.
> > >
> > > You have to follow the directions with regards to getting the
> firmware into
> > > those areas (just make sure it's a location actively searched for
> by your
> > > distro)...
> >
> > I have (put) the following files in /lib/firmware
> > v4l-cx2341x-enc.fw
> > v4l-pvrusb2-29xxx-01.fw
> >
> > The following entry in dmesg's output looks suspicious
> > [ 8201.451836] pvrusb2: V4L in-tree version:Hauppauge
> WinTV-PVR-USB2 MPEG2
> > Encoder/Tuner
> > [ 8201.451840] pvrusb2: Debug mask is 31 (0x1f)
> > [ 8201.481729] pvrusb2: Device microcontroller firmware (re)loaded;
> it should
> > now reset and reconnect.
> > [ 8201.492186] usb 5-3: USB disconnect, device number 2
> > [ 8201.492236] pvrusb2: Device being rendered inoperable
> > <<<<<<<<<<<<<<<<<<<<<<
> > but then it continues with
> >
> > [ 8203.210495] usb 2-3: new high-speed USB device number 3 using
> ehci_hcd
> > [ 8203.326157] usb 2-3: New USB device found, idVendor=2040,
> idProduct=2900
> > [ 8203.326165] usb 2-3: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [ 8203.326171] usb 2-3: Product: USB Device
> > [ 8203.326175] usb 2-3: Manufacturer: Hauppauge
> > [ 8203.326788] pvrusb2: Hardware description: WinTV PVR USB2 Model
> 29xxx
> > [ 8203.328006] pvrusb2: Binding ir_video to i2c address 0x18.
> > [ 8203.559203] saa7115 0-0021: saa7115 found (1f7115d0e100000) @
> 0x42
> > (pvrusb2_a)
> > [ 8203.710794] pvrusb2: Attached sub-driver saa7115
> > [ 8203.738861] msp3400 0-0040: MSP3415G-B8 found @ 0x80 (pvrusb2_a)
> > [ 8203.738867] msp3400 0-0040: msp3400 supports nicam and radio,
> mode is
> > autodetect and autoselect
> > [ 8203.738954] pvrusb2: Attached sub-driver msp3400
> > [ 8203.830783] tuner 0-0061: Tuner -1 found with type(s) Radio TV.
> > [ 8203.830796] pvrusb2: Attached sub-driver tuner
> > [ 8203.839786] tda9887 0-0043: creating new instance
> > [ 8203.839791] tda9887 0-0043: tda988[5/6/7] found
> > [ 8203.840781] tuner 0-0043: Tuner 74 found with type(s) Radio TV.
> > [ 8203.840795] pvrusb2: Attached sub-driver tuner
> > [ 8203.863273] tveeprom 0-0050: Hauppauge model 29039, rev D160,
> serial#
> > 8039400
> > [ 8203.863280] tveeprom 0-0050: tuner model is LG S001D MK3 (idx
> 60, type 38)
> > [ 8203.863285] tveeprom 0-0050: TV standards PAL(B/G) PAL(I)
> SECAM(L/L')
> > PAL(D/D1/K) (eeprom 0x74)
> > [ 8203.863289] tveeprom 0-0050: audio processor is MSP3415 (idx 6)
> > [ 8203.863293] tveeprom 0-0050: decoder processor is SAA7115 (idx
> 19)
> > [ 8203.863297] tveeprom 0-0050: has radio, has IR receiver, has no
> IR
> > transmitter
> > [ 8203.863310] pvrusb2: Supported video standard(s) reported
> available in
> > hardware: PAL-B/B1/D/D1/G/H/I/K;SECAM-B/D/G/H/K/K
> > [ 8203.863326] pvrusb2: Device initialization completed
> successfully.
> >
> > Furthermore I have in /sys/class/pvrusb2/sn-8039400 lots of files
> >
> > bus_info_str ctl_streaming_enabled
> > ctl_audio_bitrate ctl_stream_type
> > ctl_audio_crc ctl_treble
> > ctl_audio_emphasis ctl_usb_speed
> > ctl_audio_layer ctl_video_aspect
> > ctl_audio_mode ctl_video_b_frames
> > ctl_audio_modes_present ctl_video_bitrate
> > ctl_balance ctl_video_bitrate_mode
> > ctl_bass ctl_video_bitrate_peak
> > ctl_brightness ctl_video_chroma_median_filter_bottom
> > ctl_channel ctl_video_chroma_median_filter_top
> > ctl_contrast ctl_video_chroma_spatial_filter_type
> > ctl_cropcap_bounds_height ctl_video_gop_closure
> > ctl_cropcap_bounds_left ctl_video_gop_size
> > ctl_cropcap_bounds_top ctl_video_luma_median_filter_bottom
> > ctl_cropcap_bounds_width ctl_video_luma_median_filter_top
> > ctl_cropcap_pixel_denominator ctl_video_luma_spatial_filter_type
> > ctl_cropcap_pixel_numerator ctl_video_median_filter_type
> > ctl_crop_height ctl_video_spatial_filter
> > ctl_crop_left ctl_video_spatial_filter_mode
> > ctl_crop_top ctl_video_standard_mask_active
> > ctl_crop_width ctl_video_standard_mask_available
> > ctl_freq_table_channel ctl_video_standard_mask_detected
> > ctl_freq_table_value ctl_video_temporal_decimation
> > ctl_frequency ctl_video_temporal_filter
> > ctl_hue ctl_video_temporal_filter_mode
> > ctl_input ctl_volume
> > ctl_master_state device
> > ctl_mpeg_audio_mode device_hardware_description
> > ctl_mpeg_audio_mode_extension device_hardware_type
> > ctl_mute power
> > ctl_resolution_hor subsystem
> > ctl_resolution_ver uevent
> > ctl_saturation unit_number
> > ctl_signal_present v4l_minor_number
> > ctl_srate v4l_radio_minor_number
> >
> >
> > Thanks,
> > Helmut.
> > _______________________________________________
> > pvrusb2 mailing list
> > pvrusb2 at isely.net
> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>
Hi Mike,
first I have noticed that there are 2 different versions
of v4l-cx2341x-enc.fw, one of
length 376836 md5sum = 9b39b3d3bba1ce2da40f82ef0c50ef48
and another one of
length 262144 md5sum = 2c97465a4528807709301899630ba0e1
Now, I have used this second one.
Furthermore, stragely enough, I have to run xawtv once.
Although this doesn't show any video, a subsequent vlc does work!
I have traced the ioctl calls of xawtv, here they are:
open("/dev/video0", O_RDWR) = 4
ioctl(4, VIDIOC_QUERYCAP or VT_OPENQRY, 0x798370) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
ioctl(4, VIDIOC_ENUMINPUT, 0x7984a8) = 0
ioctl(4, VIDIOC_ENUMSTD, 0x7989a8) = 0
ioctl(4, VIDIOC_ENUM_FMT or VT_SETMODE, 0x798e28) = 0
ioctl(4, VIDIOC_G_PARM, 0x7983d8) = 0
ioctl(4, VIDIOC_QUERYCTRL, 0x799628) = 0
ioctl(4, VIDIOC_G_STD, 0x7fff1f1e0b20) = 0
ioctl(4, VIDIOC_G_INPUT, 0x7fff1f1e0b2c) = 0
ioctl(4, VIDIOC_G_TUNER, 0x7fff1f1e0ab0) = 0
ioctl(4, VIDIOC_G_CTRL, 0x7fff1f1e0b10) = 0
ioctl(4, VIDIOC_G_CTRL, 0x7fff1f1e0b20) = 0
ioctl(4, VIDIOC_S_FMT or VT_RELDISP, 0x79a748) = 0
ioctl(4, VIDIOC_G_FREQUENCY, 0x7fff1f1e0b50) = 0
Which one could be the important one?
Any other explanation?
Many thanks for a hint,
Helmut.
More information about the pvrusb2
mailing list