On 23 August 2013 04:23, Marek Vasut <ma...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
