Connecting single USB port directly to imx, kernel driver loading failing

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Connecting single USB port directly to imx, kernel driver loading failing

Jump to solution
1,496 Views
jlumme
Contributor III

In our reference design (Olinuxino maxi), there is a chip from SMSC handling LAN and USB, but in our design we don't need LAN, and we only require one USB port, so just decided to attach USB connector directly to the processor.

Unfortunately there was a slight layout problem, and we couldn't use the connector we planned, but we thought to verify the design we could just take regular extension cable and cut it and solder the wires to the pads. (it looks like this now: http://i57.tinypic.com/wtu7w1.jpg ), please ignore me my sw guy soldering skills :smileywink:.

Now the port seems to work, but when I attach our wifi dongle to the cable, the device seems to enumerate, and driver loading starts, but now driver loading fails (as designed, from software side) when it misreads the chipset ID, and thinks it cannot support this chip:

[    2.390000] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1000 with error -       

[    2.400000] ieee80211 phy0: rt2800_probe_rt: Error - Invalid RT chipset 0xc37b, rev 5108 detected

[    2.410000] ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device

The signaling looks good, I measured the data lines with a scope: http://i58.tinypic.com/2yvryxl.jpg and it's very much comparable to our reference design signaling - but in our reference design with same SW and same usb wifi dongle the driver correctly identifies the chipset, and driver loads without problems.

Could it be that soldering connector this way affects the high speed (480Mbit/s) signaling enough that data is misread ? Though the signaling looks very much comparable in our reference, so that kind of fights that theory..


Actually currently in our kernel config we are still supporting SMSC, so that we can verify stuff also on our reference board, that shouldn't be a problem right ? Thanks for any help!

Labels (2)
0 Kudos
1 Solution
1,040 Views
jlumme
Contributor III

In the end, it turned out to be our design mistake with the data lines. We didn't follow differential data line design guidelines.

By forcing the USB to work full speed only (through hw register HW_USBCTRL_PORTSC1), the wifi dongle works fine.

Thanks Raymond!

View solution in original post

0 Kudos
4 Replies
1,041 Views
jlumme
Contributor III

In the end, it turned out to be our design mistake with the data lines. We didn't follow differential data line design guidelines.

By forcing the USB to work full speed only (through hw register HW_USBCTRL_PORTSC1), the wifi dongle works fine.

Thanks Raymond!

0 Kudos
1,040 Views
raymondwang
Senior Contributor I

     I don't think that USB HS is issue affect your improper ID. Because in USB device enumerating stage, all setup packets has checksum to protect packet integrity.

Especially for HS usb device, before HS chirping ,device also can be enumerated in FS.

   Are you sure your SMSC usb device driver fully identical with reference design? BTW, I think you can try it on PC firstly.

1,040 Views
jlumme
Contributor III

Hi Raymond, thanks for your reply!

I think there is a misunderstanding. What I meant is that I have left the SMSC driver, configuration etc to the same kernel - since we are still verifying parts of our HW with the reference board as well - and so we can utilize the USB hub in the reference HW.

In our own design we have completely removed SMSC hardware, and the USB data lines are now connected directly to the processor.

Are you thinking that maybe enumeration is failing now ? If that would be the case, the wifi driver shouldn't start loading (and then fail), or ?

Maybe I have some misunderstanding how USB works ? I have to admit that this is first time I am working on USB, so please don't take anything for granted in my understanding..

Thanks,

Juha

0 Kudos
1,040 Views
raymondwang
Senior Contributor I

Dear Juha,

I think you mean your design remove SMSC chip (it exists in your reference design). So your wifi dongle is now connected to processor directly, right?

From your kernel log, I think device enumerating successfully but probe failure because of some URB communication issue. It's probably coming up by

your rework cable(USB HS require high precision timing spec).  To verify it,you can connect a LS device (usb mouse/keyboard) ,and some other HS device

(usb disk etc) to verify cable reliability.

Per my experience, you also should pay attention to USB VBUS line since it should provide 500mA current.

I don't think SMSC chip is key point (it's just a 2nd level HUB role).