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.zan...@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...@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 ? -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
