[U-Boot] Failing USB devices

[Marek Vasut <marex@denx.de>]

Dear Andrew Murray,

> On 30 August 2013 18:05, Andrew Murray <amurray@embedded-bits.co.uk> wrote:
> > 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?
> 
> 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