[pvrusb2] HVR-1950 on the SheevaPlug (Ubuntu Jaunty)

[Mike Isely]

On Wed, 27 May 2009, charleswgreenjr at aim.com wrote:

> 
> Hi all,
> 
> 
> 
> I'm attempting to get an HVR-1950 running on the new SheevaPlug, a 
> miniature server with an ARM processor (see 
> http://www.marvell.com/products/embedded_processors/developer/kirkwood/sheevaplug.jsp 
> for more details).? It's running Ubuntu Jaunty, I've extracted the 
> necessary firmware into /lib/firmware, and I have a kernel with the 
> following drivers compiled in:
> 
> 
> 
> pvrusb2
> 
> dvb_core
> 
> cx2341x
> 
> tveeprom
> 
> v4l2_common
> 
> videodev
> 
> v4l1_compat
> 

Compiled in?  OK, that should work.  So everything should be loaded and 
good to go.


> 
> 
> I also have my "official" MythTV Intel box, currently running Ubuntu 
> Hardy, with a newer (2.6.28) kernel, which successfully handles the 
> tuner, and I have a basic Intel Ubuntu Jaunty system which also 
> announces the tuner, loads firmware, etc. when I plug the tuner in, so 
> I believe that I understand the basics of getting this thing going.
> 

So far so good...

> 
> 
> However, when I plug the tuner into the SheevaPlug, here's all I see on the kernel log:
> 
> 
> 
> usb 1-1.3: new high speed USB device using orion-ehci and address 5
> usb 1-1.3: configuration #1 chosen from 1 choice

The pvrusb2 driver is not being associated with the hardware.

Detection of the hardware is handled by the USB core not the driver.  
When a new USB device is found (as you see has happened above), the 
device's ID information (USB class id, manufacturer id, product id, 
possibly various other bits) are queried from the device.  This 
information is used to perform a lookup into a local database which if 
found will tell your system which driver is supposed to handle it.  
That driver is then loaded (if not already loaded) and an entry point is 
called with a handle to the new USB device.  At this point the driver 
takes over and initializes the hardware.

Since you've compiled it in, then there's nothing to actually load, but 
the driver still has to be called in order to start initializing the 
device.

I'm used to testing with the driver compiled as a module (relinking the 
entire kernel every time I test a simple change would just be 
impractical).  In that case the database of IDs is a thing compiled and 
kept up to date by the "depmod" utility and I believe udev does the 
actual lookup.  Last time I tested the driver compiled-in this all "just 
worked" but it's been a while.  On the other hand there's simply nothing 
about the driver that should care whether or not it's compiled in or a 
module since all the mechanics that differentiate the two cases are 
really outside the driver anyway.

Do you know if udev is set up on your SheevaPlug?  (I'd have to think 
it is.)

Just as a test, can you plug in a USB flash key or hard drive and verify 
that the mass-storage driver gets associated with it?  The mechanism 
that does this is the same as for the pvrusb2 driver.


> 
> When I plug the tuner into either of the Intel boxes, I get quite a bit more:
> 
> [? 593.490018] usb 1-4: new high speed USB device using ehci_hcd and address 2
> [? 593.644339] usb 1-4: configuration #1 chosen from 1 choice
> [? 593.698637] Linux video capture interface: v2.00
> [? 593.763880] usbcore: registered new interface driver pvrusb2


> [? 593.763905] pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner

This is the message you see when the pvrusb2 driver first gets loaded 
into memory and its global init function called.  You should see a 
similar message on your SheevaPlug - though since you've compiled it 
into the kernel the message will probably print much earlier, at system 
boot time not when the device appears (try looking for it).  This 
message is not in response to a device appearing but rather the driver 
itself being initialized.  Thus you will see it happen "late" when the 
driver is built as a module and "early" when it is compiled into the 
kernel.


> [? 593.763910] pvrusb2: Debug mask is 31 (0x1f)


> [? 594.760164] usb 1-4: firmware: requesting v4l-pvrusb2-73xxx-01.fw

At this point (for your Intel scenario of course) we know the driver is 
talking to the hardware.  This is the first thing that will happen (for 
Hauppauge devices) when bringing up a newly-attached device: It's 
loading the device's microcontroller firmware.  Note that even if you 
forgot to install the firmware in your system you should still see this 
message (following shortly thereafter by a failure report).

> [? 594.781660] pvrusb2: Device microcontroller firmware (re)loaded; it should now reset and reconnect.

And this reports that the firmware load was successful.  What happens 
next is that the pvrusb2-driven device will reset itself so it can start 
running the new firmware.  This causes the device to electrically unplug 
itself from the host and then reappear.


> [? 596.328962] usb 1-4: USB disconnect, address 2

This is the device "unplugging" itself.


> [? 596.329440] pvrusb2: Device being rendered inoperable

This is just the driver reacting to the above.


> [? 596.600019] usb 1-4: new high speed USB device using ehci_hcd and address 3
> [? 596.759694] usb 1-4: configuration #1 chosen from 1 choice

And here the device has reappeared to the host.  The pvrusb2 driver this 
time will detect that its microcontroller firmware is already loaded so 
it proceeds to the next few steps, which result in the other messages 
you printed below...


> [? 596.842134] cx25840' 1-0044: cx25843-24 found @ 0x88 (pvrusb2_a)
> [? 596.912732] tuner' 1-0042: chip found @ 0x84 (pvrusb2_a)
> [? 596.937121] tveeprom 1-00a2: Hauppauge model 75111, rev C3E9, serial# 5371386
> ...
> 
> 
> It appears from 'grep -l' that the 'Linux video capture interface' 
> messages should be coming from 'videodev' (at least in the Jaunty 
> case; I don't see this one line on my Hardy system, though the rest of 
> the log looks identical).

Yes, that message comes from the videodev module being loaded; it is a 
dependency for the pvrusb2 driver.  I believe it is also a global 
initialization so on your SheevaPlug it will probably be much earlier in 
the boot process.  Perhaps your dmesg buffer has rolled around.


> 
> 
> 
> Is it possible that some configuration related to USB is preventing 
> the firmware request from being received / processed?? Anything which 
> might prevent 'videodev' or 'usbcore' from doing their thing?

No, firmware doesn't come into the picture until after the pvrusb2 
driver has been associated with the hardware.

I think the key issue here is that you need to figure out why the 
pvrusb2 driver didn't get associated with the hardware.  Are you *sure* 
it's compiled into the kernel?

> 
> 
> 
> Thanks for any pointers / suggestions,
> 

Sorry about the delay.  I've been distracted with non-driver issues 
lately.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8