[U-Boot] U-Boot timeout
Julius Werner
jwerner at chromium.org
Tue Aug 20 03:07:16 CEST 2013
>> I saw that you had proposed a patch for increasing the U-Boot timeout to
>> work with some USB flash devices:
>>
>> http://lists.denx.de/pipermail/u-boot/2010-December/083467.html
>
> Some devices do have strange characteristics, and increasing the
> timeout can make them work. However, it's tricky since it then makes
> every other device slower (if we are scanning for something that isn't
> there and waiting longer than we need to for 99% of the devices out
> there).
>
Looks like that patch is just about the bulk transfer timeout after a
failed TEST_UNIT_READY. Increasing that shouldn't really hurt, since
if we get that far we already have a device for which basic
enumeration worked (and then you probably want the code to do
everything it can to get it to work).
I have seen quite a few sticks that always fail their first
TEST_UNIT_READY and then take very long to respond, though I'm not
quite sure why (probably all using the same bad chipset/firmware). The
highest I had took about 2.2 seconds, so I would set the timeout to at
least 3 to be on the safe side.
AFAIK Linux uses at least 5 seconds for most USB timeouts, so it's
probably well-covered for this particular problem. I think it is a
specific issue for some sticks that only concerns the response time
after a failed TEST_UNIT_READY (which shouldn't be issued during data
transfer), so if you see other errors during heavy activity on Linux
they are probably unrelated. You should use a USB analyzer or the
Linux usbmon framework to have a closer look at what transfers fail
why if you want to get a better idea of what's wrong.
On Mon, Aug 19, 2013 at 4:49 PM, Simon Glass <sjg at chromium.org> wrote:
> +Julius, who may have more comment
>
> Hi Marshall,
>
> On Mon, Aug 19, 2013 at 4:41 PM, Marshall Ha <marshha at gmail.com> wrote:
>> Hi Simon,
>>
>> I saw that you had proposed a patch for increasing the U-Boot timeout to
>> work with some USB flash devices:
>>
>> http://lists.denx.de/pipermail/u-boot/2010-December/083467.html
>>
>> I have also ran into this problem in U-Boot, with the same root cause. I
>> realize that this mailer is primarily for U-Boot, but I was curious whether
>> this was an issue that you had encountered only in U-Boot, or whether you
>> had also observed this problem after booting into an operating system. For
>> example, I have observed that once booted into Linux, the USB devices will
>> return I/O errors after heavy read/write activity, which I suspect to have
>> the same root cause.
>
> I believe this code was merged into U-Boot - or at least in Chrome OS
> I'm not aware of any patches to this code that remain (on top of
> mainline) other than the USB3 work.
>
> Some devices do have strange characteristics, and increasing the
> timeout can make them work. However, it's tricky since it then makes
> every other device slower (if we are scanning for something that isn't
> there and waiting longer than we need to for 99% of the devices out
> there).
>
> So either you have found a real bug in U-Boot and Linux, or the device
> is broken. I'm not sure which, but it is worth investigating with an
> open mind.
>
> Regards,
> Simon
>
>>
>> Thanks,
>> Marshall
More information about the U-Boot
mailing list