On 30 August 2013 18:05, Andrew Murray <amur...@embedded-bits.co.uk> wrote: > > 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?
Hi Marek, As there has been no feedback on this, are you happy to accept a patch that conditionally sets MUSB_CSR0_H_DIS_PING in the header file to 0 when CONFIG_SOC_DM365 is defined? Thanks, Andrew Murray _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
