Hi, I can't say 100% for sure your enumeration is broken, but it certainly seems that way. Before you debug too deep into the ECM or ACM side of your CDC, try using USB Snoopy or some such on the enum process. 1. How can I ascertain that the enumeration has happened properly? The dmesg log of the enum certainly looks all wrong. EP0 should always be the control pipe as far as I know. 2. From the above log, does it match the endpoint config as shown by the spec-sheet? I'm confused because EP1 should be interrupt, but log's showing it as BULK!...or this doesn't matter. It does matter a lot. I still think your best chance is to probe the enum process and (since you say you don't have source of the USB CDC device) work out how the descriptors of the CDC Device are set up - and sent to the Host (and whether the Host is actually reading these right) Also, another confusing 'strange ranger' on USB is the interrupt pipe : This actually does NOT interrupt the host. The host polls the device by an interval you can set in the device's descriptor. This is what actually happens through the interrupt pipe. It could always be that the dmesg logs are all wrong but I doubt that I guess.... To me it sounds like 'Ethernet gadget' is getting the host confused and is supplying it with incomplete or incorrect descriptors (from your host's point of view). You first sanity check is the 16 byte FIFO on EP0, the control pipe. This is the link to proper enumeration, and to ensuring that the bulk in/out pipes are properly assigned and used. Oh, also btw, the presence of OTG doesn't matter so much since your CDC device can't arbitrate for Host status (IOW it needs to be an OTG host/device as well to stop it working as a device) Sorry I can't help more at this stage. HTH Best regards, Kris On Fri, 16 Jan 2009 18:24:12 +0530, "Mandeep Sandhu" <mandeepsandhu.chd@xxxxxxxxx> wrote: Hi All, I'm trying to simulate a USB-Ethernet controller device in s/w. For this I plan to use the ethernet gadget driver present in the linux kernel. Currently I don't have any debug board with a USB device controller, so I though I'd use my N810. The N810 has a OTG controller which can act as both Master & slave. I've recompiled the kernel though, to make it behave only as a slave (i.e I've disabled the OTG config in the kernel and enabled only periheral mode). This is to keep things simple and not have OTG functionality interfere in any way. Now the host machine, to which I'll connect my USB device (N810), runs a proprietary OS and we do not have access to it's source code and/or any other means to access it's internals. I know that it supports CDC-ECM driver for a particular chip. The spec-sheet of the chip mentions the following 4 endpoints setup by it: * EP0 - Control * EP1 - Interrupt * EP2 - BULK IN * EP3 - BULK OUT The spec also say that the chip supports only 1 interface and 1 configuration. I enabled all debugs in the ethernet driver (gadget/ether.c). On inserting the ether module I can bring up the USB network interface (usb0). I see the following log in 'dmesg': usb0: using musb_hdrc, OUT ep1out IN ep1in STATUS ep2in usb0: RNDIS ready On connecting the device to the Host, I get the following: musb_hdrc periph: enabled ep2in for int IN, dma, maxpacket 16 musb_hdrc periph: enabled ep1in for bulk IN, dma, maxpacket 512 musb_hdrc periph: enabled ep1out for bulk OUT, dma, maxpacket 512 usb0: high speed config #2: 100 mA, Ethernet Gadget, using RNDIS 1. How can I ascertain that the enumeration has happened properly? 2. From the above log, does it match the endpoint config as shown by the spec-sheet? I'm confused because EP1 should be interrupt, but log's showing it as BULK!...or this doesn't matter. Actually I'm expecting DHCP packets to come over this interface because the HOST gets it's IP address dynamically. But snooping usb0 interface does not show anything! :( This most likely means the enumeration has failed. But I can't figure out why & where. Any pointers on this would be helpfull. Thanks, -mandeep -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
