Mike Isely wrote: > Andrea Venturi <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]): 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 >> >> [EMAIL PROTECTED]:/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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
