[U-Boot] Failing USB devices

[U-Boot] Failing USB devices

[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):


DM36x EVM # usb start
(Re)start USB...
USB0:   scanning bus 0 for devices... New Device 0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
length 0x40
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length
0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
length 0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0
length 0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0
length 0x29
get_conf_no 0 Result 41, wLength 41
if 0, ep 0
if 0, ep 1
##EP epmaxpacketin[1] = 1
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length
0x0
new device strings: Mfr=0, Product=0, SerialNumber=0
Manufacturer
Product
SerialNumber
USB hub found
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0
length 0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0
length 0x9
7 ports detected
ganged power switching
part of a compound device
global over-current protection
power on to power good time: 100ms
hub controller current requirement: 1mA
port 1 is not removable
port 2 is not removable
port 3 is not removable
port 4 is removable
port 5 is removable
port 6 is removable
port 7 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0
length 0x4
get_hub_status returned status 0, change 0
local power source is good
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x1
length 0x0
port 1 returns 0
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x2
length 0x0
port 2 returns 0
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x3
length 0x0
port 3 returns 0
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x4
length 0x0
port 4 returns 0
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x5
length 0x0
port 5 returns 0
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x6
length 0x0
port 6 returns 0
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x7
length 0x0
port 7 returns 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
length 0x4
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2
length 0x4
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3
length 0x4
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4
length 0x4
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5
length 0x4
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x6
length 0x4
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x7
length 0x4
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1
length 0x0
port 1 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2
length 0x0
port 2 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x3
length 0x0
port 3 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x4
length 0x0
port 4 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x5
length 0x0
port 5 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x6
length 0x0
port 6 returns 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x7
length 0x0
port 7 returns 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
length 0x4
Port 1 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2
length 0x4
Port 2 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3
length 0x4
Port 3 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x4
length 0x4
Port 4 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x5
length 0x4
Port 5 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x6
length 0x4
Port 6 Status 100 Change 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x7
length 0x4
Port 7 Status 100 Change 0
1 USB Device(s) found
scan end
       scanning usb for storage devices... i=0
i=1
0 Storage Device(s) found

In this case setting CONFIG_USB_HUB_MIN_POWER_ON_DELAY to 3000 overcomes
this issue.

I have other USB drives with similar issues.

It seems there is no correct value for CONFIG_USB_HUB_MIN_POWER_ON_DELAY -
setting this to a large value supports more drives, but at the expense of
boot time. Is this a suggested way to determine when the endpoint is ready
rather than waiting an arbitrary amount of time? Is this possible?

Likewise for the delay between the COMMAND and DATA phase. Has this issue
been seen before? Is there any reason why a large delay would be required
between the very first COMMAND and DATA phase vs subsequent phases - and if
so is there value in changing UBoot to support this?

Andrew Murray

[U-Boot] Failing USB devices

[Marek Vasut]

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.

Best regards,
Marek Vasut

[U-Boot] Failing USB devices

[Benoît Thébaudeau]

Dear Marek, Andrew,

On Friday, August 23, 2013 5:23:14 AM, Marek Vasut 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.

This is the kind of issue that made me create this (discarded) patch at some
point:
http://patchwork.ozlabs.org/patch/176527/

Can you try it? I'm not sure that it will be helpful for your specific case.

I also have this issue with some devices and mainline U-Boot. I can confirm that
this is a device initialization delay issue because subsequent USB commands on
the device succeed (only the single automatic U-Boot USB command that I use at
boot time fails).

Best regards,
Beno?t

[U-Boot] Failing USB devices

[Harvey Chapman]

On Aug 23, 2013, at 6:54 AM, Beno?t Th?baudeau <benoit.thebaudeau@advansee.com> wrote:

> This is the kind of issue that made me create this (discarded) patch at some
> point:
> http://patchwork.ozlabs.org/patch/176527/
> 
> Can you try it? I'm not sure that it will be helpful for your specific case.
> 
> I also have this issue with some devices and mainline U-Boot. I can confirm that
> this is a device initialization delay issue because subsequent USB commands on
> the device succeed (only the single automatic U-Boot USB command that I use at
> boot time fails).

FWIW I've had a similar problem with an OMAP3 board. I run "usb start" and then immediately "usb reset" once or twice until my USB device shows up.

I'll try the suggestions here.

[U-Boot] Failing USB devices

[Andrew Murray]

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.

The port is powered after usb_hub_power_on, I've used
CONFIG_USB_HUB_MIN_POWER_ON_DELAY to set this to a large value (10
seconds), however this has no effect on the above failure.

In fact with some further testing it seems that adding the 1000ms
delay anywhere inside the loop inside the usb_inquiry function
overcomes the above issues. The inquiry still fails, but the
subsequent BBB_reset's stop stalling - successfully reset and then the
next inquiry succeeds and the storage device detected. E.g...

.
COMMAND phase
DATA phase
STATUS phase
!CSWSIGNATURE
BBB_reset
RESET:stall
inquiry returns -1
.
COMMAND phase
DATA phase
STATUS phase
!CSWSIGNATURE
BBB_reset
BBB_reset result 0: status 0 reset
BBB_reset result 0: status 0 clearing IN endpoint
BBB_reset result 0: status 0 clearing OUT endpoint
BBB_reset done
inquiry returns -1
.
COMMAND phase
DATA phase
STATUS phase
inquiry returns 0
ISO Vers 2, Response Data 2
COMMAND phase
STATUS phase
COMMAND phase
DATA phase
STATUS phase
Read Capacity returns: 0xff3f3d00, 0x20000
Capacity = 0x3d4000, blocksz = 0x200
 address 2
partype: 0

Does this suggest there needs to be a larger initial delay in between
the COMMAND and STATUS phase, something wrong with the BBB_reset or
something else?

> 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.
>

Unfortunately I do not have the spec (the USB device is an
off-the-shelf pen drive). The above failure happens in the usb_inquiry
function, this seems to be the first user of BBB transport and this
happens before the first call to usb_test_unit_ready.

Andrew Murray

[U-Boot] Failing USB devices

[Andrew Murray]

On 23 August 2013 11:54, Beno?t Th?baudeau
<benoit.thebaudeau@advansee.com> wrote:
> Dear Marek, Andrew,
>
...
>
> This is the kind of issue that made me create this (discarded) patch at some
> point:
> http://patchwork.ozlabs.org/patch/176527/
>
> Can you try it? I'm not sure that it will be helpful for your specific case.

Unfortunately it has no effect. But then the STATUS phase isn't
stalling in my case, it's just giving back an unexpected value for
CSWSIGNATURE - I have no idea why this is.

>
> I also have this issue with some devices and mainline U-Boot. I can confirm that
> this is a device initialization delay issue because subsequent USB commands on
> the device succeed (only the single automatic U-Boot USB command that I use at
> boot time fails).

You may be able to work around these by setting
CONFIG_USB_HUB_MIN_POWER_ON_DELAY in your config file (assuming the
device is behind a hub).

>
> Best regards,
> Beno?t

Andrew Murray

[U-Boot] Failing USB devices

[Benoît Thébaudeau]

On Saturday, August 24, 2013 12:51:09 PM, Andrew Murray wrote:
> On 23 August 2013 11:54, Beno?t Th?baudeau
> <benoit.thebaudeau@advansee.com> wrote:
> > I also have this issue with some devices and mainline U-Boot. I can confirm
> > that
> > this is a device initialization delay issue because subsequent USB commands
> > on
> > the device succeed (only the single automatic U-Boot USB command that I use
> > at
> > boot time fails).
> 
> You may be able to work around these by setting
> CONFIG_USB_HUB_MIN_POWER_ON_DELAY in your config file (assuming the
> device is behind a hub).

This happens for me without any hub.

Best regards,
Beno?t

[U-Boot] Failing USB devices

[Andrew Murray]

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?

Andrew Murray

[U-Boot] Failing USB devices

[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

[U-Boot] Failing USB devices

[Marek Vasut]

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