Dear Andrew Murray, > 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
I'd like to know from Tom what he things of this OMAP breakage first. Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
