On 23 August 2013 04:23, Marek Vasut marex@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