The problem is figured out!My two lubbock are both pxa250 based.(But all people think it is pxa26x).I am very very sorry to waste your precious time on solving such meaningless question.:-( . Yes pxa250 has bugs as driver's comments says,So the problem is hardware-related.Thank you again for your board knowledge to save me lots of times to locate problem. Now I will continue to test rndis based on Intel Mainstone(pxa27x). Best regards,
From: David Brownell <[EMAIL PROTECTED]>on lubbock(pxa26x)?
To: tong changda <[EMAIL PROTECTED]>
Subject: Re: [linux-usb-devel] Did anyone had successful run rndis based
Date: Tue, 01 Jun 2004 22:03:38 -0700
tong changda wrote:Hello david, very very surprising finding
I add dump_udccs0("handle_ep0"); at beginning of handle_ep0 ,the programs goes further show as msg1(received class req!) but if I comment off dump_udccs0("handle_ep0"); after plugs show msg2 ,
Now I doubt hardware is ok? Do you think so. It seems result a time-related issue.I test 3 times and I am 100% sure that I have no mistake,
I could easily believe there's a race there; I found the PXA hardware to be rather quirky. It wasn't exactly designed for robust USB support, I'd say.
What kind of PXA 26x CPU do you have? I thought they all had the UDCCFR register, evidently yours doesn't.
If you don't have that register, they you'll be doing things like losing SET_CONFIGURATION message ... that seems to be part of what was going on with "msg1" here, the stall is probably in part because the device isn't even configured yet (because the chip lost that request, it was busy with those long printk messages).
I usually need to go to single-character printk commands when tracking down such issues; the long messages aren't usable, they break protocol.
- Dave
----------------- msg 1 snap ---------------- udc: SETUP 80.06 v0200 i0000 l0043 *<7>udc: handle_ep0 EP0_IN_DATA_PHASE 00 = *<7>udc: handle_ep0 EP0_IN_DATA_PHASE 00 = *<7>udc: handle_ep0 EP0_IN_DATA_PHASE 00 = *<7>udc: handle_ep0 EP0_IN_DATA_PHASE 00 = *<7>udc: handle_ep0 EP0_IDLE 01 = opr *<7>udc: handle_ep0 EP0_IDLE C1 = sa rne opr udc: SETUP 21.00 v0000 i0000 l0018 Have Received CDC_SEND_ENCAPSULATED_COMMAND!!!! udc: protocol STALL, 81 err -95 (1860)<2>*<7>udc: handle_ep0 EP0_STALL 11 = sst opr udc: USB suspend usb0: suspend --------------MSG 2 -------------------------- udc: USB reset *<7>udc: SETUP 80.06 v0100 i0000 l0012 *<2>*<2>*<2>*<7>udc: SETUP 80.06 v0200 i0000 l0009 *<2>*<2>*<7>udc: SETUP 80.06 v0200 i0000 l00ff *<2>*<2>*<2>*<2>*<2>*<2>*<7>udc: SETUP 80.06 v0300 i0000 l00ff *<2>*<2>*<7>udc: SETUP 80.06 v0302 i0409 l00ff *<2>*<2>*<2>*<2>*<7>udc: SETUP 80.06 v0300 i0000 l00ff *<2>*<2>*<7>udc: SETUP 80.06 v0302 i0409 l00ff *<2>*<2>*<2>*<2>*<7>udc: SETUP 80.06 v0100 i0000 l0012 *<2>*<2>*<2>*<7>udc: SETUP 80.06 v0200 i0000 l0009 *<2>*<2>*<7>udc: SETUP 80.06 v0200 i0000 l0043 7>udc: SETUP 00.09 v0002 i0000 l0000 usb0: qlen 2 usb0: full speed config #2: Ethernet Gadget, using RNDIS ----------------- end --------------------
From: David Brownell <[EMAIL PROTECTED]>
To: tong changda <[EMAIL PROTECTED]>
Subject: Re: [linux-usb-devel] Did anyone had successful run rndis based
on lubbock(pxa26x)?
Date: Mon, 31 May 2004 15:43:02 -0700
I'm glad that descriptor patch helped!
tong changda wrote:
Sorry , after checking the code, I found after set configuration , ep0 state from EP0_IDLE->EP0_OUT_DATA_PHASE->EP0_END_XFER->EP0_IDLE is normal as your design. BUT bushound show pc send a
I seem to recall that returning to EP0_IDLE would normally be rare ... there were oddities in PXA ep0 state transitions that never quite made sense, and ep0_out transfers haven't seen all that much "real world" use there. And I certainly never had time to test on pxa2xx myself.
What does /proc/driver/udc show?
CDC_SEND_ENCAPSULATED_COMMAND (12 CTL 21 00 00 00 - 00 00 18 00 CLASS 3.5ms 5.1.0 ) but lubbock has not detect that!!! I find only one ep0 interrupt happens after set configu finished. The handler to this interrupt find ep0 state in EP0_END_XFER, so do state trafers etc. I am not sure if this interrupt is trigger by pc's class_specific request? So no further interupt happens,So eth_setup sees no this class spec req.
Sounds like a bug of some kind. I won't be able to track it down, but you seem to be finding lots of good data. Maybe you can enable VERBOSE debug in pxa2xx_udc and you'd notice something interesting near the final packets of such SEND_ENCAPSULATED cases.
It is very likely this is a question that is the last one blocks to my success.Give me a help. Thank you
You're on the right track ... get more info with VERBOSE (packet level tracing) on the Linux side, so we can see what's going on in there. Send along a complete dmesg of enumeration, ideally against XP, starting with modprobe and going to the SEND_ENCAPSULATED
- Dave
From: David Brownell <[EMAIL PROTECTED]>
To: tong changda <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] Did anyone had successful run rndis based
on lubbock(pxa26x)?
Date: Sat, 29 May 2004 11:15:23 -0700
tong changda wrote:
How to debug such kind of problem?
In this case, the RNDIS spec says the device descriptor needs to say it's a communications class device. So the attached patch should make that part work much better.
This is almost a PXA-specific issue, since it's the most widely used chip in the "gadget" stack that can't support CDC Ethernet.
I really like it when the debug info someone provides is so precise at pinpointing a problem. Thanks!
- Dave
--------msg1- usbview ---------- Device Descriptor: bcdUSB: 0x0200 bDeviceClass: 0xFF bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x10 (16) idVendor: 0x0525 (Netchip Technology Inc.) idProduct: 0xA4A2 bcdDevice: 0x0203 iManufacturer: 0x01 iProduct: 0x02 iSerialNumber: 0x00 bNumConfigurations: 0x02
ConnectionStatus: DeviceConnected Current Config Value: 0x00
Likely fixing those IDs will make Windows put it into the RNDIS configuration, Value 0x02, and then put it into RNDIS_DATA_INITIALIZED state below.
Device Bus Speed: Full Device Address: 0x00 Open Pipes: 0
----msg2----- Config Nr. 0 used : y state : RNDIS_UNINITIALIZED medium : 0x00000000 speed : 0 cable : disconnected vendor ID : 0x00000000 vendor : Linux 2.6.5/pxa2xx_udc
--- 1.44/drivers/usb/gadget/ether.c Mon May 17 23:03:16 2004
+++ edited/drivers/usb/gadget/ether.c Sat May 29 11:01:44 2004
@@ -2305,17 +2305,6 @@
UTS_SYSNAME " " UTS_RELEASE "/%s",
gadget->name);
- /* CDC subset ... recognized by Linux since 2.4.10, but Windows
- * drivers aren't widely available.
- */
- if (!cdc) {
- device_desc.bDeviceClass = USB_CLASS_VENDOR_SPEC;
- device_desc.idVendor =
- __constant_cpu_to_le16(SIMPLE_VENDOR_NUM);
- device_desc.idProduct =
- __constant_cpu_to_le16(SIMPLE_PRODUCT_NUM);
- }
-
/* If there's an RNDIS configuration, that's what Windows wants to
* be using ... so use these product IDs here and in the "linux.inf"
* needed to install MSFT drivers. Current Linux kernels will use
@@ -2329,6 +2318,16 @@
__constant_cpu_to_le16(RNDIS_PRODUCT_NUM);
snprintf (product_desc, sizeof product_desc,
"RNDIS/%s", driver_desc);
+
+ /* CDC subset ... recognized by Linux since 2.4.10, but Windows
+ * drivers aren't widely available.
+ */
+ } else if (!cdc) {
+ device_desc.bDeviceClass = USB_CLASS_VENDOR_SPEC;
+ device_desc.idVendor =
+ __constant_cpu_to_le16(SIMPLE_VENDOR_NUM);
+ device_desc.idProduct =
+ __constant_cpu_to_le16(SIMPLE_PRODUCT_NUM);
}
/* support optional vendor/distro customization */
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
