Hi, 2011/2/7 Simon Glass <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
