Date: Sat, 18 Dec 2021 14:35:43 -0800 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Dealing with slow USB disks, was: Re: Saving environment variables in u-boot Message-ID: <20211218223543.GA9484@www.zefox.net> In-Reply-To: <EC6CC83C-BC0A-4A12-866A-9FA24083FF7E@yahoo.com> References: <20211216180704.GA4173@www.zefox.net> <214132DD-A095-4349-BB81-B79CB8CF6B0C@yahoo.com> <20211217013613.GA4452@www.zefox.net> <E2F6D50B-694A-4108-BD84-C85BC96AD832@yahoo.com> <20211218005946.GA7670@www.zefox.net> <5C44D0E6-2FF1-4EEB-B21A-83333D6FCF46@yahoo.com> <9D416106-660F-40BB-98D2-1354B53D2FEF@yahoo.com> <EC6CC83C-BC0A-4A12-866A-9FA24083FF7E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20211218223543.GA9484>