[U-Boot] Failing USB devices

[Andrew Murray]

On 30 August 2013 18:05, Andrew Murray <amurray at embedded-bits.co.uk> wrote:
>
> On 23 August 2013 04:23, Marek Vasut <marex at 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