[U-Boot] problem with USB storage STALL status

Greetings,
I faced with problem: when I read data from USB Storage It unpredictably goes to 'RESET:stall' condition. After this read continuously fall down to usb_stor_BBB_reset() function Comment to this function told about Reset recovery: * For Reset Recovery the host shall issue in the following order: * a) a Bulk-Only Mass Storage Reset * b) a Clear Feature HALT to the Bulk-In endpoint * c) a Clear Feature HALT to the Bulk-Out endpoint * * This is done in 3 steps. * * If the reset doesn't succeed, the device should be port reset.
Whereas Universal Serial Bus Specification Revision 2.0 in section 8.5.3 describes that STALL handshake will be returned on all succeeding accesses until a SETUP PID is received.
I can't understand how correctly work with STALL status and where is a root of problem.
Debug information is following:
STATUS phase dev=3f3b03d8, pipe=c8008383, buffer=3f1f7490, length=13, req=(null) TOKEN=0x80008d00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) TOKEN=0x80008c00 DATA phase dev=3f3b03d8, pipe=c8008383, buffer=0058e000, length=20480, req=(null) TOKEN=0x8000dd08 usb_bulk_msg error status 32 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Request Sense returned 00 00 00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Request Sense returned 00 00 00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR

Hello,
Separating DATA phase and STATUS phase by mdelay(1) helps me solve current problem.
diff --git a/common/usb_storage.c b/common/usb_storage.c index fb322b4..ea88536 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -740,6 +740,7 @@ static int usb_stor_BBB_transport(ccb *srb, struct us_data *us) st: retry = 0; again: + mdelay(1); USB_STOR_PRINTF("STATUS phase\n"); result = usb_bulk_msg(us->pusb_dev, pipein, csw, UMASS_BBB_CSW_SIZE, &actlen, USB_CNTL_TIMEOUT*5);
I din't find any explanation for this delay in USB specification, but at Linux Kernel I found similar separation (drivers/usb/storage.c):
/* Some USB-IDE converter chips need a 100us delay between the * command phase and the data phase. Some devices need a little * more than that, probably because of clock rate inaccuracies. */

Dear Anton Vasilyev,
In message CALy29_0wpHEbVH3orjg-RWN41eKXDarRgY+Az0kucyG87i3kKg@mail.gmail.com you wrote:
Separating DATA phase and STATUS phase by mdelay(1) helps me solve current problem.
diff --git a/common/usb_storage.c b/common/usb_storage.c index fb322b4..ea88536 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -740,6 +740,7 @@ static int usb_stor_BBB_transport(ccb *srb, struct us_data *us) st: retry = 0; again:
- mdelay(1); USB_STOR_PRINTF("STATUS phase\n"); result = usb_bulk_msg(us->pusb_dev, pipein, csw, UMASS_BBB_CSW_SIZE, &actlen, USB_CNTL_TIMEOUT*5);
Indentation is all wrong, and there is no SoB line.
I din't find any explanation for this delay in USB specification, but at Linux Kernel I found similar separation (drivers/usb/storage.c):
/* Some USB-IDE converter chips need a 100us delay between the
- command phase and the data phase. Some devices need a little
- more than that, probably because of clock rate inaccuracies. */
Are you sure that you really need 1000 us, instead of the 100 us given here? On which exact device does this happen? Do other devices work with shorter delays?
Best regards,
Wolfgang Denk
participants (2)
-
Anton Vasilyev
-
Wolfgang Denk