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

On 2021-Dec-18, at 14:35, bob prohaska <[email protected]> wrote:

> . . .

> I'm becoming sceptical that usb_pgood_delay is relevant,
> after many reboots this morning. Indeed, I can't detect
> that  the delays have a useful (or harmful) effect.
> They do seem to be active, in that pauses in serial console
> output change roughly in proportion to values set. 
> 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* .

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.

> hoping that the firmware might pass on the value. No luck.
> 
> 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=

> or 
> boot_delay
> So far, the disk has never been recognized as a mass storage device
> on the first try. 
> 
> I also tried putting
> program_usb_boot_timeout=1 in config.txt, to no avail. The line seemed 
> to help on a Pi3 with a different usb-sata adapter and the same kind of
> disk. 

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.


===
Mark Millard
marklmi at yahoo.com