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 ?