Hi Juan,
Great news.
On the Windows side are you using a generic Windows Driver or a Zaurus
driver??
Cheers
Grahame Jordan
Juan Luis López wrote:
> Finally this works.......!!!!
> Thank you for your help.
> I made it work with the David Brownell patch plus changin product and
> vendor ID.
> Do not mark the RNDIS option in the kernel.
> I act as if i were a zaurus :
> //#define SIMPLE_VENDOR_NUM 0x049f
> //#define SIMPLE_PRODUCT_NUM 0x505a
> #define SIMPLE_VENDOR_NUM 0x04DD
> #define SIMPLE_PRODUCT_NUM 0x8007
> In the window side use Zaurus Drivers driver and everything works
> properly. I used (i think) the C860 ones.
> At last we have PXA27x connecting with linux and windows host .
> Here is the final patch i used.
>
> Cheers
>
> Juan Luis Lopez Blazquez
>
> VIVA GAJATES!!!!!!
> VIVA GAJATES!!!!!!
> VIVA GAJATES!!!!!!
>
>
> David Brownell escribió:
>
>> On Sunday 14 January 2007 2:01 am, Grahame Jordan wrote:
>>
>>
>>> Hi,
>>>
>>> I tried using RNDIS on PXA255 but found it unreliable. Ended up
>>> using a commercial driver from MCCI, similar to the Zaurus driver.
>>> I believe the gadget/ether.c patch is coming out on 2.6.20. I am
>>> using a patched 2.6.18.
>>>
>>
>> The patch to gadget/ether.c will merge (I think) in 2.6.21 but is
>> in Greg's patch archive now, and is in linux-usb-devel archives; I
>> posted the patch on 11-Dec, subject "[patch 2.6.19-git] ethernet
>> gadget interop with MCCI Windows driver". No reason it couldn't
>> be in 2.6.20 other than timing, IMO.
>>
>>
>>
>>
>>> I know that MCCI are working with another customer on PXA270.
>>>
>>
>> I'd expect that adding that patch to the gadget/ether.c driver
>> on a PXA 270 should let folk use MCCI's MS-Windows driver too.
>> (That's more or less what the Zaurus PDAs ship with.)
>>
>> PXA 270 USB peripheral support has been pretty painful, and I'm
>> hoping someone minimizes the ongoing pain by submitting a patch
>> for upstrea kernels that just makes it look to drivers like a
>> PXA 255, rather than trying to take advantage of Intel's dubious
>> hardware features to manage configurations and altsettings.
>>
>> - Dave
>>
>>
>>
>>
>>
>>> Let me know if you need details.
>>>
>>> Cheers
>>>
>>> Grahame Jordan
>>>
>>> Juan Luis López wrote:
>>>
>>>> Hi all
>>>> I am new in the list.
>>>> I want to connect a propietary board using pxa270 with machines
>>>> running windows.
>>>> I have no problems connecting with linux hosts over usb.
>>>> My kernel is 2.6.19, and use the file pxa27x_udc.c provided by
>>>> Handhelds slightly modified.
>>>> I would know if anyone achieved to connect th pxa27x with windows
>>>> machines.
>>>> I dont mind if it is with RNDIS or by a windows driver that support
>>>> this kernel.
>>>>
>>>> Any help will be useful.
>>>> Thank you very much in advance.
>>>> ________________________
>>>> ________________________
>>>> Juan Luis Lopez Blazquez
>>>> [EMAIL PROTECTED]
>>>>
>>
>>
>>
>
> ------------------------------------------------------------------------
>
> 75,85c75,77
> < * link-level setup only requires activating the configuration. Only the
> < * endpoint descriptors, and product/vendor IDs, are relevant; no control
> < * operations are available. Linux supports it, but other host operating
> < * systems may not. (This is a subset of CDC Ethernet.)
> < *
> < * It turns out that if you add a few descriptors to that "CDC Subset",
> < * then some host side drivers from MCCI can treat it as one submode of
> < * a proprietary scheme called "SAFE". So we do that, making it easier
> < * to use those MS-Windows drivers. Those added descriptors make it look
> < * like a CDC MDLM device, but they don't change device behavior at all.
> < * (MCCI Engineering report 950198 "SAFE Networking Functions".)
> ---
>
>> * link-level setup only requires activating the configuration.
>> * Linux supports it, but other host operating systems may not.
>> * (This is a subset of CDC Ethernet.)
>>
> 177,181c169,170
> < //#define SIMPLE_VENDOR_NUM 0x049f
> < //#define SIMPLE_PRODUCT_NUM 0x505a
> < //Act as if we were a zaurus
> < #define SIMPLE_VENDOR_NUM 0x04DD
> < #define SIMPLE_PRODUCT_NUM 0x8007
> ---
>
>> #define SIMPLE_VENDOR_NUM 0x049f
>> #define SIMPLE_PRODUCT_NUM 0x505a
>>
> 270,273d258
> < #ifdef CONFIG_USB_GADGET_S3C2410
> < #define DEV_CONFIG_CDC
> < #endif
> <
> 302a288,290
>
>> #ifdef CONFIG_USB_GADGET_S3C2410
>> #define DEV_CONFIG_CDC
>> #endif
>>
> 506,510d493
> < *
> < * To interop with some MCCI MS-Windows drivers (MSFT's RNDIS drivers
> < * are buggy) we add some more descriptors to advertise as a CDC-MDLM
> < * variant (not strictly conformant) called "SAFE". That borrows a
> < * little from CDC Ethernet, and a little from CDC MDLM.
> 543a527,528
>
>> #if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS)
>>
>>
> 552,553d536
> < #if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS)
> <
> 586,623c569
> < #ifndef DEV_CONFIG_CDC
> <
> < /* "SAFE" loosely follows CDC WMC MDLM, violating the spec in various
> < * ways: data endpoints live in the control interface, there's no data
> < * interface, and it's not used to talk to a cell phone radio.
> < */
> <
> < static const struct usb_cdc_mdlm_desc mdlm_desc = {
> < .bLength = sizeof mdlm_desc,
> < .bDescriptorType = USB_DT_CS_INTERFACE,
> < .bDescriptorSubType = USB_CDC_MDLM_TYPE,
> <
> < .bcdVersion = __constant_cpu_to_le16(0x0100),
> < /*.bGUID = {
> < 0xd8, 0xdd, 0x1a, 0x5a, 0xda, 0xa4, 0x11, 0xd6,
> < 0x87, 0x7e, 0x00, 0x00, 0x86, 0x3b, 0x02, 0x30,
> < },*/
> < .bGUID = {
> < 0x5d, 0x34, 0xcf, 0x66, 0x11, 0x18, 0x11, 0xd6,
> < 0xa2, 0x1a, 0x00, 0x01, 0x02, 0xca, 0x9a, 0x7f,
> < },
> < };
> <
> < /* since "usb_cdc_mdlm_detail_desc" is a variable length structure, we
> < * can't realy use its struct. All we do here is say that we're using
> < * the submode of "SAFE" which directly matches the CDC Subset.
> < */
> < static const u8 mdlm_detail_desc[] = {
> < 6,
> < USB_DT_CS_INTERFACE,
> < USB_CDC_MDLM_DETAIL_TYPE,
> <
> < 0, /* "SAFE" */
> < 0, /* network control capabilities (none) */
> < 0, /* network data capabilities ("raw" encapsulation) */
> < };
> <
> < #endif
> ---
>
>> #ifdef DEV_CONFIG_CDC
>>
> 637a584
>
>> #endif
>>
> 730,732d676
> < *
> < * To assist host side drivers, we fancy it up a bit, and add descriptors
> < * so some host side drivers will understand it as a "SAFE" variant.
> 743,744c687,688
> < .bInterfaceClass = USB_CLASS_COMM,
> < .bInterfaceSubClass = USB_CDC_SUBCLASS_MDLM,
> ---
>
>> .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
>> .bInterfaceSubClass = 0,
>>
> 792d735
> < /* behavior is "CDC Subset"; extra descriptors say "SAFE" */
> 794,800c737,739
> < fs_eth_function[2] = (struct usb_descriptor_header *) &header_desc;
> < fs_eth_function[3] = (struct usb_descriptor_header *) &mdlm_desc;
> < fs_eth_function[4] = (struct usb_descriptor_header *) &mdlm_detail_desc;
> < fs_eth_function[5] = (struct usb_descriptor_header *) ðer_desc;
> < fs_eth_function[6] = (struct usb_descriptor_header *) &fs_source_desc;
> < fs_eth_function[7] = (struct usb_descriptor_header *) &fs_sink_desc;
> < fs_eth_function[8] = NULL;
> ---
>
>> fs_eth_function[2] = (struct usb_descriptor_header *) &fs_source_desc;
>> fs_eth_function[3] = (struct usb_descriptor_header *) &fs_sink_desc;
>> fs_eth_function[4] = NULL;
>>
> 894d832
> < /* behavior is "CDC Subset"; extra descriptors say "SAFE" */
> 896,902c834,836
> < hs_eth_function[2] = (struct usb_descriptor_header *) &header_desc;
> < hs_eth_function[3] = (struct usb_descriptor_header *) &mdlm_desc;
> < hs_eth_function[4] = (struct usb_descriptor_header *) &mdlm_detail_desc;
> < hs_eth_function[5] = (struct usb_descriptor_header *) ðer_desc;
> < hs_eth_function[6] = (struct usb_descriptor_header *) &hs_source_desc;
> < hs_eth_function[7] = (struct usb_descriptor_header *) &hs_sink_desc;
> < hs_eth_function[8] = NULL;
> ---
>
>> hs_eth_function[2] = (struct usb_descriptor_header *) &fs_source_desc;
>> hs_eth_function[3] = (struct usb_descriptor_header *) &fs_sink_desc;
>> hs_eth_function[4] = NULL;
>>
> 948a883
>
>> #ifdef DEV_CONFIG_CDC
>>
> 950a886
>
>> #endif
>>
> 958d893
> < { STRING_ETHADDR, ethaddr, },
> 960a896
>
>> { STRING_ETHADDR, ethaddr, },
>>
> 1055c991
> < dev->in = ep_desc(gadget, &hs_source_desc, &fs_source_desc);
> ---
>
>> dev->in = ep_desc (dev->gadget, &hs_source_desc, &fs_source_desc);
>>
> 1058c994
> < dev->out = ep_desc(gadget, &hs_sink_desc, &fs_sink_desc);
> ---
>
>> dev->out = ep_desc (dev->gadget, &hs_sink_desc, &fs_sink_desc);
>>
> 2347,2348c2283
> < * drivers aren't widely available. (That may be improved by
> < * supporting one submode of the "SAFE" variant of MDLM.)
> ---
>
>> * drivers aren't widely available.
>>
> 2350a2286
>
>> device_desc.bDeviceClass = USB_CLASS_VENDOR_SPEC;
>>
> 2477,2480d2412
> <
> < /* use functions to set these up, in case we're built to work
> < * with multiple controllers and must override CDC Ethernet.
> < */
> 2544,2546c2476
> < * ends up in a persistent config database. It's not clear if
> < * the host sides for the SAFE thing cares -- its original BLAN
> < * thing didn't, Sharp didn't assign those addresses to Zaurii.
> ---
>
>> * ends up in a persistent config database.
>>
> 2551,2557c2481,2491
> < if (get_ether_addr(host_addr, dev->host_mac))
> < dev_warn(&gadget->dev,
> < "using random %s ethernet address\n", "host");
> < snprintf (ethaddr, sizeof ethaddr, "%02X%02X%02X%02X%02X%02X",
> < dev->host_mac [0], dev->host_mac [1],
> < dev->host_mac [2], dev->host_mac [3],
> < dev->host_mac [4], dev->host_mac [5]);
> ---
>
>> if (cdc || rndis) {
>> if (get_ether_addr(host_addr, dev->host_mac))
>> dev_warn(&gadget->dev,
>> "using random %s ethernet address\n", "host");
>> #ifdef DEV_CONFIG_CDC
>> snprintf (ethaddr, sizeof ethaddr, "%02X%02X%02X%02X%02X%02X",
>> dev->host_mac [0], dev->host_mac [1],
>> dev->host_mac [2], dev->host_mac [3],
>> dev->host_mac [4], dev->host_mac [5]);
>> #endif
>> }
>>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
