[U-Boot] Failing USB devices

[Andrew Murray]

On 23 August 2013 04:23, Marek Vasut <marex at denx.de> wrote:
>
> Dear Andrew Murray,
>
> > Hello,
> >
> > I'm unable to use some mass storage devices with the current git version
> > (6612ab33956ae09c5ba2fde9c1540b519625ba37) of UBoot on a TI Davinci custom
> > board. I have 7 pen drives, and 2 of them fail.
> >
> > I-O DATA USB Flash Disk (0x04bb/0x0c43)
> >
> > ...
> > 2 USB Device(s) found
> > scan end
> >        scanning usb for storage devices... i=0
> > i=1
> >
> >
> > USB Mass Storage device detected
> > Transport: Bulk/Bulk/Bulk
> > Endpoints In 1 Out 2 Int 0
> > usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0
> > length 0x1
> > Get Max LUN -> len = 1, result = 0
> >  address 2
> > COMMAND phase
> > DATA phase
> > STATUS phase
> > !CSWSIGNATURE
> > BBB_reset
> > usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> > length 0x0
> > RESET:stall
> > inquiry returns -1
> > COMMAND phase
> > DATA phase
> > STATUS phase
> > !CSWSIGNATURE
> > BBB_reset
> > usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> > length 0x0
> > RESET:stall
> > inquiry returns -1
> > COMMAND phase
> > DATA phase
> > STATUS phase
> > !CSWSIGNATURE
> > BBB_reset
> > usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> > length 0x0
> > RESET:stall
> > inquiry returns -1
> > COMMAND phase
> > DATA phase
> > STATUS phase
> > !CSWSIGNATURE
> > BBB_reset
> > usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> > length 0x0
> > RESET:stall
> > inquiry returns -1
> > COMMAND phase
> > DATA phase
> > STATUS phase
> > !CSWSIGNATURE
> > BBB_reset
> > usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0
> > length 0x0
> > RESET:stall
> > inquiry returns -1
> > error in inquiry
> > i=2
> > 0 Storage Device(s) found
> >
> > In this case putting a delay of 1000ms in usb_stor_BBB_transport between
> > the COMMAND and DATA phase, (in place of the conditional 5ms USB_READY
> > delay), overcomes this issue. It seems this 1000ms delay is only required
> > for the first COMMAND, subsequent COMMAND phases seem happy with the 5ms
> > delay.
> >
> > Lexar JumpDrive 32GB (0x0424/0x2507):
> >
>
> So the device takes too long to init itself after powering up the port.

The port is powered after usb_hub_power_on, I've used
CONFIG_USB_HUB_MIN_POWER_ON_DELAY to set this to a large value (10
seconds), however this has no effect on the above failure.

In fact with some further testing it seems that adding the 1000ms
delay anywhere inside the loop inside the usb_inquiry function
overcomes the above issues. The inquiry still fails, but the
subsequent BBB_reset's stop stalling - successfully reset and then the
next inquiry succeeds and the storage device detected. E.g...

.
COMMAND phase
DATA phase
STATUS phase
!CSWSIGNATURE
BBB_reset
RESET:stall
inquiry returns -1
.
COMMAND phase
DATA phase
STATUS phase
!CSWSIGNATURE
BBB_reset
BBB_reset result 0: status 0 reset
BBB_reset result 0: status 0 clearing IN endpoint
BBB_reset result 0: status 0 clearing OUT endpoint
BBB_reset done
inquiry returns -1
.
COMMAND phase
DATA phase
STATUS phase
inquiry returns 0
ISO Vers 2, Response Data 2
COMMAND phase
STATUS phase
COMMAND phase
DATA phase
STATUS phase
Read Capacity returns: 0xff3f3d00, 0x20000
Capacity = 0x3d4000, blocksz = 0x200
 address 2
partype: 0

Does this suggest there needs to be a larger initial delay in between
the COMMAND and STATUS phase, something wrong with the BBB_reset or
something else?

> It would
> be nice if you could check the spec and see if there is a way to query the
> device for ready condition. Although I remember we already do that.
>

Unfortunately I do not have the spec (the USB device is an
off-the-shelf pen drive). The above failure happens in the usb_inquiry
function, this seems to be the first user of BBB transport and this
happens before the first call to usb_test_unit_ready.

Andrew Murray