[pvrusb2] PARTIAL SUCCESS Re: terratec grabster av400.. short report..
a.venturi at cineca.it
Fri Mar 23 05:25:41 CDT 2007
Mike Isely wrote:
> Andrea Venturi <a.venturi at cineca.it> wrote:
>> Mike Isely wrote:
>> you can see a close-up shot of the naked board from the terratec site here:
> That photo is not bad. The major part numbers are fairly visible.
> Looks like a cx23416 combined with a cx2584x, driven by an FX2 (the
> large chip in the lower right). I'm somewhat curious about the
> smaller chip in the lower left corner next to the USB jack, but it
> might be some kind of PHY for the USB in which case we don't care. (I
> learned to take notice of any chip on the PVR USB2 devices which is
> more than about 3 pins...)
i opened mine. it's a bit newer
the three main chips are:
the little chip behind the USB port is called Philips 74HC74D, from
internet is a "Dual D-type flip-flop with set and reset; positive-edge
the memoy is an Etrontech EM638325TS-6G (8MB at 166MHz):
and, wrote in white on the board, i can read BMP-837 REV 1.1
>> i don't see sign of the upload of the firmware for the cx25840..
> Oh that's definitely happening. The pvrusb2 driver doesn't directly
> upload this part. Rather, it's done by the cx25840.ko module itself.
> So you won't see any references to that firmware in the driver. The
> upload is performed via I2C transfers. The Hauppauge Windows driver
> uses a special USB endpoint for these transfers which is how the
> decode_log tool can pick off that data. But since it's just I2C
> traffic, such an upload doesn't strictly require using a special
> endpoint - in fact the cx25840 module just uses normal I2C transfers
> to accomplish the same thing. So if the Windows Terratec driver is
> doing that same sort of thing, then the transfers will be, well,
> "hidden in plain sight".
> If you can send me or post somewhere the USB Snoop log output (bzip2
> it first to get it down to a semi-reasonable size), I can probably
> find the point where the cx25840 firmware upload is happening. We're
> probably going to need to identify and extract that firmware because
> your device is using a newer chip and I've been told that it might now
> work correctly with the older known cx25840 firmware floating around
> (though I doubt this would explain the B&W video issue).
here you can find the dump of a full startup of the device: a 1MB log
compressed in 125KB
>> 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..
> Yes, that sounds like the cx23416 firmware. Recently it's been
> discovered that this firmware image does not have to be exactly
> 256KB. Good job grabbing it.
you can make yourself that firmware (with usbreplay & decode_log), or
you can get mine from here:
> If you can send me the USB snoop log (the data *before* it is fed to
> decode_log) plus (if you haven't already) the USB vendor and device ID
> for this device, I can probably quickly take a first cut at a set of
> driver changes that should work a lot better for your device. Then
> you can try that and we can fine-tune the results.
this is the device ID:
Bus 005 Device 008: ID 0ccd:0039 TerraTec Electronic GmbH
>> 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
>> 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?
> It's not difficult to change; the trick is knowing what to change it
> The cx25840 has a number of possible inputs. Some are composite and
> some are paired in such a way to form an s-video input. The wiring
> and pairing depends on the surrounding circuits. Obviously this is
> different in your case. The pvrusb2 driver assumes the wiring present
> in the Hauppauge hardware of course and that assumption is probably
> wrong here. Very likely what's happening is that we need to change
> this for your hardware. Unfortunately there's going to be some
> guesswork here and it's hard to explain concisely in an e-mail.
maybe i can proceed quickly by trial and error, supposed that making
some mistake doesn't panic the kernel! :-)
More information about the pvrusb2