Re: [U-Boot] stability USB memory sticks for the common OHCI USB layer.
Hello Stelian, Thanks for the logging. This is useful info. usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) Apparently the 1st access to the device already fails. Can you please try to set #define CONFIG_LEGACY_USB_INIT_SEQ 1 in your include/configs/board.h ? This enables the old way U-boot does the device initialisation. If this helps I have to check 1 of my patches, which changed this behaviour to make it compliant to the USB standard. The legacy implementation of U-boot is just wrong, but it might work. Kind Regards, Remy ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) usb_new_device: 64 byte descr usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 set address 2 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length 0x0 ERROR: submit_control_message: pipesize for pipe 8000 is zero USB device not accepting new address (error=8000) usb_control_msg: request: 0x1, requesttype: 0x23, value 0x1 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4 2 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found U-Boot -- Stelian Pop [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] stability USB memory sticks for the common OHCI USB layer.
Hello Stelian,
As promised, here is the first patch to test.
I looked at your logging output, and noticed that the device you mailed me the
logging from contained an interrupt endpoint (3 endpoints).
My USB sticks do not have such an endpoint, so that was the only difference
in the lsusb output. In the mean time I found such a device here also, but
that one worked also without problems...
So, my suggestion is to look it in a different area. I compared the Linux
code and the U-boot code, and found another difference. U-boot uses timeouts
on Control requests between 100 and 500 ms, while Linux uses a 5 second
timeout. Maybe your device is slower than my devices, and maybe that is
where we have to look. (Notice that my devices always respond between 70 and 95
ms
on a control request, so 100 ms is very short in the first place)
So, here is the first patch. Can you please test if this helps?
If it does not help, I would like to wait until you are able to verify if your
problem with _your_ USB sticks also exists on a AT91sam9261-ek, to be able to
differentiate if the problem is USB stick related or SoC related.
NOT-FOR-MAINLINE
Make the USB timeout on a Control request equal to max. 5 seconds.
This is an experimental patch to test if this is the cause of some USB sticks
not functional in U-boot.
It is a difference between U-Boot and the Linux kernel, where Linux always uses
a max. of 5 seconds timeout on a control request, and U-boot uses 100ms, 300ms
and 500ms timeouts.
Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
---
common/usb.c |4 ++--
common/usb_storage.c | 16
include/usb.h|8 +++-
3 files changed, 17 insertions(+), 11 deletions(-)
Index: u-boot-git-22092008/common/usb.c
===
--- u-boot-git-22092008.orig/common/usb.c 2008-09-22 14:29:36.0
+0200
+++ u-boot-git-22092008/common/usb.c2008-09-22 14:29:37.0 +0200
@@ -397,7 +397,7 @@ int usb_clear_halt(struct usb_device *de
result = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
USB_REQ_CLEAR_FEATURE, USB_RECIP_ENDPOINT, 0,
-endp, NULL, 0, USB_CNTL_TIMEOUT * 3);
+endp, NULL, 0, USB_CNTL_TIMEOUT);
/* don't clear if failed */
if (result 0)
@@ -513,7 +513,7 @@ int usb_set_interface(struct usb_device
ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
USB_REQ_SET_INTERFACE, USB_RECIP_INTERFACE,
alternate, interface, NULL, 0,
- USB_CNTL_TIMEOUT * 5);
+ USB_CNTL_TIMEOUT);
if (ret 0)
return ret;
Index: u-boot-git-22092008/common/usb_storage.c
===
--- u-boot-git-22092008.orig/common/usb_storage.c 2008-09-22
14:29:37.0 +0200
+++ u-boot-git-22092008/common/usb_storage.c2008-09-22 14:29:37.0
+0200
@@ -327,7 +327,7 @@ static int us_one_transfer(struct us_dat
USB_STOR_PRINTF(Bulk xfer 0x%x(%d) try #%d\n,
(unsigned int)buf, this_xfer, 11 - maxtry);
result = usb_bulk_msg(us-pusb_dev, pipe, buf,
- this_xfer, partial,
USB_CNTL_TIMEOUT*5);
+ this_xfer, partial,
USB_CNTL_TIMEOUT);
USB_STOR_PRINTF(bulk_msg returned %d xferred %d/%d\n,
result, partial, this_xfer);
if(us-pusb_dev-status!=0) {
@@ -393,7 +393,7 @@ static int usb_stor_BBB_reset(struct us_
USB_STOR_PRINTF(BBB_reset\n);
result = usb_control_msg(us-pusb_dev, usb_sndctrlpipe(us-pusb_dev,0),
US_BBB_RESET, USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
-0, us-ifnum, 0, 0, USB_CNTL_TIMEOUT*5);
+0, us-ifnum, 0, 0, USB_CNTL_TIMEOUT);
if((result 0) (us-pusb_dev-status USB_ST_STALLED))
{
@@ -433,7 +433,7 @@ static int usb_stor_CB_reset(struct us_d
cmd[1] = 4;
result = usb_control_msg(us-pusb_dev, usb_sndctrlpipe(us-pusb_dev,0),
US_CBI_ADSC, USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
-0, us-ifnum, cmd, sizeof(cmd),
USB_CNTL_TIMEOUT*5);
+0, us-ifnum, cmd, sizeof(cmd),
USB_CNTL_TIMEOUT);
/* long wait for reset */
wait_ms(1500);
@@ -485,7 +485,7 @@ int usb_stor_BBB_comdat(ccb *srb, struct
/* copy the command data into the CBW command data buffer */
/* DST SRC LEN!!! */
memcpy(cbw.CBWCDB, srb-cmd, srb-cmdlen);
- result = usb_bulk_msg(us-pusb_dev, pipe, cbw, UMASS_BBB_CBW_SIZE,
actlen,
Re: [U-Boot] stability USB memory sticks for the common OHCI USB layer.
Le lundi 22 septembre 2008 à 14:42 +0200, Remy Bohmer a écrit : pièce jointe document texte brut (increase-usb-control-timeout.patch) Hello Stelian, As promised, here is the first patch to test. Unfortunately it doesn't seem to make much difference, see the log below. I've enabled USB_DEBUG in common/usb.c in case some of the more verbose printouts ring someone's bell. If it does not help, I would like to wait until you are able to verify if your problem with _your_ USB sticks also exists on a AT91sam9261-ek, to be able to differentiate if the problem is USB stick related or SoC related. Sure, I'll try to test this next monday. Stelian. usb reset (Re)start USB... USB: scanning bus for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x8 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 2 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=0, Product=1, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF Manufacturer Product OHCI Root Hub SerialNumber usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x9 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) ERROR: USB-error: DEVICENOTRESPONDING: Device did not respond to token (IN) or did not provide a handshake (OUT) (5) usb_new_device: 64 byte descr usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 set address 2 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length 0x0 ERROR: submit_control_message: pipesize for pipe 8000 is zero USB device not accepting new address (error=8000) usb_control_msg: request: 0x1, requesttype: 0x23, value 0x1 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4 2 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found U-Boot -- Stelian Pop [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
