3rd party kernel module on BeagleBone (not working)

Hi folks,

Me again...with another issue.

Preface: I have a 3rd party kernel module that I use on the
BeagleBoard. It's been working fine for the past 4 months or so
(despite the unrelated ehci module issue which has been discussed in
another thread I started) with a patched kernel (http://rcn-ee.net/deb/
sid/v3.0.4-x3/). In addition, I recently installed (i.e. Friday) the
official ubuntu-arm 12.04 hard float image on another SD card for use
on the BeagleBoard. Using the source for that image, I compiled the
kernel module on the BeagleBoard, installed the kernel module, and it
appears to work fine (module loads, device works in sane manner).
Also, in my current project, we'd like to move from the BeagleBoard to
the BeagleBone, if possible.

Yesterday I received a BeagleBone and installed the patched 12.04 hard
float image on it, following the instructions at
http://elinux.org/BeagleBoardUbuntu#Demo_Image. The image installed
correctly, and after removing resistor 219, I started installing/
porting stuff over and everything seemed great. I also installed the
3rd party kernel module mentioned above. Specifically, I got the
source to the image provided by Robert, patched it, cross-compiled the
kernel, and then cross-compiled the kernel module by pointing to the
kernel source. I installed the kernel module on the BeagleBone,
plugged in the device, and although it was recognized, it doesn't work
correctly (like it does on the BeagleBoard). Also, to rule out any
cross-compilation funny business, I compiled the source on the
BeagleBone overnight to generate the Module.symvers file and then
compiled and installed the kernel module on the board this morning.
Same result.

Here are the dmesg and relevent syslog entries for both the BeagleBone
(device not working) and the BeagleBoard (device working):

BeagleBone dmesg:

[ 79.420259] usb 1-1: new high-speed USB device number 2 using musb-
hdrc
[ 79.561197] usb 1-1: config 2 interface 0 altsetting 0 bulk
endpoint 0x81 has invalid maxpacket 128
[ 79.561261] usb 1-1: config 2 interface 0 altsetting 0 bulk
endpoint 0x1 has invalid maxpacket 128
[ 79.561799] usb 1-1: New USB device found, idVendor=0bfd,
idProduct=000b
[ 79.561842] usb 1-1: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
[ 79.561879] usb 1-1: Product: Kvaser Leaf Light HS
[ 79.664436] Disabling lock debugging due to kernel taint

BeagleBone syslog:

Feb 12 09:36:16 omap kernel: [ 79.420259] usb 1-1: new high-speed
USB device number 2 using musb-hdrc
Feb 12 09:36:16 omap kernel: [ 79.561197] usb 1-1: config 2
interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 128
Feb 12 09:36:16 omap kernel: [ 79.561261] usb 1-1: config 2
interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 128
Feb 12 09:36:16 omap kernel: [ 79.561799] usb 1-1: New USB device
found, idVendor=0bfd, idProduct=000b
Feb 12 09:36:16 omap kernel: [ 79.561842] usb 1-1: New USB device
strings: Mfr=0, Product=2, SerialNumber=0
Feb 12 09:36:16 omap kernel: [ 79.561879] usb 1-1: Product: Kvaser
Leaf Light HS
Feb 12 09:36:16 omap kernel: [ 79.664436] Disabling lock debugging
due to kernel taint
Feb 12 09:36:26 omap kernel: [ 89.690578] usbcore: registered new
interface driver leaf
Feb 12 09:36:26 omap /usr/sbin/leaf.sh: Module leaf added
Feb 12 09:37:04 /usr/sbin/leaf.sh: last message repeated 3 times

It's actually more different then you think.. on the BeagleBoard xM,
if your device is plugged into the 4 port onboard connector, your
actually using the "ehci-omap" kernel driver.. If your device is
connected the xM's otg it's using the "musb" driver. Two completely
different, but providing usb subsystem's..

On the BeagleBone, there's two USB connectors, both are connected to
another newer but still "musb" based IP... :wink: It's always been buggy
in the past, and it's going to take bug reports like your's to figure
out all the issues..

So for a closser apples to apples comparison, can you retry with your
beagleboard xm's otg port in host mode, i don't remember of the
linaro/canonical guys renabled that port in "3.2.0-12-omap"..

Regards,

If your device is connected the xM's otg it's using the "musb" driver. Two completely
different, but providing usb subsystem's..

Ah, that makes sense.

So for a closser apples to apples comparison, can you retry with your
beagleboard xm's otg port in host mode,

That's a good test. The only problem is that I guess I need an
adapter to connect the USB device to the OTG port on the Beagle Board.
Do you guys recommend any specific one? I found a micro-USB otg
converer on Amazon, but the OTG port looks like a micro-USB port to
me, and I can't find a cable/adapter for that.

i don't remember of the linaro/canonical guys renabled that port in "3.2.0-12-omap"..

I have one of your guys' images flashed on a card; it's what we've
been using for the past 4 months. So, I can try plugging into the
port with that image and see if I get the same behavior.

Thanks,

Tony

Do you guys recommend any specific one?

Nevermind that question. I found one. It'll be here on Tuesday and
I'll post the syslog and dmesg output then.

Thanks,

Tony

So for a closser apples to apples comparison, can you retry with your
beagleboard xm's otg port in host mode, i don't remember of the
linaro/canonical guys renabled that port in "3.2.0-12-omap"..

Hi Robert,

My OTG adapter finally came in. So, I shorted J1 with a solder blob,
plugged the device to the OTG port, and powered up the board. It
appears that the module is working correctly. Unlike with the bone,
the /dev/leaf0 mount point exists (because cat /proc/leaf has sane
entries) and here is the relevant chunk from syslog showing the musb
driver in action:

Feb 13 12:44:19 omap kernel: [ 106.203796] usb 2-1: new high-speed
USB device number 3 using musb-hdrc
Feb 13 12:44:19 omap kernel: [ 106.353088] usb 2-1: config 2
interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 128
Feb 13 12:44:19 omap kernel: [ 106.353149] usb 2-1: config 2
interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 128
Feb 13 12:44:19 omap kernel: [ 106.353668] usb 2-1: device v0bfd
p000b is not supported
Feb 13 12:44:19 omap kernel: [ 106.359588] usb 2-1: New USB device
found, idVendor=0bfd, idProduct=000b
Feb 13 12:44:19 omap kernel: [ 106.359619] usb 2-1: New USB device
strings: Mfr=0, Product=2, SerialNumber=0
Feb 13 12:44:19 omap kernel: [ 106.359649] usb 2-1: Product: Kvaser
Leaf Light HS

Now, the only strange message is "usb 2-1: device v0bfd p000b is not supported."

Excuse the potentially stupid question, but would there be a way to
enable ehci and ditch musb in the kernel source (e.g. is it a
configuration that I can set)? I don't need OTG functionality on the
board, and i can always set up the ethernet by editing the
/etc/newtork/interfaces file on my laptop prior to booting up.

Thanks for your help,

Tony

My OTG adapter finally came in. ...

BTW, I forgot to mention that the XM is running the v3.2.3-x4 kernel
now (and it also has Richard Watt's patch for the SMSC9514 problem).

-Tony