> 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. I'm not sure if there's one available for the n810 tablet. I searched the apt repos and it didn't show up there... > > 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. EP0 IS being used for enumeration. I verified this from the device controller's logs. > > 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) Thats what I'm doing right now. Will post my probe results soon! :) > 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) Unfortunately I can't find out whats going on in the Host, since I don't have access to it's innards! :( > 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. Yes, I know it sounds strange that one has to POLL to get an interrupt! But setting up of an interrupt EP is required because the device (which I'm trying to emulate in s/w) also sets up this EP. > 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. Somehow the enum IS happening because I'm not seeing any errors in the log. Also someone (David Brownell) in the Linux USB mailing list pointed out that the fact that the host is sending out a SET_CONFIGURATION request means that the previous stages of enum passed w/o error (makes sense since SET_CONFIGURATION is last step while enumerating a device). Logs: usb0: Ethernet Gadget, version: May Day 2005 usb0: using musb_hdrc, OUT ep1out IN ep1in STATUS ep2in usb0: MAC 9e:06:cb:e0:8a:37 usb0: HOST MAC fa:eb:60:0c:15:1c usb0: qlen 10 usb0: high speed config #1: 100 mA, Ethernet Gadget, using CDC Ethernet NOTE: I've disabled RNDIS feature in while building my g_ether module. Still I don't see any DHCP packets coming out on this port! :( This means somewhere something gets screwed up! > 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) Ok. Thanks, -mandeep > > 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 > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
