[U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks

Remy Bohmer linux at bohmer.net
Fri Feb 11 21:08:49 CET 2011


Hi,

2011/2/7 Simon Glass <sjg at chromium.org>:
> Hi Remy,
>
> I have now tested on OHCI with AT91SAM9G45 and found that the code
> already includes a longer timeout and does not have the submission
> bug. So for now I would like to replace that patch with a new one
> which I will send to the list today.

OK

> For now I will drop the reset and restart parts of the patch since I
> don't have evidence that they are required. I still believe the reset
> is too ad-hoc, so am happy to resubmit that part of it if you like.
>
> Regarding your troubled sticks, can you please advise make / model
> numbers and USB ID? It would be good to at least look at these
> problems and see what can be done.

I have for example these sticks that show problems on a OHCI host:
13fe:1a20 Kingston Technology Company Inc.
0204:6025 Chipsbank Microelectronics Co., Ltd CBM2080 Flash drive controller
2008:2018

Note that these sticks give only problems on a at91sam9261 processor
if it runs on 200MHz (10MHz X-tal) and not if it runs on 198.656 MHz
(18.432 MHz X-tal) One stick also stop showing the problem if it has
been powered on for about 10 minutes...(Then it feels a little
warmer).
I have more sticks of the same brand/type/manufacturing-date that do
not show a problem at all...
Furthermore, the exact same software is being used in both cases, and
same stick with same contents.
U-boot since 2010.06 seems to be more sensitive to make these sticks
fail, so there seems to be some regression here.
Failure is usually being visualised as a stall of an endpoint.
Sometimes failure of the stick is that hard, that a power cycle of the
stick is required.

I have not had the time to hook up the USB analyser to see what
exactly is going wrong, but my guts tell me that there are some tricky
timing issues involved.

Kind regards,

Remy


More information about the U-Boot mailing list