[U-Boot] Failing USB devices
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
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
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
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.
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
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
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
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
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
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=0i=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
participants (4)
-
Andrew Murray -
Benoît Thébaudeau -
Harvey Chapman -
Marek Vasut