[pvrusb2] PARTIAL SUCCESS Re: terratec grabster av400.. short report..
Andrea Venturi
a.venturi at cineca.it
Sun Mar 18 14:22:21 CDT 2007
Mike Isely wrote:
>>
>> i had to change just one line to fake a Hauppauge 24xxxx
>>
>> pvrusb2-hdw.c: [PVR2_HDW_TYPE_24XXX] = { USB_DEVICE(0x0ccd, 0x0039) },
>
> Yes, that is pretty much what Mike Krufky first suggested and what I
> hoped you'd try.
>
>
>> and put these three files inside the firmware directory:
>>
>> ...$ls -l /usr/lib/hotplug/firmware/v4l*
>> -rw-r--r-- 1 root root 376836 2007-03-16 12:37
>> /usr/lib/hotplug/firmware/v4l-cx2341x-enc.fw
>
> That's the encoder firmware.
>
>
>> -rw-r--r-- 1 root root 16382 2007-03-16 12:37
>> /usr/lib/hotplug/firmware/v4l-cx25840.fw
>
> That's the firmware for the cx25840 audio/video processing chip. It's
> only needed for 24xxx devices and not 29xxx devices (which use a
> different pair of parts for this role).
you can see a close-up shot of the naked board from the terratec site here:
http://www.terratec.it/prodotti/video_editing/grabster_av400/board.JPG
anyway i hope my box has the same HW inside. i didn't open it
actually,because i'm going that path only as a last resort.. i have too
much things to try before..
>
>> pvrusb2: cpureset_assert(1) error=-19
>> pvrusb2: cpureset_assert(0) error=-19
>> pvrusb2: Failure uploading firmware1
>> pvrusb2: ***WARNING*** pvrusb2 device hardware appears to be jammed and
>> I can't clear it.
>> pvrusb2: You might need to power cycle the pvrusb2 device in order to
>> recover.
>
> This is bad. It's an attempt by the pvrusb2 driver to load the FX2
> firmware. The attempt failed. This is the sort of thing where I
> would have expected trouble.
>
> Now, if your device's FX2 firmware is instead being loaded from a
> local ROM in the device, then this is not necessarily fatal. The
> device might still work. However even if that is the case, then
> there's still some work needed here because we have to teach the
> pvrusb2 driver not to attempt to download to such a device.
it seems, from the debug, that the 8051 firmware is not needed.
================
Linux video capture interface: v2.00
usbcore: registered new driver pvrusb2
/usr/local/src/andrea/v4l/v4l-dvb/v4l/pvrusb2-main.c: Hauppauge
WinTV-PVR-USB2 MPEG2 Encoder/Tuner : V4L in-tree version
/usr/local/src/andrea/v4l/v4l-dvb/v4l/pvrusb2-main.c: Debug mask is 8195
(0x2003)
usb 5-5: new high speed USB device using ehci_hcd and address 3
usb 5-5: configuration #1 chosen from 1 choice
pvrusb2: pvr2_upload_firmware1
pvrusb2: Located fx2 controller firmware: v4l-pvrusb2-24xxx-01.fw;
uploading...
pvrusb2: cpureset_assert(1) error=-71
pvrusb2: Upload done, releasing device's CPU
pvrusb2: cpureset_assert(0) error=-71
pvrusb2: Upload done (-284 bytes sent)
pvrusb2: Failure uploading firmware1
pvrusb2: ***WARNING*** pvrusb2 device hardware appears to be jammed and
I can't clear it.
pvrusb2: You might need to power cycle the pvrusb2 device in order to
recover.
usb 5-5: USB disconnect, address 3
usb 5-5: new high speed USB device using ehci_hcd and address 4
usb 5-5: configuration #1 chosen from 1 choice
usb 5-5: reset high speed USB device using ehci_hcd and address 4
pvrusb2: pvr2_upload_firmware2
pvrusb2: Located encoder firmware: v4l-cx2341x-enc.fw; uploading...
pvrusb2: upload of v4l-cx2341x-enc.fw : 376836 / 376836
==========
maybe the 8051 code is on a rom inside the box, as you say, waiting only
to be waken up by the driver..
as i told in the first report, in the .inf file of the driver i can see
some reference of two 8051 codes:
- hmngbrd.bix
- Eagle.bix
but there's no trace of them in the windows drivers directory, they
could be present in different designs (like those from yuan and conexant
python..) but maybe the terratec doesn't need it.
i don't see sign of the upload of the firmware for the cx25840..
>
> It's also possible that the device doesn't have a ROM, but if you do
> not power cycle it after running it in Windows but before starting it
> in Linux, then the needed firmware will likely still be loaded -
> because the Windows driver had previously loaded it. That's a nice
> trick to get past this sort of problem, at least temporarily. (It's
> also a step in the manual firmware extraction process.)
actually i have tried always from cold start.
>>
>> anyway, i get the /dev/video0 entry in the /dev directory..
>
> *THAT* is very puzzling.
>
> If the driver fails to load the FX2 firmware, it will give up. So I'm
> not sure how it could have gotten far enough to produce a /dev entry.
>
> Now it is possible for the driver to decide it doesn't have to load
> the FX2 firmware, in which case that step is skipped and the rest of
> the initialization proceeds. So the only thing I can think of is a
> scenario like this:
>
> 1. Plug in device.
>
> 2. Driver creates a context, decides to load the FX2 firwmare, fails
> and gives up.
>
> 3. Device disconnects.
>
> 4. Device reconnects.
>
> 5. Reconnection causes the driver to start from scratch - but this
> time for some reason it decides that the FX2 firmware is not needed
> and initialization continues.
>
==========
usb 5-5: USB disconnect, address 3
usb 5-5: new high speed USB device using ehci_hcd and address 4
usb 5-5: configuration #1 chosen from 1 choice
usb 5-5: reset high speed USB device using ehci_hcd and address 4
pvrusb2: pvr2_upload_firmware2
pvrusb2: Located encoder firmware: v4l-cx2341x-enc.fw; uploading...
pvrusb2: upload of v4l-cx2341x-enc.fw : 376836 / 376836
cx25840 0-0044: cx25837-23 found @ 0x88 (pvrusb2_a)
==========
indeed, during the second connect, the driver goes straight to the
encoder firmware..
BTW, i got another firmware 262K long, from replaying the windows driver
connect and your scripts (usbreplay and decode firmware), and i used it.
it works too..
>>
>> SO NOW THIS IS A SUCCESS STORY! :-)
>>
>> now, i can already get a black and white video from the composite input
>> of the grabster av400! hurrah..
>
> Nice.
>
>
>>
>> now i get these more info in dmesg:
>>
>> == dmesg ============================
>> cx25840 0-0044: cx25837-23 found @ 0x88 (pvrusb2_a)
>> wm8775 0-001b: chip found @ 0x36 (pvrusb2_a)
>> wm8775 0-001b: I2C: cannot write 000 to register R23
>> wm8775 0-001b: I2C: cannot write 000 to register R7
>> wm8775 0-001b: I2C: cannot write 021 to register R11
>> wm8775 0-001b: I2C: cannot write 102 to register R12
>> wm8775 0-001b: I2C: cannot write 000 to register R13
>> wm8775 0-001b: I2C: cannot write 1d4 to register R14
>> wm8775 0-001b: I2C: cannot write 1d4 to register R15
>> wm8775 0-001b: I2C: cannot write 1bf to register R16
>> wm8775 0-001b: I2C: cannot write 185 to register R17
>> wm8775 0-001b: I2C: cannot write 0a2 to register R18
>> wm8775 0-001b: I2C: cannot write 005 to register R19
>> wm8775 0-001b: I2C: cannot write 07a to register R20
>> wm8775 0-001b: I2C: cannot write 102 to register R21
>
> The wm8775 is a little I2C-hosted ADC audio & routing part used in the
> 24xxx devices. Probably you don't have one of these. It's impossible
> to automatically detect this chip, so if the pvrusb2 driver thinks it
> is talking to a 24xxx device, then it will arrange for the wm8775 to
> be "detected" through a sort of a hack. This is a side effect of you
> "borrowing" the 24xxx configuration. Not a big deal.
in the final driver for the terratec will be removed, but until i get
complete functionalities, it will stay as it is.. it should not do any
harm..
>
>> cx25840 0-0044: Video signal: not present
>> cx25840 0-0044: Detected format: NTSC-M
>> cx25840 0-0044: Specified standard: automatic detection
>> cx25840 0-0044: Specified video input: Composite 7
>> cx25840 0-0044: Specified audioclock freq: 48000 Hz
>
> Nice. Your device apparently has a cx25840. Unlike the wm8775 chip,
> this part *is* auto-detected.
>
yes. it's a cx25840
> This set of messages is interesting - it confirms that the driver
> thinks it initialized correctly. I'm starting to think my earlier
> guess is correct. The pvrusb2 driver probably tried to start twice.
> The first time it crashed and burned when it could not load the FX2
> firmware; the second time it either managed to load that firmware
> (which I highly doubt) or the device didn't need the firmware and the
> driver managed to skip that step, at least the second time.
yes, i think too the second time is skipping to try to load the fx2
firmware and going straight to the encoder firmware..
>
> I think your guess there is still correct. You can also dump the
> value(s) back from sysfs and confirm that it set the standard you
> wanted.
>
> Also, there's a little trick you can do:
don't know how to read this stuff:
>
> cat /sys/class/pvrusb2/*/debuginfo
andrea at nb-venturi:~$ cat /sys/class/pvrusb2/unit-a/debuginfo
big lock free; ctl lock free
driver flags: initialized ok connected
Subsystems enabled / configured: +ENC_FIRMWARE
Subsystems disabled / unconfigured: -ENC_CFG -DIG_RUN -USB_RUN -ENC_RUN
Attached I2C modules:
cx25840 @ 0x44 (handler: pvrusb2-cx2584x-v4l) [v4l2_standard
v4l2_audiomode v4l2_bcsh v4l2_volume v4l2_freq v4l2_size v4l2_log]
wm8775 @ 0x1b (handler: pvrusb2-wm8775) [v4l2_standard v4l2_audiomode
v4l2_bcsh v4l2_volume v4l2_freq v4l2_size v4l2_log]
then dmesg reports the usual stuff.
========= dmesg ===============
........
pvrusb2: ================= START STATUS CARD #0 =================
cx25840 0-0044: Video signal: not present
cx25840 0-0044: Detected format: PAL-BDGHI
cx25840 0-0044: Specified standard: automatic detection
cx25840 0-0044: Specified video input: Composite 7
cx25840 0-0044: Specified audioclock freq: 48000 Hz
wm8775 0-001b: Input: 2
pvrusb2: cx2341x config:
pvrusb2: Stream: MPEG-2 Program Stream
pvrusb2: VBI Format: No VBI
pvrusb2: Video: 720x480, 30 fps
pvrusb2: Video: MPEG-2, 4x3, Variable Bitrate, 6000000, Peak 8000000
pvrusb2: Video: GOP Size 12, 2 B-Frames, GOP Closure
pvrusb2: Audio: 48 kHz, Layer II, 224 kbps, Stereo, No Emphasis, No CRC
pvrusb2: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D
Horizontal, 0
pvrusb2: Temporal Filter: Manual, 8
pvrusb2: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
pvrusb2: ================== END STATUS CARD #0 ==================
===============================
>
> Aha, seems you found the trick (or used another tool to trigger the
> same dump). This is what I was talking about. Notice how cx25840 is
> reporting PAL-BDGHI now. So your attempt to change the standard did
> have an effect.
>
yes but it seems there's some glitch in the wiring or the input
because the image stays in black & white
if i try all the inputs available
andrea at nb-venturi:/sys/class/pvrusb2/unit-a$ cat ctl_input/enum_val
television
s-video
composite
radio
i get different inputs:
television = cx25840 0-0044: Specified video input: Composite 7
s-video: cx25840 0-0044: Specified video input: S-Video (Luma In1,
Chroma In5)
composite: cx25840 0-0044: Specified video input: Composite 3
if i could move the composite config to Composite In1 (where the s-video
config get the luminance), i think i could get a color image..
is it difficult to change this config?
>>
>> BTW, i don't see "transport stream" in the pack of streaming type.. so
>> it's missing on purpose because it's not a hardware thing but just a
>> software made container, or there's something more to do to get it?
>>
>> andrea at nb-venturi:/sys/class/pvrusb2/unit-a$ cat ctl_stream_type/enum_val
>> MPEG-2 Program Stream
>> MPEG-1 System Stream
>> MPEG-2 DVD-compatible Stream
>> MPEG-1 VCD-compatible Stream
>> MPEG-2 SVCD-compatible Stream
>>
>>
>> now what to do?
>
> That I might not be able to help much on. The creation of the mpeg
> data is being done in hardware in the device - in the cx23416 chip.
> The only specific formats available are those programmed into the
> firmware of that part. The list you see there is from
> reverse-engineering work that has been done on the part by the ivtv
> maintainer.
>
> However MPEG-PS and MPEG-TS are variations of one another. I presume
> that if you can get an MPEG-PS you could probably post-process it into
> an MPEG-TS. The payload data is the same; it's just the packaging
> that is going to be a little different.
>
>
yes, if the video elementary stream is CBR enough, there should not be
too hassle to move from one container (PS) to the other (TS)
>
>
>> i have a bunch of questions, maybe i could just wade in the code
>> tomorrow, or i can do some educated question today.
>>
>> - in the beginning, wrong firmware ? which one mpeg encoder or video
>> decoder?
>
> The problem happened with the FX2 firmware. The other firmware images
> appear to have loaded OK - not a suprise because the FX2 firmware is
> specific to the 24xxx Hauppauge device while the other firmware images
> are more generic.
>
>
>> - i should raise the level of the debug to get a better idea of stuff going?
>
> Yes. Definitely. See the usage documentation for tips on how to do
> this (there are a number of ways you can do this).
>
>
>> - i should begin to "make up" a clean entry for this terratec?
>
> Well there's nothing wrong with experimentation.
>
> One thing that would help is if you could remove the cover and take a
> digital photo of the board. Make it as clear as possible so that chip
> numbers can be read. Examples of what I'm talking about can be found
> here:
>
> http://www.isely.net/gallery2/v/PVR+Hardware/
>
> That would provide a lot of guidance about what might need to be done
> here.
see the first link. it's not my own shot, but it should be reliable
>
>
>> all in all, it seems it's just a matter of tweaking the right bits
>> (GPIO?) in the right registers.. but i'll need to proceed with trial and
>> error or there a cleaner path?
>
> There's actually not a lot of specific GPIO signals that are tweaked
> in the pvrusb2 driver. Details like that (except for the cx23416) are
> left to V4L-hosted chip level drivers.
>
> The B&W video may be a configuration issue not strictly related to the
> video standard. The cx25840 has multiple video inputs and they may be
> probably wired differently on your device than on the PVR USB2
> device. The chrominance and luminance inputs can be split (to support
> s-video), so while you might have told the driver to select composite,
> the theoretically different wiring might have resulted in the
> chrominance component of the video signal getting lost. Just a
> guess. It's also still very likely that a video standard misconfig is
> causing this.
i need to dig better the code with some time
the problem is that i have two little daughter so not so much time to tweak.
i'll keep you posted.
bye
andrea venturi
>
>
>> anyway, thank you again for this driver. it's really a wonderful
>> project, and not only for the quality of the source code, but it's
>> really all about the carefulness of the maintainer
>
> Thanks.
>
> I've been a Linux user for about 13 years now. But I haven't been
> much of a contributor (aside from the odd small kernel patch here and
> there). One thing that got me into this was that perhaps it was time
> to give something back :-)
>
> -Mike
>
More information about the pvrusb2
mailing list