[pvrusb2] PARTIAL SUCCESS Re: terratec grabster av400.. short report..
Mike Isely
isely at isely.net
Fri Mar 16 22:47:52 CDT 2007
Lots of comments interspersed.
Andrea Venturi <a.venturi at cineca.it> wrote:
>
> hoo mike..
> first of all, i just have to tell that the care you are giving to your
> "customers" is SO complete that it is simply overwhelming my expectation.
>
> i'm a long time user of free software and completely sold to this
> win-win community attitude (think positive) and i daily struggle to make
> my management aware of the big advantages of the free (as freedom)
> software strategy and the subtle social implications of this way of
> think and act in a truly cooperative mood and i believed to be quite
> accustomed to the community standard "SLA" but your words are so clear
> and so positive expecially for a simple clueless unknown user like me
> that i am without better words to tell you my gratefulness.
Actually, I hate writing documentation. Really. I'd rather code.
But I also learned early on that the best way to keep from being asked
the same questions over and over again is to try to be as thorough as
possible with the documentation. And yet at the same time, try to
structure the docs so that someone can quickly drill down to where the
needed information can be found. It's not easy doing that. It's kind
of like correctly structuring a software architecture actually. (But
I still hate writing documentation.)
The documentation you are seeing is roughly the 3rd time I've written
it. The first time was a single flat-ASCII readme file. When I set
up the web site, I spread things out a bit. Then as people asked
questions, I kept refining the documentation to cover these new cases
/ scenarios that people tended to hit. Unfortunately that eventually
turned into a big thick impenetrable pile. I also realized over time
that there were things I was dwelling on that were becoming less of an
issue over time and just served to obfuscate the real info people kept
asking about. So then a while back I restructured all the
documentation into the form you see there. I set up an outline,
arranged into a logical procession with successive layers of detail.
Then I just filled it in, liberally sprinkling cross-links where I
thought it made sense.
I haven't had too many complaints about the documentation being too
complicated since the last rework. Generally I find that people who
have complained about the complexity of the documentation usually
haven't read very far into it and realized how it is organized.
For those that still ask me questions that I know are already
answered, I try instead to gently nudge them back towards the
documentation, usually with a link that goes straight to the issue
being asked about. And in other cases I answer the question - and
then see how I can work that answer back into the documentation in a
logical spot.
>
> now stop the chat and get down to business..
>
> i have read more carefully your web pages and they are indeed packed of
> informations to a such level and consistence unbelievable.
>
> expecially when one thinks the really long chain of ever changing
> packages involved!!
>
> kernel - v4l-dvb - ivtv -pvrusb2
>
> when i wrote my first email, i didn't understand completely that i
> already had on my disk two complete pvrusb2 stacks:
>
> - the 2.6.18 kernel
> - the v4l-dvb 24.2.07 tree
>
> but i have been acting as everyone in the free software frenzyness.. get
> the latest. what a newbie error! :-)
>
> now i'm getting back to try to patch and user the pvrusb2 of the v4l-dvb
> tree (because i'm already using other linux dvb drivers like cinergy
> pinnacle and animation..)
>
> and i have to tell, things are going a lot better..
>
> 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).
>
> -rw-r--r-- 1 root root 8192 2007-03-16 12:37
> /usr/lib/hotplug/firmware/v4l-pvrusb2-24xxx-01.fw
That's the FX2 microcontroller firmware. It's very specific to the
Hauppauge PVR USB2 24xxx series devices. This is the firmware that I
said earlier may be a problem for you.
The "FX2" is a Cypress part. It has an 8051 architecture processing
core glued to a USB 2.0 hi-speed device interface, and some crazy
logic for automating block transfers between itself and an outside
chip. This chip is the key to what makes your device a USB device.
>
>
> bingo. when i connect the terratec grabster av400 i get a warm green
> light on the device..
>
> these are the modules involved:
>
> == lsmod =================================
> Module Size Used by
> wm8775 5516 0
> tuner 53288 0
> cx25840 22416 0
> pvrusb2 138068 0
> cx2341x 10820 1 pvrusb2
> videodev 26624 1 pvrusb2
> v4l2_common 15808 5 tuner,cx25840,pvrusb2,cx2341x,videodev
> v4l1_compat 11908 2 pvrusb2,videodev
> tveeprom 13520 1 pvrusb2
> i2c_core 20496 5 wm8775,tuner,cx25840,pvrusb2,tveeprom
> michael_mic 2496 2
> =========================================
No idea what "michael_mic" is. The rest are what I'd expect to see
for a 24xxx device.
>
> these are the relevant entries in dmesg
>
> == dmesg =================================
> usb 5-5: new high speed USB device using ehci_hcd and address 3
> usb 5-5: configuration #1 chosen from 1 choice
> 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 15 (0xf)
> usb 5-5: USB disconnect, address 3
> 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'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.)
> 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
> ==========================================
>
> anyway, the device get the same VID/PID on lsusb
>
> == lsusb ===========
> Bus 005 Device 004: ID 0ccd:0039 TerraTec Electronic GmbH
> ====================
>
> i see too these errors WRT:
>
> - cpu assert (!)
> - uploading firmware1 (what's this? mpeg encoder or video decoder?)
> - jammed device
>
>
> 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.
Getting more log messages will verify if this sort of scenario is
happening. I suggest you just turn on all the bits for for and
capture the results. Don't try to capture any video yet this way -
the log will get MB of data then.
>
> nb-venturi:/home/andrea/src/v4l/v4l-dvb# ls -l /dev/video0
> crw-rw---- 1 root video 81, 0 2007-03-16 22:27 /dev/video0
>
> as explained in the web pages, i have been able to do:
>
> cat /dev/video0 > test.mpg
>
> for a few seconds and i get a real mpeg ps file. at least, mplayer tell
> me so:
>
> == mplayer log ==========================
> ....
> ==> Found video stream: 0
> ==> Found audio stream: 0
> MPEG Stream reached EOF
> ds_fill_buffer: EOF reached (stream: video)
> MPEG-PS file format detected.
> Searching for sequence header... OK!
> VIDEO: MPEG2 720x480 (aspect 2) 25.000 fps 8000.0 kbps (1000.0 kbyte/s)
> [V] filefmt:2 fourcc:0x10000002 size:720x480 fps:25.00 ftime:=0.0400
> ...
> Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
> dec_audio: Allocating 4608 + 65536 = 70144 bytes for output buffer.
> mp3lib: made decode tables with MMX optimization
> mp3lib: using SSE optimized decore!
> MP3lib: init layer2&3 finished, tables done
> MPEG 1.0, Layer II, 48000 Hz 224 kbit Stereo, BPF: 672
> Channels: 2, copyright: No, original: No, CRC: No, emphasis: 0
> AUDIO: 48000 Hz, 2 ch, s16le, 224.0 kbit/14.58% (ratio: 28000->192000)
> Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
> ==========================================================================
If you've gotten this far, then you've gotten most of the hardware
working with this driver. Still a lot of rough edges to tune here,
and I'm very puzzled about how you could have gotten this if the
driver suffered a failure on attempt to load the FX2 firmware.
>
>
> the standard input is television (still related to the hauppauge: in
> this device there's no tuner; maybe we'll purge it later..)
>
> andrea at nb-venturi:~$ cat /sys/class/pvrusb2/unit-a/ctl_input/cur_val
> television
Yup.
>
> but if put a source in the composite input, and if i set the ctl_input
> to s-video (!) i can get in the mpeg ps file a good black and white
> recording.
>
> andrea at nb-venturi:~$ echo s-video >
> /sys/class/pvrusb2/unit-a/ctl_input/cur_val
> andrea at nb-venturi:~$ cat /sys/class/pvrusb2/unit-a/ctl_input/cur_val
> s-video
>
> 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.
> tveeprom 0-0051: Encountered bad packet header [00]. Corrupt or not a
> Hauppauge eeprom.
> pvrusb2: WARNING: Failed to identify any viable standards
> pvrusb2: Unable to select a viable initial video standard
This could be an annoying problem. The "real" Hauppauge device
includes a little I2C serial ROM which encodes information about the
device. The pvrusb2 driver (via the tveeprom module) reads this ROM
to determine things like supported video standards, tuner type, serial
number, etc. You don't care about tuner type, but the video standard
may be an issue. You can override the list of available video
standards in the driver via a module load option (see the usage docs
for information about this). IIRC you can also override the list of
available video standards via sysfs as well (but my memory is a bit
fuzzy there).
> wm8775 0-001b: I2C: cannot write 0c0 to register R21
> 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 102 to register R21
> wm8775 0-001b: I2C: cannot write 0c0 to register R21
> 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 102 to register R21
> wm8775 0-001b: I2C: cannot write 0c0 to register R21
> 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 102 to register R21
> 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.
> wm8775 0-001b: Input: 2
> pvrusb2: Device initialization completed successfully.
> pvrusb2: registered device video0 [mpeg]
> pvrusb2: registered device radio0 [mpeg]
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.
> wm8775 0-001b: I2C: cannot write 0c0 to register R21
> wm8775 0-001b: I2C: cannot write 1d4 to register R14
> wm8775 0-001b: I2C: cannot write 1d4 to register R15
> 0-001b: I2C: cannot write 102 to register R21
> wm8775 0-001b: I2C: cannot write 0c0 to register R21
> 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 102 to register R21
> =============================
>
> it's such an easy task to program this device thru the /sys/ fs and with
> such rewarding, that i'd like to test the PAL setting
>
> and i'm wrong again.. :-)
>
> i tried some of these settings..
>
> echo "PAL-B/G" > ctl_video_standard_mask_available/cur_val
> echo "PAL-B/G"> ctl_video_standard/cur_val
>
> but with always a black and white image..
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:
cat /sys/class/pvrusb2/*/debuginfo
That will dump a list of I2C chip-level drivers that have connected to
the driver. That's useful info - but even more useful is that as a
side effect that command will ask all of those chip-level drivers to
issue a debug dump into the system log. You should for example see
another blob of data from the cx25840 - including it's idea of the
video standard, giving you another way to see if the standard you
tried to set actually "took".
>
> anyway, it's enough for today (23.44 local time..)
>
> i just can see these more info on dmesg
>
> == dmesg ======================
> pvrusb2: ================= START STATUS CARD #0 =================
> cx25840 0-0044: Video signal: present
> cx25840 0-0044: Detected format: PAL-BDGHI
> cx25840 0-0044: Specified standard: automatic detection
> cx25840 0-0044: Specified video input: S-Video (Luma In1, Chroma In5)
> 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, 25 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, 0
> 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.
> pvrusb2: ***WARNING*** device's encoder appears to be stuck
> (status=0x00000003)
> pvrusb2: Encoder command: 0x81
> pvrusb2: Giving up on command. It is likely that this is a bad idea...
> pvrusb2: Error recovery initiated
> pvrusb2: Retrying device reconfiguration
Don't worry about this one. It's a known but currently benign issue.
Sometimes the cx23416 stops talking to the driver. The driver
recovers by kicking it in the teeth, uh, I mean reloading its
firmware. It's kind of clunky to do that, but it always works, and
this sort of problem only ever happens when streaming is started (thus
it doesn't happen in the middle of streaming thus no glitching).
> =================================
>
> 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.
>
> 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.
>
> 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.
>
> 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
--
| Mike Isely | PGP fingerprint
Spammers Die!! | | 03 54 43 4D 75 E5 CC 92
| isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| |
More information about the pvrusb2
mailing list