[U-Boot] Debugging, Why USB is not stable
Good evening,
I have some few problems with usb start / reset commands on last uboot.
USB hard drive are not always detected.
Is there something I missed ?
Marvell>> usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found scanning bus for storage devices... 2 Storage Device(s) found
Marvell>> usb tree
Device Tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) | +-3 Mass Storage (480 Mb/s, 100mA) | Corsair Voyager Mini 89980116200801151425232B | +-4 Mass Storage (480 Mb/s, 2mA) JMicron USB to ATA/ATAPI Bridge 1002170B8200
Marvell>> usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
2: Hub, USB Revision 2.0 - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0409 Product 0x005a Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 100mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
3: Mass Storage, USB Revision 2.0 - Corsair Voyager Mini 89980116200801151425232B - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x1b1c Product 0x0b29 Version 2.0 Configuration: 1 - Interfaces: 1 Bus Powered 100mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512
4: Mass Storage, USB Revision 2.0 - JMicron USB to ATA/ATAPI Bridge 1002170B8200 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x152d Product 0x2338 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 2mA - String: "USB Mass Storage" Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - String: "MSC Bulk-Only Transfer" - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512
Marvell>> usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 3 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found
Marvell>> usb info 1: Hub, USB Revision 2.0 - u-boot EHCI Host Controller - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0000 Product 0x0000 Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
2: Hub, USB Revision 2.0 - Class: Hub - PacketSize: 64 Configurations: 1 - Vendor: 0x0409 Product 0x005a Version 1.0 Configuration: 1 - Interfaces: 1 Self Powered Remote Wakeup 100mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
3: Mass Storage, USB Revision 2.0 - Corsair Voyager Mini 89980116200801151425232B - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x1b1c Product 0x0b29 Version 2.0 Configuration: 1 - Interfaces: 1 Bus Powered 100mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 In Bulk MaxPacket 512 - Endpoint 2 Out Bulk MaxPacket 512
Hi Gérald,
I have some few problems with usb start / reset commands on last uboot.
USB hard drive are not always detected.
Is there something I missed ?
Only the fact that USB is a nightmare to work with. No, honestly, we have a continuous stream of USB related problems with the current USB code. As I understand it this results from the ever more diverging USB implementation in U-Boot and e.g. in the Linux kernel. The latter has received a lot of work which is simply not possible by reading datasheets and writing software according to those. This involves a lot of testing on literally thousands of different HW incarnations and on working around the discovered idosyncracies of the parts.
Sometimes I get the impression that we would save a lot of headache by starting afresh and porting the current Linux code into U-Boot thus leverage all this, but nobody yet dared to start such a feat.
For the problem at hand, you may try to test variations on your setup, e.g. by introducing different hubs in different combinations. I'm pretty sure that this will change the situation - sadly may be not for the better.
Cheers Detlev
On Mon, 30 Aug 2010 11:12:25 +0200, Detlev Zundel dzu@denx.de wrote:
Sometimes I get the impression that we would save a lot of headache by starting afresh and porting the current Linux code into U-Boot thus leverage all this, but nobody yet dared to start such a feat.
If somebody starts over, it would be wise to find a way to use the Linux code unmodified or only automatically converted in U-Boot. Otherwise, every resync is painful again and again.
With the use of wrapper functions, a few sed/awk/whatever scripts and all kinds of macro trickery, it is should be possible to use the Linux code without manually changing it for U-boot.
Hi Bas,
On Mon, 30 Aug 2010 11:12:25 +0200, Detlev Zundel dzu@denx.de wrote:
Sometimes I get the impression that we would save a lot of headache by starting afresh and porting the current Linux code into U-Boot thus leverage all this, but nobody yet dared to start such a feat.
If somebody starts over, it would be wise to find a way to use the Linux code unmodified or only automatically converted in U-Boot. Otherwise, every resync is painful again and again.
Absolutely.
With the use of wrapper functions, a few sed/awk/whatever scripts and all kinds of macro trickery, it is should be possible to use the Linux code without manually changing it for U-boot.
In the past this turned out not to be as easy as it sounds. The devil lurks in the details which become apparant only when starting on the job. But of course if somebody accomplishes this, I cannot imagine anyone from stopping him :)
Cheers Detlev
On Mon, 30 Aug 2010 11:52:30 +0200, Detlev Zundel dzu@denx.de wrote:
In the past this turned out not to be as easy as it sounds. The devil lurks in the details which become apparent only when starting on the job. But of course if somebody accomplishes this, I cannot imagine anyone from stopping him :)
Well, I vaguely recall a recent discussion here where a lot of changes to imported code were requested just to fulfil the U-boot code guidelines. That will not help particularly when the code needs to be synced again with the origin.
And yes, nobody said it was easy :-)
Hi Bas,
On Mon, 30 Aug 2010 11:52:30 +0200, Detlev Zundel dzu@denx.de wrote:
In the past this turned out not to be as easy as it sounds. The devil lurks in the details which become apparent only when starting on the job. But of course if somebody accomplishes this, I cannot imagine anyone from stopping him :)
Well, I vaguely recall a recent discussion here where a lot of changes to imported code were requested just to fulfil the U-boot code guidelines. That will not help particularly when the code needs to be synced again with the origin.
For code that we import en-bloc, we explicitely make expections to U-Boot rules[1]:
Source files originating from different projects (for example the MTD subsystem or the hush shell code from the BusyBox project) may, after careful consideration, be exempted from these rules. For such files, the original coding style may be kept to ease subsequent migration to newer versions of those sources.
And yes, nobody said it was easy :-)
Well, at least I thought it at one moment in the past :)
Cheers Detlev
[1] http://www.denx.de/wiki/U-Boot/CodingStyle
Hi Detlev,
2010/8/30 Detlev Zundel dzu@denx.de:
Hi Gérald,
I have some few problems with usb start / reset commands on last uboot.
USB hard drive are not always detected.
Is there something I missed ?
Only the fact that USB is a nightmare to work with. No, honestly, we have a continuous stream of USB related problems with the current USB code.
This is not what I notice on the amount of fixes that are posted on the list... The only fixes I have seen the last year or two were related to newly added host-controller support. Apart from that it is quite silent in the u-boot-usb tree... But, anyway. I know it has some stability issues, although it is now much better compared to a year ago...
As I understand it this results from the ever more diverging USB implementation in U-Boot and e.g. in the Linux kernel.
Indeed, It has diverged that much that I did not succeed in finding the real origin of the code...
Sometimes I get the impression that we would save a lot of headache by starting afresh and porting the current Linux code into U-Boot thus leverage all this, but nobody yet dared to start such a feat.
Hey... I have dared to start it! (But it is a real pain to do it properly, and I stopped half way due to lack of time...)
Kind regards,
Remy
Hi Remy,
Only the fact that USB is a nightmare to work with. No, honestly, we have a continuous stream of USB related problems with the current USB code.
This is not what I notice on the amount of fixes that are posted on the list...
Most problems go without a fix if there is an easy hardware replacement. Even diagnosing such a problem is usually too expensive for customers.
The only fixes I have seen the last year or two were related to newly added host-controller support. Apart from that it is quite silent in the u-boot-usb tree... But, anyway. I know it has some stability issues, although it is now much better compared to a year ago...
Yes it is and without a question I greatly appreciate your work for the USB part.
As I understand it this results from the ever more diverging USB implementation in U-Boot and e.g. in the Linux kernel.
Indeed, It has diverged that much that I did not succeed in finding the real origin of the code...
Sometimes I get the impression that we would save a lot of headache by starting afresh and porting the current Linux code into U-Boot thus leverage all this, but nobody yet dared to start such a feat.
Hey... I have dared to start it! (But it is a real pain to do it properly, and I stopped half way due to lack of time...)
I can understand that also. My intention of the mail was to transport my personal view of the whole area. USB problems in my experience have a very high cost even to diagnose, let alone fix.
Cheers Detlev
participants (4)
-
Bas Mevissen -
Detlev Zundel -
Gérald Kerma -
Remy Bohmer