[U-Boot] usb: Fail to get descriptor for USB 2.0 device
Hi,
When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09.
In u-boot version 2016.09 the device appears like this:
2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5567 Version 1.38 Configuration: 1 - Interfaces: 1 Bus Powered 200mA 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
But in version 2018.03 I just can't start usb. It fails with following error:
=> usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found
I did a "git bisect" and found that this problem is related to the following commit:
c008faa usb: Only get 64 bytes device descriptor for full speed devices
I am not an expert on USB, so I would like to ask for help on this issue.
In u-boot v2018.03, file common/usb.c, line 973, shouldn't the comparison be like this:
if (do_read && dev->speed >= USB_SPEED_FULL) {
or, at list:
if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed == USB_SPEED_HIGH)) {
I would submit a patch for this, but I lack on USB knowledge for explaining the patch.
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
Hi,
Hi,
When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09.
Does it still happen in u-boot/master ?
In u-boot version 2016.09 the device appears like this:
2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5567 Version 1.38 Configuration: 1 - Interfaces: 1 Bus Powered 200mA 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
But in version 2018.03 I just can't start usb. It fails with following error:
=> usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found
I did a "git bisect" and found that this problem is related to the following commit:
c008faa usb: Only get 64 bytes device descriptor for full speed devices
I am not an expert on USB, so I would like to ask for help on this issue.
In u-boot v2018.03, file common/usb.c, line 973, shouldn't the comparison be like this:
if (do_read && dev->speed >= USB_SPEED_FULL) {
or, at list:
if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed == USB_SPEED_HIGH)) {
I would submit a patch for this, but I lack on USB knowledge for explaining the patch.
On 23/05/2018 14:03, Marek Vasut wrote:
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
Hi,
Hi,
When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09.
Does it still happen in u-boot/master ?
Yes, it still happens.
I just tested it with the following commit: dca268a .travis.yml: Further optimizations
In u-boot version 2016.09 the device appears like this:
2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0781 Product 0x5567 Version 1.38 Configuration: 1 - Interfaces: 1 Bus Powered 200mA 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
But in version 2018.03 I just can't start usb. It fails with following error:
=> usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found
I did a "git bisect" and found that this problem is related to the following commit:
c008faa usb: Only get 64 bytes device descriptor for full speed devices
I am not an expert on USB, so I would like to ask for help on this issue.
In u-boot v2018.03, file common/usb.c, line 973, shouldn't the comparison be like this:
if (do_read && dev->speed >= USB_SPEED_FULL) {
or, at list:
if (do_read && (dev->speed == USB_SPEED_FULL || dev->speed == USB_SPEED_HIGH)) {
I would submit a patch for this, but I lack on USB knowledge for explaining the patch.
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:03, Marek Vasut wrote:
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
Hi,
Hi,
When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09.
Does it still happen in u-boot/master ?
Yes, it still happens.
I just tested it with the following commit: dca268a .travis.yml: Further optimizations
In u-boot version 2016.09 the device appears like this:
2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64
Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is.
Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks.
On 23/05/2018 14:43, Marek Vasut wrote:
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:03, Marek Vasut wrote:
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
Hi,
Hi,
When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09.
Does it still happen in u-boot/master ?
Yes, it still happens.
I just tested it with the following commit: dca268a .travis.yml: Further optimizations
In u-boot version 2016.09 the device appears like this:
2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64
Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is.
Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks.
No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ?
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:43, Marek Vasut wrote:
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:03, Marek Vasut wrote:
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
Hi,
Hi,
When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09.
Does it still happen in u-boot/master ?
Yes, it still happens.
I just tested it with the following commit: dca268a .travis.yml: Further optimizations
In u-boot version 2016.09 the device appears like this:
2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64
Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is.
Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks.
No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ?
So that's chipidea ? That one should be reasonably sane.
Submit the patch you had in mind and let's see what happens.
On 23/05/2018 15:00, Marek Vasut wrote:
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:43, Marek Vasut wrote:
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:03, Marek Vasut wrote:
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote:
Hi,
Hi,
When trying to migrate a board from u-boot version 2016.09 to version 2018.03, I found a problem with a USB 2.0 device which used to work on version 2016.09.
Does it still happen in u-boot/master ?
Yes, it still happens.
I just tested it with the following commit: dca268a .travis.yml: Further optimizations
In u-boot version 2016.09 the device appears like this:
2: Mass Storage, USB Revision 2.0 - SanDisk Cruzer Blade 200443243002FB509E64
Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is.
Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks.
No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ?
So that's chipidea ? That one should be reasonably sane.
I don't think so. It uses following drivers: drivers/usb/host/ehci-fsl.c drivers/usb/host/ehci-hcd.c
Submit the patch you had in mind and let's see what happens.
I just noticed that this stick needs more time after the usb_set_address() call. I increased the mdelay(10) to mdelay(20) and the "usb start" command worked. But the problem is that I am still not convinced that this should be the solution.
On 05/23/2018 10:51 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 15:00, Marek Vasut wrote:
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:43, Marek Vasut wrote:
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:03, Marek Vasut wrote:
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: > Hi, Hi,
> When trying to migrate a board from u-boot version 2016.09 to > version > 2018.03, I found a problem with a USB 2.0 device which used to > work on > version 2016.09. Does it still happen in u-boot/master ?
Yes, it still happens.
I just tested it with the following commit: dca268a .travis.yml: Further optimizations
> In u-boot version 2016.09 the device appears like this: > > 2: Mass Storage, USB Revision 2.0 > - SanDisk Cruzer Blade 200443243002FB509E64
Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is.
Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks.
No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ?
So that's chipidea ? That one should be reasonably sane.
I don't think so. It uses following drivers: drivers/usb/host/ehci-fsl.c drivers/usb/host/ehci-hcd.c
Should be chipidea IP.
Submit the patch you had in mind and let's see what happens.
I just noticed that this stick needs more time after the usb_set_address() call. I increased the mdelay(10) to mdelay(20) and the "usb start" command worked. But the problem is that I am still not convinced that this should be the solution.
Try setenv usb_pgood_delay 10000 ; usb reset then ?
Hi,
On Thu, May 24, 2018 at 4:51 AM, DATACOM - Paulo.Zaneti paulo.zaneti@datacom.com.br wrote:
On 23/05/2018 15:00, Marek Vasut wrote:
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:43, Marek Vasut wrote:
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:03, Marek Vasut wrote:
On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: > > Hi,
Hi,
> When trying to migrate a board from u-boot version 2016.09 to version > 2018.03, I found a problem with a USB 2.0 device which used to work > on > version 2016.09.
Does it still happen in u-boot/master ?
Yes, it still happens.
I just tested it with the following commit: dca268a .travis.yml: Further optimizations
> > In u-boot version 2016.09 the device appears like this: > > 2: Mass Storage, USB Revision 2.0 > - SanDisk Cruzer Blade 200443243002FB509E64
Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is.
Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks.
No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ?
So that's chipidea ? That one should be reasonably sane.
I don't think so. It uses following drivers: drivers/usb/host/ehci-fsl.c drivers/usb/host/ehci-hcd.c
Submit the patch you had in mind and let's see what happens.
I just noticed that this stick needs more time after the usb_set_address() call. I increased the mdelay(10) to mdelay(20) and the "usb start" command worked. But the problem is that I am still not convinced that this should be the solution.
Agreed. Can you bisect to see which commit broke your stick?
Regards, Bin
On 23/05/2018 20:40, Bin Meng wrote:
Hi,
On Thu, May 24, 2018 at 4:51 AM, DATACOM - Paulo.Zaneti paulo.zaneti@datacom.com.br wrote:
On 23/05/2018 15:00, Marek Vasut wrote:
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:43, Marek Vasut wrote:
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:03, Marek Vasut wrote: > On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: >> Hi, > Hi, > >> When trying to migrate a board from u-boot version 2016.09 to version >> 2018.03, I found a problem with a USB 2.0 device which used to work >> on >> version 2016.09. > Does it still happen in u-boot/master ? Yes, it still happens.
I just tested it with the following commit: dca268a .travis.yml: Further optimizations >> In u-boot version 2016.09 the device appears like this: >> >> 2: Mass Storage, USB Revision 2.0 >> - SanDisk Cruzer Blade 200443243002FB509E64
Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is.
Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks.
No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ?
So that's chipidea ? That one should be reasonably sane.
I don't think so. It uses following drivers: drivers/usb/host/ehci-fsl.c drivers/usb/host/ehci-hcd.c
Submit the patch you had in mind and let's see what happens.
I just noticed that this stick needs more time after the usb_set_address() call. I increased the mdelay(10) to mdelay(20) and the "usb start" command worked. But the problem is that I am still not convinced that this should be the solution.
Agreed. Can you bisect to see which commit broke your stick?
Yes. The commit which broke my stick is:
commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2 Author: Bin Meng bmeng.cn@gmail.com Date: Mon Sep 18 06:40:42 2017 -0700
usb: Only get 64 bytes device descriptor for full speed devices
My first guess was that this commit should be adapted to "get_descriptor_len()" for USB_SPEED_HIGH too.
But then, I realized that I can bypass this problem by increasing the mdelay() after usb_set_address() from 10 to 20 msec.
So, I think commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2 is not the offender one. It probably uncovered another problem with this stick.
I will try to get a better understanding before submitting a patch.
Regards, Bin
Thank you guys for all the help. I hope I can contribute back too.
Regards, Paulo
On 05/24/2018 06:23 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 20:40, Bin Meng wrote:
Hi,
On Thu, May 24, 2018 at 4:51 AM, DATACOM - Paulo.Zaneti paulo.zaneti@datacom.com.br wrote:
On 23/05/2018 15:00, Marek Vasut wrote:
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:43, Marek Vasut wrote:
On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote: > On 23/05/2018 14:03, Marek Vasut wrote: >> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: >>> Hi, >> Hi, >> >>> When trying to migrate a board from u-boot version 2016.09 to >>> version >>> 2018.03, I found a problem with a USB 2.0 device which used to >>> work >>> on >>> version 2016.09. >> Does it still happen in u-boot/master ? > Yes, it still happens. > > I just tested it with the following commit: > dca268a .travis.yml: Further optimizations >>> In u-boot version 2016.09 the device appears like this: >>> >>> 2: Mass Storage, USB Revision 2.0 >>> - SanDisk Cruzer Blade 200443243002FB509E64 Let me guess, is this a DWC2-based host ? You didn't mention which SoC or USB controller it is.
Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , DWC2 has problems with those sandisk sticks.
No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ?
So that's chipidea ? That one should be reasonably sane.
I don't think so. It uses following drivers: drivers/usb/host/ehci-fsl.c drivers/usb/host/ehci-hcd.c
Submit the patch you had in mind and let's see what happens.
I just noticed that this stick needs more time after the usb_set_address() call. I increased the mdelay(10) to mdelay(20) and the "usb start" command worked. But the problem is that I am still not convinced that this should be the solution.
Agreed. Can you bisect to see which commit broke your stick?
Yes. The commit which broke my stick is:
commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2 Author: Bin Meng bmeng.cn@gmail.com Date: Mon Sep 18 06:40:42 2017 -0700
usb: Only get 64 bytes device descriptor for full speed devices
My first guess was that this commit should be adapted to "get_descriptor_len()" for USB_SPEED_HIGH too.
But then, I realized that I can bypass this problem by increasing the mdelay() after usb_set_address() from 10 to 20 msec.
So, I think commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2 is not the offender one. It probably uncovered another problem with this stick.
That particular lineup of sandisk sticks is trash, I have a few of those here for testing too.
I will try to get a better understanding before submitting a patch.
Did usb_pgood_delay help ?
On 24/05/2018 14:57, Marek Vasut wrote:
On 05/24/2018 06:23 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 20:40, Bin Meng wrote:
Hi,
On Thu, May 24, 2018 at 4:51 AM, DATACOM - Paulo.Zaneti paulo.zaneti@datacom.com.br wrote:
On 23/05/2018 15:00, Marek Vasut wrote:
On 05/23/2018 07:52 PM, DATACOM - Paulo.Zaneti wrote:
On 23/05/2018 14:43, Marek Vasut wrote: > On 05/23/2018 07:37 PM, DATACOM - Paulo.Zaneti wrote: >> On 23/05/2018 14:03, Marek Vasut wrote: >>> On 05/23/2018 07:00 PM, DATACOM - Paulo.Zaneti wrote: >>>> Hi, >>> Hi, >>> >>>> When trying to migrate a board from u-boot version 2016.09 to >>>> version >>>> 2018.03, I found a problem with a USB 2.0 device which used to >>>> work >>>> on >>>> version 2016.09. >>> Does it still happen in u-boot/master ? >> Yes, it still happens. >> >> I just tested it with the following commit: >> dca268a .travis.yml: Further optimizations >>>> In u-boot version 2016.09 the device appears like this: >>>> >>>> 2: Mass Storage, USB Revision 2.0 >>>> - SanDisk Cruzer Blade 200443243002FB509E64 > Let me guess, is this a DWC2-based host ? You didn't mention which > SoC > or USB controller it is. > > Cfr https://lists.denx.de/pipermail/u-boot/2016-January/240090.html , > DWC2 has problems with those sandisk sticks. No, it is a NXP T1024 SoC. Do you think it may be a problem with the SoC or NXP USB host driver ?
So that's chipidea ? That one should be reasonably sane.
I don't think so. It uses following drivers: drivers/usb/host/ehci-fsl.c drivers/usb/host/ehci-hcd.c
Submit the patch you had in mind and let's see what happens.
I just noticed that this stick needs more time after the usb_set_address() call. I increased the mdelay(10) to mdelay(20) and the "usb start" command worked. But the problem is that I am still not convinced that this should be the solution.
Agreed. Can you bisect to see which commit broke your stick?
Yes. The commit which broke my stick is:
commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2 Author: Bin Meng bmeng.cn@gmail.com Date: Mon Sep 18 06:40:42 2017 -0700
usb: Only get 64 bytes device descriptor for full speed devices
My first guess was that this commit should be adapted to "get_descriptor_len()" for USB_SPEED_HIGH too.
But then, I realized that I can bypass this problem by increasing the mdelay() after usb_set_address() from 10 to 20 msec.
So, I think commit c008faa77358bb5b313696dd1d5bb8afa03a6ca2 is not the offender one. It probably uncovered another problem with this stick.
That particular lineup of sandisk sticks is trash, I have a few of those here for testing too.
I will try to get a better understanding before submitting a patch.
Did usb_pgood_delay help ?
Yes. It worked. Thanks for the tip.
participants (3)
-
Bin Meng -
DATACOM - Paulo.Zaneti -
Marek Vasut