Re: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot

On Sat, Dec 18, 2021 at 05:19:49PM -0800, Mark Millard wrote:
> 
> 
> On 2021-Dec-18, at 14:35, bob prohaska <fbsd@www.zefox.net> wrote:
> 
> > I even tried putting usb_pgood_delay=20000 in config.txt,
> 
> Wrong place: usb_pgood_delay is only for U-Boot, not the RPi*
> firwmare. It does nothing useful in config.txt on an RPi* .
>

I was hopeful that maybe u-boot might pick up the environment
from the earlier-running firmware. Evidently not.

> As stands the only ways I know to supply usb_pgood_delay
> to U-Boot are:
> 
> A) Type its assignment into the U-Boot prompt.
> B) Build the *u-boot*.bin in question with the value assigned
>    at build time.
> 
> To my knowledge (B) has yet to be tried. Any test of
> usb_pgood_delay that did not involve (A) was a
> wrong-context test and does not apply.
> 
> That includes any testing about seconds vs. milliseconds. I
> expect that usb_pgood_delay is in milliseconds in U-Boot.
> 
> > Usb reset finds the disk after one to about six tries, seemingly 
> > at random, regardless of 
> > usb_pgood_delay
> > bootcode.bin_delay
> 
> ".bin"? Wrong name. use: bootcode_delay=
>
 
Sorry, misreported. The actual line in config.txt on microSD is
bootcode_delay=10

> 
> It will probably be a while before I look at
> 
> http://www.zefox.net/~fbsd/slow_usb_notes
> 
> but it may be that some experiments need to be replaced/re-run
> based on usb_pgood_delay being provided in the wrong place
> and the bootcode.bin_delay wrong name being used.

Experiments using
editenv usb_pgood_delay from 0 to 20 s while in u-boot were tried. 
I could not detect any _consistent_ improvement. Sometimes the disk 
enumerated on the next usb reset, but often enough it made no 
difference. More confusingly, simply repeating usb reset without doing 
anything else has always enumerated the disk within (so far) six tries. 
I'll keep playing with it, especially now that the hub has been removed, 
but if the timing is fussy a persistent loop seems more dependable. 

Thanks for writing!

bob prohaska