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

MJ <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.