G_Ether + Rndis + Windoze

[crow_riot]

i was recently trying to get the ether gadget working in combination with windows. just want to let you know about my findings, if everyone tries to do the same.

the g_ether modules compiles fine using the rndis settings, also gets inserted successfully using insmod. but the device cannot be started on windows (error code #10 ... yeah, great info! <_< ). i tried everything on the windows side, tried different versions of drivers on 2 different machines (windows XP 32 bit, windows 7 64 bit) ... looking for different drivers and so on. no luck at all to get that working.

now i found out that rndis is broken on the 2.6.24 kernel! funny :angry:

i'm going to try to patch the gadget with an earlier kernel version - i've read that kernel 2.6.22 has working rndis in combination with windows. i'll let u know more when there's some progress.

 

[crow_riot]

ported back to 2.6.2.55 ... no success, either. but i think i could port to any of the kernel versions: my knowledge is minimal about rndis, but as from reading the ether.c source, it seems the usb device controller needs to support 3 endpoints (for in,out and status) whereas the LF1000 only has 2 of them. can anyone confirm this? so ... nice try, no cigar? <_<

 

[ikari]

Well, I've also readed ether.c and lf1000_udc.c.
RNDIS needs 4 usb endpoints(for control, in, out, status) but lf1000_udc.h says that LF1000(Pollux) supports only three(control, in, out). So ether.c's configuration codes of status endpoint are also disabled for LF1000(Pollux).

* drivers/usb/gadget/ether.c 2381~2403
* Ether.c's configuration codes of status endpoint are disabled.

#if 0 /* It seems that this codes are disabled by Pollux's kernel engineer */
#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS)
/* CDC Ethernet control interface doesn't require a status endpoint.
* Since some hosts expect one, try to allocate one anyway.
*/
if (cdc || rndis) {
status_ep = usb_ep_autoconfig (gadget, &fs_status_desc);
if (status_ep) {
status_ep->driver_data = status_ep; /* claim */
} else if (rndis) {
dev_err (&gadget->dev,
"can't run RNDIS on %s\n",
gadget->name);
return -ENODEV;
#ifdef DEV_CONFIG_CDC
/* pxa25x only does CDC subset; often used with RNDIS */
} else if (cdc) {
control_intf.bNumEndpoints = 0;
/* FIXME remove endpoint from descriptor list */
#endif
}
}
#endif


* drivers/usb/gadget/lf1000_udc.h 245~252
* It says that lf1000 supports only three endpoints.

static const char *const ep_name[] = {
ep0name, /* everyone has ep0 */
/* lf1000 three bidirectional endpoints */
"ep1-bulk", "ep2-bulk",
#ifndef CPU_LF1000
"ep3-bulk",
#endif
};

 

[ikari]

Well, I can't explain it enough because I'm not good at linux kernel and USB driver. It's hardware limitation? or can be modified on kernel source?

 

[crow_riot]

yeah, these sums up my findings quite well

if i remove the #if 0 hack (who did that? ), calling dmesg gives "RNDIS not possible on lf1000_udc". which seems to be correct.

Well, I can't explain it enough because I'm not good at linux kernel and USB driver. It's hardware limitation? or can be modified on kernel source?

not me either, would be good to know

*edit*
just found whitepaper from belcarra which sums up RNDIS quite nice:
http://www.belcarra.com/rndis/Belcarra_RNDIS_Whitepaper_1.0.PDF

snippet from the paper

CDC Requirements: Endpoints: CONTROL, BULK-IN, BULK-OUT, optionally: INTERRUPT  
RNDIS Requirements:  CONTROL, BULK-IN, BULK-OUT, INTERRUPT

so for the lf1000 we could use CDC instead of RNDIS, but there are hardly windows drivers around. i already did a search but i had no luck. belcarra has some drivers, but i was not able to find some working ones.

*edit2*
found some demo drivers ... http://www.thesycon.de/eng/usb_cdcecm.shtml ... have not tried but will tonite. if they work GPH should just buy a license and all ether problems are solved!

 

[hcf]

I find the idea of hardware limitations really curious. I don't understand why hardware would care when it's all just exposed as integers...I'd expect those are just values in fields received as bits flow by...maybe this shows how much of a mystery USB low-layer functions are to most of us.