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

[subject modified to reflect changed emphasis, much snippage]

On Fri, Dec 17, 2021 at 09:20:36PM -0800, Mark Millard wrote:
> >> Until "1 Storage Device(s) found" is automatic this
> >> later-stage material is too late to yet be relevant
> >> or to have an appropriate context.
> >> 
> >> I'm staying focused on getting the "1 Storage Device(s)
> >> found" to be automatic. Absent that you are likely stuck
> >> with doing something similar to be Rock64 e.MMC way of
> >> working --where /boot/loader.conf and /boot/kernel/kernel
> >> and /etc/hostid for early activity is from a UFS
> >> partition on the microsd card.

Agreed entirely.

> >>>> It is not so much that these would be sufficient,
> >>>> but they do establish some context before U-Boot
> >>>> is even active. It could be important to
> >>>> understand that context. (Unsure at this point.)
> >>>> 
> >>>> 
> >>>>>> But that was for the u-boot-rpi4 or u-boot-rpi-arm64 ports.
> >>>>>> (They also later mentioned using "usb_pgood_delay=2000\0"
> >>>>>> instead, a figure they found in a bunch of configrations.)
> >>>>>>
 
It does appear that usb_pgood_delay is in milliseconds, not seconds
as I initially thought. At present I don't think it helps.


> >> 
> >> This gets back into the use of a config.txt with a
> >> bootcode_delay assignment also being in the MSDOSFS
> >> on the microsd card and the file timeout also being
> >> in the MSDOSFS on the microsd card. Only if those
> >> delays together can lead to the USB drive being
> >> accessible will it get any farther.
> >> 
> >> I'd suggest such experiments. The vintage of bootcode.bin
> >> matters as I understand.
> >> 
> 
> One point for testing that could be a simplification
> initially: booting just from a microsd card with the
> USB drive powered and attached already, even though
> the USB drive is not boot-media for this kind of test.
> 
 
So far all experiments have been done with the USB drive
on a powered hub which is kept on. Until the USB drive is 
discovered it's hard to imagine how what's on the disk can 
matter, no?

> The goal would be to get the boot to report something
> other than than the 0 in:
> scanning usb for storage devices... 0 Storage Device(s) found
> 
> That line is not a count of bootable USB storage devices, but
> a count of all the accessible USB storage devices found. it
> reports useful information even for booting from a microsd
> card, including reporting if the USB device was not accessible.

Still, it was surprising to see the disk recognized by the 
usb-sata adapter name but not seen as a disk. Might there
be a SMART control parameter that needs to be tweaked? The
same disks and adapters work fine on two Pi4's without microSD.

I've turned on bootcode.bin's uart and placed a diary of the
experiments at
http://www.zefox.net/~fbsd/slow_usb_notes

The only configuration that makes any progress at all
seems to be a fully-populated microSD FAT slice. 

> I should have noted: so far the only option that
> has evidence for being sufficient is having a build
> of *u-boot*.bin that has usb_pgood_delay already
> assigned. I'm not aware of UEFI style U-Boot's
> reading in any configuration files or executing any
> scripts to control usb_pgood_delay from the outside.

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,
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
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. 

If you got this far, thanks for reading!

bob prohaska