I use zaurus windows driver. I think this is the C860 ones but other
zaurus drivers (or other embedded product drivers) may work.
When you connect to windows systems it works, but the connection with
linux host depends on the kernel you are using.
With a 2.6.10 it works well.
With 2.6.14 you get "/unsupported MDLM descriptors/".
You have to modify the file "drivers/usb/net/zaurus.c" (in lower
versions it doesn`t exist) so that it can talk to the PXA.
It is no the best way but it works:
Change
if ((detail->bDetailData[1] & ~0x02) != 0x01)
to
if (detail->bDetailData[1] != 0x00)
It is what i did and have my PXA270 connecting with Linux and Windows
hosts without problems.
Good luck...
Juan Luis Lopez Blazquez
GAJATES....
Grahame Jordan escribió:
> 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
