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

[Mike Isely]

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...)


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

You're not really risking much by opening it.  If you follow common
sense you should be fine.  Though obviousy I can't speak to the state
of the warranty afterwards however unless there are self-destructing
stickers over the screw holes it's pretty hard to tell that it's been
opened.


>
> it seems, from the debug, that the 8051 firmware is not needed.

That may be a correct assessment.  However, the pvrusb2 driver doesn't
know that.  It uses a test to figure out if the firmware needs to be
loaded and the test may not work for this device.  Way back when I was
only dealing with 29xxx devices, the driver made this decision based
on the USB configuration it saw - if it wasn't what was expected then
the driver would download the FX2 firmware.  However with the 24xxx
devices this trick stopped working.  So instead I changed the driver
to issue a command to the device that should always work if the
firmware is loaded and fail if it isn't.  However the test may be
specific to the Hauppauge-authored firmware so it may fail on your
device.  And obviously if it fails then it's going to try to load the
bad firmware.  So a change here that is needed is to immediately skip
any attempt to load the firmware if it recognizes your device.


> 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

I've heard of "hummingbird" as a term refering to another reference
design built around the cx23416 (or maybe it was "bluebird").  The
other term I have not heard.


>
> 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 think you may be correct.


>
> 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).


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

Good.


>
> indeed, during the second connect, the driver goes straight to the
> encoder firmware..

It is a mystery to me right now for why the pvrusb2 driver is making
different choices each time.  However I'm already suspecting that the
algorithm it is using to choose whether or not to upload the firmware
is probably flawed for this device.


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


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

Well true, but it's noise that should be removed.

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.

I should have some time next week to work on this if you want to send
me that log.


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

Ignore everything above this point.

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

Here the pvrusb2 driver is telling you which of the chip-level I2C client
drivers have attached to the pvrusb2 driver, and the pvrusb2 driver is
telling you some info about how it is communicating with each
chip-level driver.  Each line represents one module.  The first word
is the name of the module (as reported by the module).  The hex value
after the @ is the associated I2C address of the chip being
controlled.  The "handler" is an indication of any special logic in
the pvrusb2 driver that is talking to that driver.  The stuff in
square brackets indicates what classes of commands the pvrusb2 driver
is forwarding to the given module.  Basically the most interesting
parts here would be the name of the module and the I2C address.

What you are seeing here are 2 attached modules, and they are what we
had mentioned before.

These modules "attach" by attempting to detect "their" chip at the
other end of the bus.  If the detection succeeds, the module will
attach.  This is why you don't see the tuner or tda9887 modules
showing up here, since your hardware doesn't have an RF section those
modules are not needed.  The wm8775 module is probably showing up
erroneously, but that's because the pvrusb2 driver generates a false
positive on that detection attempt (because the chip is other
undetectable).  What we need to do there is disable the false positive
if it's your device we're dealing with.  Do that and the module will
cease trying to operate with the pvrusb2 driver for your hardware.


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

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.


>
> 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 understand completely.  I'm busy with something like 5 different
things right now (the others are not V4L related), and I've been
time-slicing amoung it all :-)


> i'll keep you posted.

OK.

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