[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. 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.

After further investigation I've learnt that removing references to
MUSB_CSR0_H_DIS_PING in musb_hcd.c removes the need for a large delay
between the COMMAND and STATUS phases, this allows more USB mass
storage devices to work.

MUSB_CSR0_H_DIS_PING sets bit 12 of txcsr, however on the DM36x
(http://www.ti.com/litv/pdf/sprufh9a) this appears to be a reserved
bit. In any case it appears to have an undesirable effect. The linux
driver does appear to use this bit, yet these devices do work under
Linux.

I'll submit a patch if you feel this is incorrect, any suggestions for
the best way to fix this?

Andrew Murray