Objective Development Forums

Re: Linux kernel patch for CDC problems

2012-02-16T23:42:29+02:00

Are there any news with this?

My kernel version is 3.2.2. It still doesn't work, and i suspect that i've run into the same problem.
debug messages are:

Code:

1d: 80 06 00 01 00 00 40 00 dd 94
20: 4b 12 01 10 01 02 00 00 08 10 cf
20: c3 c0 16 e1 05 00 01 01 02 ce 45
20: 4b 00 01 3f 8f
ff:
1d: 00 05 41 00 00 00 00 00 e5 e5
20: 4b 00 00
1d: 80 06 00 01 00 00 12 00 e0 f4
20: 4b 12 01 10 01 02 00 00 08 10 cf
20: c3 c0 16 e1 05 00 01 01 02 ce 45
20: 4b 00 01 3f 8f
1d: 80 06 00 02 00 00 09 00 ae 04
20: 4b 09 02 43 00 02 01 00 80 03 75
20: c3 fa c0 fc
1d: 80 06 00 02 00 00 43 00 99 64
20: 4b 09 02 43 00 02 01 00 80 03 75
20: c3 fa 09 04 00 00 01 02 02 79 2a
20: 4b 01 00 05 24 00 10 01 04 0f fc
20: c3 24 02 02 05 24 06 00 01 79 0c
20: 4b 05 24 01 03 01 07 05 83 ac d4
20: c3 03 08 00 ff 09 04 01 00 21 f8
20: 4b 02 0a 00 00 00 07 05 01 e7 7c
20: c3 02 08 00 00 07 05 81 02 47 09
20: 4b 08 00 00 0f fd
1d: 80 06 00 03 00 00 ff 00 d4 64
20: 4b 04 03 09 04 09 78
1d: 80 06 02 03 09 04 ff 00 97 db
20: 4b 10 03 55 00 53 00 42 00 a0 19
20: c3 2d 00 50 00 49 00 4f 00 52 49
20: 4b 00 00
1d: 80 06 01 03 09 04 ff 00 97 e8
20: 4b 22 03 77 00 77 00 77 00 39 f6
20: c3 2e 00 72 00 65 00 63 00 00 8e
20: 4b 75 00 72 00 73 00 69 00 46 e9
20: c3 6f 00 6e 00 2e 00 6a 00 d6 9a
20: 4b 70 00 db 8f
1d: 00 09 01 00 00 00 00 00 27 25
20: 4b 00 00
1d: 21 22 00 00 00 00 00 00 7e 22
20: 4b 00 00
1d: 21 20 00 00 00 00 07 00 5f d2
11: 80 25 00 00 00 00 08 63 c4
20: 4b 00 00
1d: 21 22 03 00 00 00 00 00 7e 11
20: 4b 00 00
1d: 21 22 00 00 00 00 00 00 7e 22
20: 4b 00 00
1d: 21 22 03 00 00 00 00 00 7e 11
20: 4b 00 00
1d: 21 22 00 00 00 00 00 00 7e 22
20: 4b 00 00

The last ones from sending '@' to the device.

Statistics: Posted by avion23 — Thu Feb 16, 2012 11:42 pm

Thanks!

2008-10-30T22:33:35+02:00

Hello,

until I found this page I was trying night and day to get the f...... AVR-USB working...

After I applied the "Kernel-Patch" the AVR-USB-Thing is working perfect and I have a lot of fun playing around with it.

Right now I'm using the Vanilla Kernel 2.6.27.

Here's a little Overview of the two steps i did to get it running:

Code:

1. in /usr/src/linux/drivers/usb/host/uhci-q.c:
[Column ~1050]

static int uhci_submit_bulk(struct uhci_hcd *uhci, struct urb *urb, struct uhci_qh *qh)
{
   int ret;

   /* Can't have low-speed bulk transfers */
//   if (urb->dev->speed == USB_SPEED_LOW)
//      return -EINVAL;

   if (qh->state != QH_STATE_ACTIVE)
//      qh->skel = SKEL_BULK;
      qh->skel = (urb->dev->speed == USB_SPEED_LOW ? SKEL_LS_CONTROL : SKEL_BULK); 
   ret = uhci_submit_common(uhci, urb, qh);
//   if (ret == 0)
   if (ret == 0 && urb->dev->speed != USB_SPEED_LOW)
      uhci_add_fsbr(uhci, urb);
   return ret;
}

2. in /usr/src/linux/drivers/usb/core/config.c in der Funktion usb_parse_endpoint(...):
[Column ~140]

   /* Some buggy low-speed devices have Bulk endpoints, which is
    * explicitly forbidden by the USB spec.  In an attempt to make
    * them usable, we will try treating them as Interrupt endpoints.
    */
   if (to_usb_device(ddev)->speed == USB_SPEED_LOW &&
         usb_endpoint_xfer_bulk(d)) {
             dev_warn(ddev, "config %d interface %d altsetting %d "
                      "endpoint 0x%X is Bulk; this violates USB spec for "
                      "low speed devices.\n",
                      cfgno, inum, asnum, d->bEndpointAddress);
//               dev_warn(ddev, "config %d interface %d altsetting %d "
//                  "endpoint 0x%X is Bulk; changing to Interrupt\n",
//                  cfgno, inum, asnum, d->bEndpointAddress);
//               endpoint->desc.bmAttributes = USB_ENDPOINT_XFER_INT;
//               endpoint->desc.bInterval = 1;
//               if (le16_to_cpu(endpoint->desc.wMaxPacketSize) > 8)
//                       endpoint->desc.wMaxPacketSize = cpu_to_le16(8); 
   }

Statistics: Posted by Guest — Thu Oct 30, 2008 10:33 pm

Linux kernel patch for CDC problems

2008-04-15T10:01:54+02:00

The problem is not only with cdc_acm, but with all host side software. Libusb has different API functions for bulk and interrupt endpoints. Software which is written for one type of endpoint won't accept the other.

Statistics: Posted by christian — Tue Apr 15, 2008 10:01 am

Linux kernel patch for CDC problems

2008-04-15T08:15:45+02:00

Thanks for your fast reply!

christian wrote:Converting the bulk endpoint to an interrupt endpoint implicitly would be a great idea, if a reasonable poll interval is chosen. Unfortunately, the implementation of this conversion seems to be broken: The host side driver still searches for a bulk endpoint, of course, since the interface descriptor of the device lists one.

Hm, i think the interface descriptor is changed also by the code:

Code:

              dev_warn(ddev, "config %d interface %d altsetting %d "
                  "endpoint 0x%X is Bulk; changing to Interrupt\n",
                  cfgno, inum, asnum, d->bEndpointAddress);
              endpoint->desc.bmAttributes = USB_ENDPOINT_XFER_INT;
              endpoint->desc.bInterval = 1;
              if (le16_to_cpu(endpoint->desc.wMaxPacketSize) > 8)
                      endpoint->desc.wMaxPacketSize = cpu_to_le16(8);

I suppose the problem is that config.c out of the usb core is maintained by different people than the cdc_acm module. And the cdc_acm module still insists on bulk endpoints. Therefore it fails.

For the moment, it's probably best to remove all this "intelligence" and simply allow the bulk endpoint in the kernel driver. That's what all other operating systems to, after all.

Yes, i think so too.

Kind regards,
Klaus

Statistics: Posted by Guest — Tue Apr 15, 2008 8:15 am

Linux kernel patch for CDC problems

2008-04-14T18:01:45+02:00

Yes, Bulk endpoints are not allowed for low speed devices. There is no particular reason for this (at least not these days with USB 2.0 hubs), but the standard defines it this way. [For USB 1.0 hubs, this was a performance problem since polling blocks the bus for a long time.]

Since it's additional work to do this check, most operating systems don't care whether there is a bulk endpoint in a low speed device. I don't think it's a good idea to police things which don't harm just to make sure others conform to the standard.

Converting the bulk endpoint to an interrupt endpoint implicitly would be a great idea, if a reasonable poll interval is chosen. Unfortunately, the implementation of this conversion seems to be broken: The host side driver still searches for a bulk endpoint, of course, since the interface descriptor of the device lists one. The automatic conversion should redirect accesses to the bulk endpoint to the interrupt endpoint which is actually used so that the host software does not need to know about the conversion.

AVR-USB does not need to know about any conversions, at the device end there's really no difference between bulk and interrupt.

For the moment, it's probably best to remove all this "intelligence" and simply allow the bulk endpoint in the kernel driver. That's what all other operating systems to, after all.

Statistics: Posted by christian — Mon Apr 14, 2008 6:01 pm

Linux kernel patch for CDC problems

2008-04-14T17:04:18+02:00

Hello Christian, floe, Guest et al.

After several weeks i investigated the AVR-CDC problem in conjunction
with the linux kernel again. I think there is no good news but i have to
admit again that i don't have any clue of all this usb stuff.
So everything i write is a suggestion. But since there are no better
explanations i think it's justified and i try to abstract my cognitions.

Several times was noticed that CDC does not work with low-speed USB
transfer according to the USB spec. I'm not sure whether this is true
directly.
As far as i have seen there are no bulk-endpoints in the spec for
low-speed USB devices but CDC expects bulk-endpoints according to
the spec. This leads indeed into the situation that CDC should not
work on low-speed USB.

The linux kernel reflects this exactly. However in a few steps:

Up to Kernel Version 2.6.23 there was a small code snippet in
drivers/usb/host/uhci-q.c:

Code:

     if (urb->dev->speed == USB_SPEED_LOW)
        return -EINVAL;

it is executed for bulk endpoints and therefore they are
ignored at low speed.

Since this is at quite low-level in the uhci code it leads to the
interesting situation that the AVR-CDC Device works nevertheless if
connected to an High-Speed USB2.0 Hub. Because on Host side it is
handled by ehci driver then and the code above will never be executed.

It's easy to use the already mentioned patch for
"drivers/usb/host/uhci-q.c":

Code:

1045,1046c1045,1046
<       if (urb->dev->speed == USB_SPEED_LOW)
<               return -EINVAL;
---
> //    if (urb->dev->speed == USB_SPEED_LOW)
> //            return -EINVAL;

Then AVR-CDC works even on direct connected USB Ports using uhci.

Unfortunately with Kernel 2.6.24 there appeared a more generic
solution for the low-speed bulk endpoints in drivers/usb/core/config.c.
It's commented like this:

Code:

  /* Some buggy low-speed devices have Bulk endpoints, which is
   * explicitly forbidden by the USB spec.  In an attempt to make
   * them usable, we will try treating them as Interrupt endpoints.
   */

It leads to the following Kernel messages if i plug in my AVR-CDC:

Code:

 usb 3-4.7: USB disconnect, address 41
 usb 3-4.7: new low speed USB device using ehci_hcd and address 42
 usb 3-4.7: config 1 interface 1 altsetting 0 endpoint 0x1 is Bulk; changing to Interrupt
 usb 3-4.7: config 1 interface 1 altsetting 0 endpoint 0x81 is Bulk; changing to Interrupt
 usb 3-4.7: configuration #1 chosen from 1 choice
 cdc_acm 3-4.7:1.0: ttyACM0: USB ACM device

This is bad for AVR-CDC because it does not support interrupt
endpoints. At first i wondered if this would be necessarry at all
because the kernel changes the endpoint from bulk to interrupt already.
Christian mentioned that there is not much difference between bulk and
interrupt endpoints too. Somebody else suggested an adjustment in
AVR-CDC.

So i simply changed the endpoint in the AVR-CDC Code from bulk to
interrupt. The kernel warning disappeared but it still doesn't work.

Then i discovered that there is a generic serial usb driver in the
kernel tree which is derived from the cdc_acm module and i thought it
should work with AVR-CDC too. With the interrupt endpoint enabled
AVR-CDC device the kernel says this:

Code:

usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbserial_generic 3-4.7:1.0: Generic device with no bulk out, not allowed.
usbserial_generic: probe of 3-4.7:1.0 failed with error -5
usbserial_generic 3-4.7:1.1: Generic device with no bulk out, not allowed.
usbserial_generic: probe of 3-4.7:1.1 failed with error -5
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core

After having a look at usb-serial.c and cdc-acm.c i found that the
driver insists on bulk endpoints but don't get it because the kernel
changed them to interrupt endpoints before or interrupt endpoints are
already introduced by my changed AVR-CDC firmware.

All this conforms very well with the USB specification and therefore
doesn't work.

So i think there is no chance to get the AVR-CDC device with
an unpatched linux kernel newer than 2.4.23 running. And i don't think
that this could ever be fixed by the AVR-CDC firmware since it is a
problem as a matter of principle.

Maybe the most reasonable solution would be to write a driver or a
fixed version of the cdc_acm or usbserial_generic module which can deal
with interrupt endpoints.

But the easiest way is to patch "drivers/usb/core/config.c"
like this:

Code:

139,145c139,149
<               dev_warn(ddev, "config %d interface %d altsetting %d "
<                   "endpoint 0x%X is Bulk; changing to Interrupt\n",
<                   cfgno, inum, asnum, d->bEndpointAddress);
<               endpoint->desc.bmAttributes = USB_ENDPOINT_XFER_INT;
<               endpoint->desc.bInterval = 1;
<               if (le16_to_cpu(endpoint->desc.wMaxPacketSize) > 8)
<                       endpoint->desc.wMaxPacketSize = cpu_to_le16(8);
---
>          dev_warn(ddev, "config %d interface %d altsetting %d "
>               "endpoint 0x%X is Bulk; this violates USB spec for "
>               "low speed devices.\n",
>               cfgno, inum, asnum, d->bEndpointAddress);
> //            dev_warn(ddev, "config %d interface %d altsetting %d "
> //                "endpoint 0x%X is Bulk; changing to Interrupt\n",
> //                cfgno, inum, asnum, d->bEndpointAddress);
> //            endpoint->desc.bmAttributes = USB_ENDPOINT_XFER_INT;
> //            endpoint->desc.bInterval = 1;
> //            if (le16_to_cpu(endpoint->desc.wMaxPacketSize) > 8)
> //                    endpoint->desc.wMaxPacketSize = cpu_to_le16(8);

I have posted this already in the forum a few weeks ago. But i assume
in most situations both patches are necessary.

It would be very nice if one of the usb experts would write a short
comment whether my ideas could be true.

And sorry for my weak english!

Kind regards,
Klaus

Statistics: Posted by Guest — Mon Apr 14, 2008 5:04 pm

Linux kernel patch for CDC problems

2008-04-06T10:00:04+02:00

Finally, I managed to compile the kernel with the modified USB-driver (like in my previous post). Data is now received by my Linux PC. But there is a high failure rate. 70% of the data is corrupted. I double checked already with a XP PC, that the controller board is OK. What can I do now?

Statistics: Posted by jschmelzer — Sun Apr 06, 2008 10:00 am

Linux kernel patch for CDC problems

2008-03-26T20:18:59+02:00

OK, I decided to try to fix my problem by building a kernel with modified USB driver. When I understood the posting from Florian right, the code should be looking like this (removed the lines with a "-" and add the lines with "+"):

Code:

static int uhci_submit_bulk(struct uhci_hcd *uhci, struct urb *urb,
      struct uhci_qh *qh)
{
   int ret;

   /* Can't have low-speed bulk transfers */
   /*if (urb->dev->speed == USB_SPEED_LOW)
      return -EINVAL;*/

   if (qh->state != QH_STATE_ACTIVE)
      qh->skel = (urb->dev->speed == USB_SPEED_LOW ? SKEL_LS_CONTROL : SKEL_BULK);
   ret = uhci_submit_common(uhci, urb, qh);
   if (ret == 0 && urb->dev->speed != USB_SPEED_LOW) 
      uhci_add_fsbr(uhci, urb);
   return ret;
}

I downloaded the sources and modified the USB driver. Now I want to compile a new kernel out of that sources. Could somebody just confirm, that I am on the right way?

BR,
Joerg

Statistics: Posted by jschmelzer — Wed Mar 26, 2008 8:18 pm

Linux kernel patch for CDC problems

2008-03-25T20:07:03+02:00

Hello everybody!

I am facing the same problem with Kernel 2.6 and an Intel chipset. I want to use my Asus EeePC (Xandros with Kernel 2.6.21.4) to communicate with the "Experimentierboard " from Ulrich Radig. You can find the project under this Link:

http://www.ulrichradig.de/home/index.ph ... ntierboard

There is a Tiny2313 used with the CDC-2313 firmware.

The circuit is running fine with Windows XP and also with a different PC with nVidia MCP55 chipset running gOS. I tried a third PC with gOS and Intel chipset. There, I was able to duplicate the issue again.

As I am just a beginner with Linux AND AVR C-programming, is there an easy way to solve the problem, or do I need to patch and compile my own Kernel? I would like to stay with my current installation on the EeePC. It was quite a tough job for me to compile and install the AVR-GCC toolchain...

dmesg is reporting this:

usb 2-2: new low speed USB device using uhci_hcd and address 12
usb 2-2: configuration #1 chosen from 1 choice
cdc_acm 2-2:1.0: ttyACM0: USB ACM device

Anybody has an idea for me to get ahead?

Thanks in advance.
BR,
Joerg

Statistics: Posted by jschmelzer — Tue Mar 25, 2008 8:07 pm

Linux kernel patch for CDC problems

2008-02-14T00:19:46+02:00

USB is a host driven serial bus. Real interrupts are therefore not possible, all interrupt-like semantics are implemented with polling.

I don't understand why this change should break anything. There is no difference between interrupt- and bulk-endpoints in AVR-USB. Only the timing of the API calls should differ. This may trigger a bug.

Statistics: Posted by christian — Thu Feb 14, 2008 12:19 am