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

From: MJ <mafsys1234_at_gmail.com>
Date: Sat, 18 Dec 2021 23:56:04 UTC

On 19/12/2021 9:35 am, bob prohaska wrote:
> [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?

My suggestion: Have you tried directly connecting the USB into the RPI4?
I've had previous run-ins with RPI3B and powered hubs where it seems to be
very slow to enumerate the hub and therefore the devices attached.

Having said that, I have a RPI2 with 13R and two USB flash drives attached and it's
a pure lottery for one of them to be recognized at boot (always the same one, an old transcend 16GB).

Mark