[pvrusb2] PARTIAL SUCCESS Re: terratec grabster av400.. short report..

[Andrea Venturi]

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:
>>
>>   http://www.terratec.it/prodotti/video_editing/grabster_av400/board.JPG
> 

> 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:

 cy7c68013a
 cx23416-22
 cx25837-44

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
trigger"

the memoy is an Etrontech  EM638325TS-6G (8MB at 166MHz):

http://etron.com/img/pdf/SDRAM/64Mb/2Mx32/Em638325(Rev%200.8).pdf

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

 http://mhplab.cineca.tv/grabster-usbsnoop.log.bz2


> 
>> 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:

  http://mhplab.cineca.tv/firmware_file


> 
> 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:

$lsusb
...
 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
>> 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?
> 
> It's not difficult to change; the trick is knowing what to change it
> to.
> 
> 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! :-)


bye

andrea venturi