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