From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 24 May 2018 19:57:07 +0200 Subject: [U-Boot] usb: Fail to get descriptor for USB 2.0 device In-Reply-To: References: <2eda45c3-c5ee-fe14-90bf-09b4e210c987@datacom.com.br> <628db656-4232-20c5-e707-c6d91ae78506@denx.de> <2dc64c17-6d54-2d50-2050-0b4dd6a731d8@datacom.com.br> <1dabcf01-d4f1-39d2-d911-56641e954e72@datacom.com.br> Message-ID: <6ddd87d7-3b93-8cd8-09b2-96f449b8adf9@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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 >> 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 > 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